> On 27 Jul, 2019, at 6:01 am, Bob Briscoe <[email protected]> wrote: > > Yes, with byte-preserving, as packets are re-assembled the number of marked > packets reduces. Counter-intuitively, that's correct, even for compatibility > with TCP's single congestion response per RTT. > > I originally suggested the requirement in RFC3168 to preserve the number of > marked packets, but it's incorrect. It's not compatible with TCP's single > response per RTT (or the response to the proportion of marks of other > TCP-Friendly real-time congestion controls). > > This is not a matter of compatibility with just one of SCE or L4S. The > logical OR approach is wrong for both, and the byte-preserving approach is > correct for both - see previous response to Markku. > > Reasoning: the paramount requirement when reassembling fragments is to > reconstruct the marking probability that would have occurred had the packets > not been fragmented when the AQM in the tunnel marked them. The logical OR > approach increases the marking probability as if congestion was higher, while > byte-preserving keeps it constant.
I think you are still thinking in terms of marking *probability*, which is not correct in at least conventional RFC-3168 semantics. Conventional TCPs are sensitive to the number of RTTs between marks; the DCTCP response function is sensitive to the number of marks per RTT. Both are *time based* relationships. Codel, the most deployed AQM, is a *time based* marking function. Preserving the marking probability while the number of packets decreases would reduce the number of RTTs containing a mark. The original logical-OR function correctly preserves this property, and only fails when there's a mixture of ECT(0) and ECT(1) marks on fragments for a single packet (which can legitimately happen with SCE but not L4S, ironically enough). Preserving the number of marked bytes does not preserve the number of marks over time, and therefore does not preserve the intent of the marks applied by the AQM. That's the logic behind my suggested series of rules. I carefully held both L4S and SCE requirements in mind, as well as those of RFC-3168, while drafting them. - Jonathan Morton _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
