Re: [tsvwg] SCE / L4S and fragmentation

[Bob Briscoe <[e-mail]>]

Jonathan,

On 15/03/2020 16:15, Jonathan Morton wrote:
> 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.

[BB] Readers on this list will see that you've used this as an excuse to 
snip (and not address) the cases where SCE doesn't work (again).

When you are indulging in attention deflection tactics and get called 
out, attacking the person who called you out is even less polite than 
the original behaviour.

>
> 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.

[BB] I asked to retract the untruthful statement you had made that L4S 
was equally deficient in this respect. You were being called out (not 
attacked) for snipping that request.

>
> On the subject of IPv6 fragmentation, Bob previously asserted that RFC-3168 has nothing to say about IPv6.

[BB] Bob actually said RFC3168 "does not seem to recognize that IPv6 
*e2e fragmentation* exists."

> 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.

[BB] You would not be able to verify anything, because RFC3168 offers no 
rules to verify. It explicitly says that it offers no rules for how to 
reassemble a mixture of ECT(0) and ECT(1) fragments.

The remedy that RFC3168 offers for the lack of guidance on how to 
reassemble a mixture of ECT(0) and ECT(1) fragments is to set DF. No 
remedy is offered for IPv6 e2e fragmentation, which has no DF flag.

> 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.

[BB] The additional important exception that Bob highlighted is where 
UDP datagrams are larger that the MTU, in which case IPv6 has to do e2e 
fragmentation and reassembly.

If you snip these two points again without addressing them, I will 
assume everyone on the list will notice. So I will not bother to ask the 
questions again.


>
> 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:

[BB] I thought your "interim language was suggested" phrase meant this 
text was in the draft. Hence why I thought you were referring to the 
byte-preserving text. It would have been straightforward for you to 
point to the place where you suggested some text.

As I said, in the latest revision, I took out the byte-preserving 
language at your request (i.e. this text *is not* present), and have 
since argued for it on the list instead, and only included least common 
denominator text in the draft.

>
>> …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.

[BB] I (and David Black) have argued that a separate draft is needed to 
update fragment reassembly in RFC3168. Can you please accept that we are 
not going to update ECN fragmentation and reassembly in 
rfc6040update-shim. Then it can unblock and be published.

rfc6040update-shim is meant to be about encap and decap. It would allow 
this draft to become unstuck if it just said fragmentation and 
re-assembly is out of scope (which it is).

>
> 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.

[BB] Aside from the question of whether and where we update reassembly 
text, your suggested text would be incompatible with the standards track 
PCN RFCs. Whereas the previous text in the draft was compatible with 
PCN, and happened to support SCE as well.

I am aware that you haven't got your head around why byte-preserving 
produces a correct result for all of RFC3168, SCE and L4S style 
signalling. But let's continue that discussion in the other thread.



Bob


>
> 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
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/