Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text

[Jonathan Morton <[e-mail]>]

> On 8 Oct, 2019, at 10:51 pm, Black, David <[e-mail]> wrote:
> 
> **NEW**: Beyond those first two paragraphs, I suggest deleting the rest of Section 5 of the rfc6040update-shim draft and substituting the following paragraph:
>  
>    As a tunnel egress reassembles sets of outer fragments
>    [I-D.ietf-intarea-tunnels] into packets, it MUST comply with
>    the reassembly requirements in Section 5.3 of  RFC 3168 in
>    order to ensure that indications of congestion are not lost.
>  
> It is certainly possible to continue from that text to paraphrase part or all of Section 5.3 of RFC 3168, but I think the above text crisply addresses the problem, and avoids possibilities of subtle divergence.  I do like the “reassembles sets of outer fragments” lead-in text (which I copied from the current rfc6040shim-update draft) because that text makes it clear that reassembly logically precedes decapsulation at the tunnel egress.
>  
> Comments?

Looks good to me.

The one case this doesn't really cover is what happens when a fragment set has a mixture of ECT(0) and ECT(1) codepoints.  This probably isn't very relevant to current ECN usage, but may become relevant with SCE, in which middleboxes on the tunnel path may introduce such a mixture to formerly "pure" packets.  From my perspective, a likely RFC-3168 compliant implementation of arbitrarily choosing one fragment's ECN codepoint as authoritative (where it doesn't conflict with other rules) is acceptable, but this doesn't currently seem to be mandatory.

With the above language, it should be sufficient to update RFC-3168 to cover this case at an appropriate time, rather than scattering further requirements in many documents.

 - Jonathan Morton