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

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

At this juncture, for an ECT(0)/ECT(1) mix across a set of fragments being reassembled, I would suggest using "any" (i.e., either is ok) at this juncture to avoid constraining what we may do in the future; in particular, this allows use of the value in the first or last fragment, both of which are likely to be convenient approaches for some implementations.

Thanks, --David

> -----Original Message-----
> From: Joe Touch <[e-mail]>
> Sent: Wednesday, October 9, 2019 10:29 AM
> To: Black, David
> Cc: Jonathan Morton; [e-mail]
> Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested
> Fragmentation/Reassembly text
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi, all,
> 
> I disagree with the suggestion below.
> 
> Pushing this “under the rug” for an indeterminate later date only serves to
> undermine the importance of this issue.
> 
> At a MINIMUM, there needs to be direct guidance in place until a “better”
> solution can be developed. For now, that would mean one of the following:
> - use the max of the frag code point values
> - use the min of the frag code point values
> - use “any” of the frag code point values
> - pick some other way (first, the one in the initial fragment i.e., offset 0), etc.
> 
> One of these needs to be *included at this time*.
> 
> If a clean up doc needs to be issued, it can override individual “scattered”
> recommendations later.
> 
> Joe
> 
> > On Oct 9, 2019, at 6:33 AM, Black, David <[e-mail]> wrote:
> >
> >> 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
> >