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

Bob Briscoe <in@bobbriscoe.net> Thu, 03 December 2020 14:06 UTC

Return-Path: <in@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E31E3A0BAD for <tsvwg@ietfa.amsl.com>; Thu, 3 Dec 2020 06:06:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A6EIDH8Bgri for <tsvwg@ietfa.amsl.com>; Thu, 3 Dec 2020 06:06:24 -0800 (PST)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B4E3A0BD9 for <tsvwg@ietf.org>; Thu, 3 Dec 2020 06:06:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aupQRp4LvehLcwcXRThB7lSZHqyzLm6RbtJraBW/pWk=; b=q/uy+IeebfHm0fpGLKHaEYIxt 9yeNRByO6woxhKMHF59LpssRI2ZVv8Ss0Flp+ZyDfYwRN5WXZuE7ydmOup1FaJfHtT4j8fVNZIW9M sNalEOHeTp5P60PtRtUNa5iQGzGE3XVYNkZ5Ak8JLMoxPIBr7y+eVSNHAeFI70lFkCE+gbKYaChIW sMqs3Q8bP4fqvFxOu9nHTOGkvuk/qpEAcOY6GqkK/0CExUr1sGpjOOidY+PjghnjrRDxLTvn5ZOec 0tQE/kNqU0TTbuwstFFB/WfxIFX6S7T8s45taJhHmYYG3ABQq1lcs9FaCZxxm9+lqQfL4OSpB/s3M mNpYJz2OQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:47046 helo=[192.168.1.8]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <in@bobbriscoe.net>) id 1kkpFT-00Cjfl-EC; Thu, 03 Dec 2020 14:06:20 +0000
To: Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>, David Black <David.Black@dell.com>
Cc: Joe Touch <touch@strayalpha.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <CE03DB3D7B45C245BCA0D243277949363076629A@MX307CL04.corp.emc.com> <CE03DB3D7B45C245BCA0D24327794936307662EA@MX307CL04.corp.emc.com> <1920ABCD-6029-4E37-9A18-CC4FEBBFA486@gmail.com> <CE03DB3D7B45C245BCA0D2432779493630768173@MX307CL04.corp.emc.com> <6D176D4A-C0A7-41BA-807A-5478D28A0301@strayalpha.com> <CE03DB3D7B45C245BCA0D24327794936307688C5@MX307CL04.corp.emc.com> <alpine.DEB.2.21.1911171041020.5835@hp8x-60.cs.helsinki.fi>
From: Bob Briscoe <in@bobbriscoe.net>
Message-ID: <9024d91a-bb08-fb45-84f8-ce89ba90648d@bobbriscoe.net>
Date: Thu, 3 Dec 2020 14:06:19 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.1911171041020.5835@hp8x-60.cs.helsinki.fi>
Content-Type: multipart/alternative; boundary="------------5BEBF6ED81096498D011DA9B"
Content-Language: en-GB
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/wfVK8_jwRK76-Z2BoPDcQ2hR7EE>
Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: SuggestedFragmentation/Reassembly text
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 14:06:27 -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 <touch@strayalpha.com>
>>> Sent: Wednesday, October 9, 2019 10:29 AM
>>> To: Black, David
>>> Cc: Jonathan Morton; tsvwg@ietf.org
>>> 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 <David.Black@dell.com> 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 <chromatix99@gmail.com>
>>>>> Sent: Tuesday, October 8, 2019 6:55 PM
>>>>> To: Black, David
>>>>> Cc: tsvwg@ietf.org
>>>>> Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested
>>>>> Fragmentation/Reassembly text
>>>>>
>>>>>
>>>>> [EXTERNAL EMAIL]
>>>>>
>>>>>> On 8 Oct, 2019, at 10:51 pm, Black, David <David.Black@dell.com> 
>>>>>> 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