Re: [tsvwg] SCE / L4S and fragmentation

[Jonathan Morton <[e-mail]>]

I had hoped that a thread with this title represented an opportunity to discuss the effects of fragmentation on L4S and SCE, *without* immediately descending into tribalism and ad-hominem attacks.  Accordingly, I will decline to quote *any* of Bob Briscoe's latest post, in favour of summarising the technical content.

Firstly, we have apparently agreed that fragmentation has no deleterious effects on ECN codepoints applied prior to fragmentation.  I do not understand why I am being attacked for expressing that agreement.

On the subject of IPv6 fragmentation, Bob previously asserted that RFC-3168 has nothing to say about IPv6.  This is demonstrably false by a simple text search over RFC-3168, in which the IPv6 Traffic Class Octet is repeatedly equated with the IPv4 TOS Byte.  In §5.3 dealing with fragmentation, neither IPv4 nor IPv6 are explicitly mentioned, implying that the language therein applies equally to both.  I have not personally verified that any given IPv6 receiver correctly implements these rules, but I would expect that they generally do.

So the only material difference is that IPv6 behaves as if the DF (Don't Fragment) bit is always set, which limits the scope of the problem at hand (for most transports) to the case of an on-path tunnel which performs outer fragmentation.  The only exception is when a jumbo datagram needs to be sent, but most such protocols are not ECTs (ECN Capable Transports) and are therefore out of scope for this discussion.  We can of course still discuss any specific counterexamples that might be identified.

Most ECTs are expected to set DF (on IPv4) and implement PMTUD.  Indeed, most do.  If certain tunnel implementations interact badly with PMTUD, I think that is primarily a problem for the tunnel, not the transport.  It is still desirable that the transport functions reasonably well in difficult circumstances, and that is part of what I hope to discuss in this thread.

Bob stated that the language I referred to in the quote below was present in an earlier draft of rfc6040update-shim:

> ISTR, at some point in the past, interim language was suggested which would require taking the ECN codepoint from one of the fragments constituting the packet, with the behaviour being otherwise unspecified except by the existing rules.  This would be a worthwhile improvement from SCE's point of view, and is likely to match at least some existing implementations.

That is not true, however.  What *is* present there is language which strongly advocates propagating marking on a byte-preserving basis, both for CE and ECT(1) codepoints, and that is what I have objected to, both recently and less recently.  What I referred to above is much simpler and less prescriptive, and can be summarised in the following proposed language updating RFC-3168 §5.3:

> …if any fragment of an IP packet to be reassembled has the Not-ECT codepoint set, then one of two actions MUST be taken:
> 
>  * Set the Not-ECT codepoint on the reassembled packet.  However, this MUST NOT occur if any of the other fragments contributing to this reassembly carries any ECN codepoint other than Not-ECT.
> 
>  * The packet is dropped.
> 
> If both actions are applicable, either MAY be chosen.
> 
> Reassembly of a fragmented packet MUST NOT change the ECN codepoint when all of the fragments carry the same codepoint.
> 
> Notwithstanding the above, if any fragment of an IP packet to be reassembled has the CE codepoint set, then one of two actions MUST be taken:
> 
>  * Set the CE codepoint on the reassembled packet.
> 
>  * The packet is dropped.
> 
> If neither the Not-ECT nor the CE codepoints appear on any of the fragments contributing to this reassembly, then the ECN codepoint set on the reassembled packet SHOULD be one of the ECN codepoints present on one of the fragments.  Any contributing fragment MAY be chosen as the source.

I'm sure some wordsmithing is in order on the above, but I hope this makes my position clearer.

In connection with this, Bob claims I'm asking for requirements to support SCE in a standards-track document.  If that is what I was actually asking for, then the final sentence in the above proposed language would be markedly different.  I would be asking for the existing requirement in RFC-3168 §5.3 that congestion information MUST NOT be lost during reassembly be interpreted to treat ECT(1) codepoints as congestion information.

Mindful of SCE's current status in the WG, I am deliberately *not* asking for that at this time, even though it would improve the quality of SCE signalling over tunnelled paths.  Instead, I am asking for simple, easily-implemented language which is approximately neutral between L4S and SCE, but allows for the possibility of using ECT(1) as an output from the network at some point in the future.

Finally, I thank Bob for the link to a two-year-old slide deck containing a survey of existing tunnel protocols.  I infer from this that shimmed tunnels have typically considered RFC-6040 as out of scope, as the latter only explicitly covers tunnels without a shim layer.  But the rules in RFC-6040 for handling ECN are generally applicable, I think, and have nothing whatsoever to do with fragmentation.  This latter fact informs my support for the suggestion to separate the concerns of reassembly and decapsulation.

 - Jonathan Morton