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

From: Bob Briscoe <[email-masked]>
Date: Thu, 3 Dec 2020 14:06:19 +0000

Markku, all,

I am also only now catching up with the list...

On 17/11/2019 08:46, Markku Kojo wrote:
> 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".

[BB] Thanks. For the list, the current text that Markku is agreeing with 
is here:
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-11#section-5

Regarding reassembly of a mix of ECT(0)/ECT(1). I agree with David that 
the current text should handle this case that 3168 doesn't address.
And I agree with Joe that an interim way of handling it is needed, not 
just punting until later.

I see that all of Jonathan, David and you Markku are happy with 
reassembling a mix of ECT(0) and ECT(1) to result in either ECT(0) or 
ECT(1). (for now). I think we can go one better than that, still without 
precluding a more specific RFC later. Here's proposed text:

After the following para:

    During reassembly of outer fragments [I-D.ietf-intarea-tunnels  <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-11#ref-I-D.ietf-intarea-tunnels>], if
    the ECN fields of the outer headers being reassembled into a single
    packet consist of a mixture of Not-ECT and other ECN codepoints, the
    packet MUST be discarded.

Add:

    If there is mix of ECT(0) and ECT(1) fragments, then the reassembled
    packet MUST be set to either ECT(0) or ECT(1). In this case,
    reassembly SHOULD take into account that the RFC series has so far
    ensured that ECT(0) and ECT(1) can either be considered equivalent
    [RFC3168], or they can provide 2 levels of congestion severity,
    where the ranking of severity from highest to lowest is CE, ECT(1),
    ECT(0) [RFC6040].

Rationale: This avoids constraining future RFCs, but at least lays out 
all the interoperabilityrequirements we already have for handling this 
mixture. Then if an implementer wants to just default to choosing one, 
it hints that they should choose ECT(1).

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

[BB] I'll start another thread for this, rather than make this thread 
too unweildy.

Bob

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
                PRIVILEGED AND CONFIDENTIAL

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 3 Dec 2020 14:11:43 +0000

Markku,

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

[BB] On 15 Nov (before your email, but admittedly only by 2 days 
before), I had revised the text here:
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-14#section-4.6 

First, bear in mind that the scope of this draft is not IP fragmentation 
and reassembly. It is about lower layer re-framing.

So, this section has to deal with cases where packets are formed into a 
link-layer stream and chopped up into frames at boundaries that bear no 
relation to the original packet boundaries. In IP, the ECN marking on a 
fragment only ever contributes to one reassembled packet. But a L2 frame 
can cross packet boundaries, so the ECN marking of some of the frames 
will contribute to 2 (or more) packets, while others will contribute to 
a fraction of a packet.

So the fragmentation and reassembly text in RFC3168 covers only a small 
part of the scope of this ecn-encap draft. Indeed, I had intended that 
IP fragmentation/reassembly was outside of scope of this section, but I 
just noticed I accidentally left the word 'fragment' in the first 
sentence. If people agree, I'll remove it.

    The guidance in this section is worded in terms of framing
    boundaries, but it applies equally whether the protocol data units
    are frames, cells, packets or fragments.

->

...are frames, cells or packets.

Despite this difference in scope, this ecn-encap draft has fallen under 
the disagreements over fragmentation in the 6040update-shim draft. So, 
just so we don't all die before this is published, I took the same 
approach of writing broad hints at what a solution would look like, but 
removed any specifics, including examples. Then specifics can be dealt 
with in the draft-to-be that David has conjured up.

So what have I left in there? It boils down to the two somewhat 
conflicting requirements, in the last 2 paras; with no mention that each 
makes the other difficult, or how to resolve the conflict:

    1) ...SHOULD approximately preserve the
    proportion of PDUs with congestion indications arriving and leaving

    2) ...SHOULD ensure
    that any incoming congestion indication is propagated immediately

The goal of 1) is long-term: to avoid altering long-run marking 
probability (as I have been explaining), which determines the rates of 
long-running flows in steady-state.
The goal of 2) is short-term: not to defer congestion indications 
indefinitely (as Jonathan has been explaining).

Bob

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 3 Dec 2020 18:07:14 +0200

