[Writing as draft shepherd and responsible WG chair, still interested in additional responses & comments]
Back to Joe's original comment that started this. > - it would be useful for these documents to address how fragmentation and > reassembly affects these signals > (esp. if reassembling fragments with different ECN values) Bob writes: > 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). I'm not clear on how that's either incorrect or incompatible with TCP's single response per RTT - as long as TCP sees a CE mark within an RTT interval, the right thing happens, and extra CE marks don't matter. Picking up a line from Jonathan's response: > Preserving the marking probability while the number of packets decreases > would reduce the number of RTTs containing a mark. I'm definitely concerned about that. Suppose we have a stream of packets in which each packet is fragmented into 3 fragments, and exactly one fragment is marked in each RTT. My understanding of the requirement in the new text to preserve the number of marked octets is that it would result in a CE marked packet once every 3 RTTs after reassembly, which is wrong. If DCTCP needs a different marking behavior, then these drafts need a warning about what goes wrong if that's not done - that's reasonable as deployment considerations for DCTCP, but not TCP, as DCTCP is currently a "controlled environment" protocol. Further, these two drafts currently do not modify RFC 3168, which (IMHO) is a "feature" ... not a "bug" ... Additional thoughts/comments? Thanks, --David > -----Original Message----- > From: Bob Briscoe <[email protected]> > Sent: Saturday, July 27, 2019 6:01 AM > To: Jonathan Morton > Cc: Joe Touch; Black, David; [email protected]; tsvwg > Subject: Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines > and rfc6040-update-shim drafts, closes 6 May 2019 > > > [EXTERNAL EMAIL] > > Jonathan, > > On 10/07/2019 11:38, Jonathan Morton wrote: > >> On 8 Jul, 2019, at 3:27 pm, Bob Briscoe <[email protected]> wrote: > >> > >> These are quite significant updates to outer fragment processing at the > tunnel egress. But, given something has to be said, I can't think of a better > way (see the original quoted email about why the logical OR of the ECN > codepoints as defined in RFC3168 is no longer sufficient - and it's no simpler > anyway). > > If I may offer such an alternative approach, which avoids the need to keep > persistent state at the reassembly point whilst still properly handling > RFC3168, L4S and SCE expected semantics: > > > > - If all incoming fragments are Not-ECT marked, the outgoing packet must > also be so marked. > > > > - If any fragment has CE set, the reassembled packet must have CE set. > > > > (This guarantees correct RFC3168 and SCE behaviour for each conventional > AQM marking action. Your proposal doesn't, as it will generally result in > fewer CE marks downstream especially if the smaller fragments end up being > marked; subsequent upstream CE marks have to relieve a counter deficit > before they will be honoured. The tradeoff is that L4S may see some > technical "over marking" but this should be tolerable.) > 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. > > If it helps, consider the reductio ad absurdam proof that, as fragments > get smaller, the logical OR approach would ultimately result in every > packet being marked. > > Regarding state, the problem isn't amount of state because reassembly > requires per-packet state and the the approach I suggested adds only 2 > int's per tunnel decap. > > The problem seems to be common read-write access to these variables. > However, it's not important that they are updated before forwarding > continues. So updates can be queued in parallel to forwarding. > > Also the state can include occasional errors, so it doesn't have to be > strictly persistent - meaning it's unnecessary to preserve during a > re-boot or if a tunnel endpoint is moved. > > > - Notwithstanding the above rules, the ECT(0) vs ECT(1) choice should be > made according to the majority of fragmented payload bytes so marked, on > the individual packet being reassembled. In the case of a tie, break in > favour > of ECT(0). > My original proposed wording deliberately allows such an algorithm. > Byte-preserving was stated as a goal. The specific mechanism was only an > example. > > (I'm not convinced majority voting would be simpler than byte counting, > which never leads to an exception case. But that's irrelevant anyway). > > > > > (We may expect that L4S packets will be entirely ECT(1) marked except for > fragments or whole packets carrying CE; this also applies to obsolete Nonce > Sum semantics. SCE and RFC-3168 flows will be ECT(0) marked by default, > with perhaps some ECT(1) marking applied by SCE middleboxes. SCE is > reasonably tolerant of disruption to its markings, because the control loop is > fundamentally stable.) > As above, my proposed wording is nothing to do with support for one > semantic or another. It is for all semantics. > > > > - A mixture of Not-ECT and other ECN codepoints is \unexpected and may > imply upstream shenanigans. > Yup, the wording in 3168, and my wording both agree with you here. > > > > Bob > > > > > > - Jonathan Morton > > > > -- > __________________________________________________________ > ______ > Bob Briscoe http://bobbriscoe.net/ _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
