[tsvwg] ecn-encap: (was: draft-ietf-tsvwg-rfc6040update-shim:) Suggested Fragmentation/Reassembly text

[Bob Briscoe <[e-mail]>]

Markku,

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

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/