> On 3 Dec, 2020, at 4:06 pm, Bob Briscoe <[email-masked]> wrote:
> 
> I see that all of Jonathan, David and you Markku are happy with reassembling a mix of ECT(0) and ECT(1) to result in either ECT(0) or ECT(1). (for now). I think we can go one better than that, still without precluding a more specific RFC later. Here's proposed text:
> 
>    During reassembly of outer fragments [I-D.ietf-intarea-tunnels], if
> If there is mix of ECT(0) and ECT(1) fragments, then the reassembled packet MUST be set to either ECT(0) or ECT(1). In this case, reassembly SHOULD take into account that the RFC series has so far ensured that ECT(0) and ECT(1) can either be considered equivalent [RFC3168], or they can provide 2 levels of congestion severity, where the ranking of severity from highest to lowest is CE, ECT(1), ECT(0) [RFC6040]. 
> 
> Rationale: This avoids constraining future RFCs, but at least lays out all the interoperabilityrequirements we already have for handling this mixture. Then if an implementer wants to just default to choosing one, it hints that they should choose ECT(1).

This seems reasonable to me.  The text could do with a proofreading pass, but the technical content makes sense.

 - Jonathan Morton

---

From: Markku Kojo <[email-masked]>
Date: Mon, 14 Dec 2020 17:44:23 +0200 (EET)

Hi Bob, all,

apologies for the delay, now catching up again.

yes, handling mix of ECT(0)/ECT(1) like in the new proposed text below 
seems reasonable choice (for now).

I'll come back shortly with the issue in the other thread. It seems less 
clear, actually seems quite difficult to handle correctly for all 
foreseen cases.

/Markku

On Thu, 3 Dec 2020, Bob Briscoe wrote:

>       I agree with the modified new text as well as treatment of an ECT(0)/ECT(1)
>       mix as "any".
> 
> 
> [BB] Thanks. For the list, the current text that Markku is agreeing with is here:
> Regarding reassembly of a mix of ECT(0)/ECT(1). I agree with David that the current text
> should handle this case that 3168 doesn't address.
> And I agree with Joe that an interim way of handling it is needed, not just punting until
> later.
> 
> I see that all of Jonathan, David and you Markku are happy with reassembling a mix of
> ECT(0) and ECT(1) to result in either ECT(0) or ECT(1). (for now). I think we can go one
> better than that, still without precluding a more specific RFC later. Here's proposed
> text:
> 
>       If there is mix of ECT(0) and ECT(1) fragments, then the reassembled packet
>       MUST be set to either ECT(0) or ECT(1). In this case, reassembly SHOULD take
>       into account that the RFC series has so far ensured that ECT(0) and ECT(1)
>       can either be considered equivalent [RFC3168], or they can provide 2 levels
>       of congestion severity, where the ranking of severity from highest to lowest
>       is CE, ECT(1), ECT(0) [RFC6040].
> 
> 
> Rationale: This avoids constraining future RFCs, but at least lays out all the
> interoperabilityrequirements we already have for handling this mixture. Then if an
> implementer wants to just default to choosing one, it hints that they should choose
> ECT(1).
> 
> 
>
> [BB] I'll start another thread for this, rather than make this thread too unweildy.
> 
> 
> 
> Bob
> 
> 
>
>       Thanks,
>
>       /Markku
>
>       PS. I missed Bob's response to my comment at the time, but will reply it
>       separately at some point.
> 
>
>             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
>
>                   Subject: Re: [tsvwg]
>                   draft-ietf-tsvwg-rfc6040update-shim: Suggested
>                   Pushing this “under the rug” for an indeterminate
>                   later date only serves to
>                   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:
>                   - pick some other way (first, the one in the initial
>                   fragment i.e., offset 0), etc.
>
>                   If a clean up doc needs to be issued, it can override
>                   individual “scattered”
>                   recommendations later.
>
>                   Joe
>
>                               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
>                               authoritative (where it
>                               doesn't conflict with other
>                               rules) is acceptable, but
>                               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.
> 
>
>                               Subject: Re: [tsvwg]
>                               draft-ietf-tsvwg-rfc6040update-shim:
>                               Suggested
>                                     On 8 Oct, 2019,
>                                     at 10:51 pm,
>                                     Black, David
>                                     <[email-masked]>
>                                     **NEW**: Beyond
>                                     those first two
>                                     paragraphs, I
>                                     suggest deleting
>                               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
>                               authoritative (where it
>                               doesn't conflict with other
>                               rules) is acceptable, but
>                               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
> 
> 
> 
> 
> 
> --