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

[Joe Touch <[e-mail]>]

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
>