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

["Black, David" <[e-mail]>]

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

I would concur that using a separate draft to cover that case at the appropriate time would be the better course of action.

Thanks, --David

> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: Tuesday, October 8, 2019 6:55 PM
> To: Black, David
> Cc: [e-mail]
> Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested
> Fragmentation/Reassembly text
> 
> 
> [EXTERNAL EMAIL]
> 
> > 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