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

Bob Briscoe <ietf@bobbriscoe.net> Mon, 08 March 2021 12:35 UTC

Return-Path: <ietf@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 54E673A0DFF; Mon, 8 Mar 2021 04:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Level:
X-Spam-Status: No, score=-1.433 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_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 s5LTuGKOISsf; Mon, 8 Mar 2021 04:35:43 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (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 3F8D63A0DD8; Mon, 8 Mar 2021 04:35:43 -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=pi1sHLEBjMGoLON8xNiMdTNqhd3BUqO9HzA+P3u4aWk=; b=O7gGUvRcUQ0xZy0RII50WZUNf WxgBHypfIPZWJK0BMF2IjOztXSOBZ80oGfZTLZmUSS01hZkG9wSFptGus1DkPiauqfUpzM0Rq4TNh h2wV426RUQ0cApetzJk/v4aFqHN3P3LSTgflJB6vRaZDzDWo2LLkqV3/ao9MIMfTzDuGNahi9DjN2 psZi1b2+DnCbh3ddUximpXBkrJjYkoIPs1mMu6ei7l9Z9hZC1hH3v82r24MhnXTiPil0/HwDb2Ely HyRm7AFOVRtUDqYs4TaoatwaUBe5pHsrJRTgGyZDrbvAfujcloHXvQjNVtfjfqgWGFky0b3zvi1nX bmlRe7iAA==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:35976 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1lJF6q-0004jK-TI; Mon, 08 Mar 2021 12:35:41 +0000
To: Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
Cc: Joe Touch <touch@strayalpha.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Jonathan Morton <chromatix99@gmail.com>
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> <9024d91a-bb08-fb45-84f8-ce89ba90648d@bobbriscoe.net> <alpine.DEB.2.21.2012141735030.5844@hp8x-60.cs.helsinki.fi>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <1e038b64-8276-3515-ac45-e0fc84e1c413@bobbriscoe.net>
Date: Mon, 8 Mar 2021 12:35:39 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.21.2012141735030.5844@hp8x-60.cs.helsinki.fi>
Content-Type: multipart/alternative; boundary="------------718A6BC8E81D771BE4096503"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/zKqL68lTFDPNHKPd6CSFo5WvqB8>
Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: SuggestedFragmentation/Reassemblytext
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: Mon, 08 Mar 2021 12:35:48 -0000

Markku, chairs, all,

Having reached agreement on the text last Dec, I then went and dropped 
the ball and forgot all about this draft,... and ecn-encap-guidelines.


    == ecn-encap-guidelines ==

I shall upload a new rev shortly with the following single diff that I 
noticed during the meeting last Nov, and said I would do at the next rev:

  4.6.  Reframing and Congestion Markings

     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.


    == rfc6040update-shim ==

I shall upload a new rev shortly, with the following 3 paras at the end 
of S.5 on ECN fragmentation/reassembly:

Para 1 is just moved up from the end but otherwise unchanged.
Para 2 is unchanged.
Para 3 is the text agreed on this list last Dec subject to further 
checking, with one exception: I removed the citation of RFC3168 after 
"equivalent".
     Reason: The citation of RFC6040 at the end is the relevant one, 
'cos it introduced the mechanism for ECT(0) and ECT(1) to be either 
equivalent or two severity levels. In this respect it updated RFC3168. 
So it would not be appropriate to cite RFC3168, which only said the two 
were equivalent. If we cited RFC3168 here, it could be interpreted as if 
we're saying two RFC give conflicting definitions.

     Section 5.3 of [RFC3168] defines the process that a tunnel egress
     follows to reassemble sets of outer fragments
     [I-D.ietf-intarea-tunnels] into packets.

     During reassembly of outer fragments [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.

+   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,
+   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].


If any of this isn't acceptable, I'll have to post another rev, but I 
think it's what was agreed.

Cheers



Bob


On 14/12/2020 15:44, Markku Kojo wrote:
> 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:
>
>> 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], 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
>>
>>

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