Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: SuggestedFragmentation/Reassembly text

From: Markku Kojo <[email-masked]>
Date: Sun, 17 Nov 2019 10:46:10 +0200 (EET)

Hi Dave, Joe, All,

Catching up ...

I agree with the modified new text as well as treatment of an 
ECT(0)/ECT(1) mix as "any".

I also want to repeat my comment that

  draft-ietf-tsvwg-ecn-encap-guidelines-13

added similar new text that alters RFC 3168, and it should be modified 
accordingly.

Thanks,

/Markku

PS. I missed Bob's response to my comment at the time, but will reply it 
separately at some point.

On Wed, 9 Oct 2019, David Black wrote:

> 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 <[email-masked]>
>> Sent: Wednesday, October 9, 2019 10:29 AM
>> To: Black, David
>> Cc: Jonathan Morton; [email-masked]
>> 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 <[email-masked]> 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 <[email-masked]>
>>>> Sent: Tuesday, October 8, 2019 6:55 PM
>>>> To: Black, David
>>>> Cc: [email-masked]
>>>> Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested
>>>> Fragmentation/Reassembly text
>>>>
>>>>
>>>> [EXTERNAL EMAIL]
>>>>
>>>>> On 8 Oct, 2019, at 10:51 pm, Black, David <[email-masked]> 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
>>>
>
>