> 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.) - 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). (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.) - A mixture of Not-ECT and other ECN codepoints is unexpected and may imply upstream shenanigans. - Jonathan Morton _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
