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

Markku Kojo <kojo@cs.helsinki.fi> Mon, 08 March 2021 13:48 UTC

Return-Path: <kojo@cs.helsinki.fi>
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 C8C123A2A84; Mon, 8 Mar 2021 05:48:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi
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 5rpE6JiRKi6w; Mon, 8 Mar 2021 05:48:14 -0800 (PST)
Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60C73A2A82; Mon, 8 Mar 2021 05:48:13 -0800 (PST)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Mon, 08 Mar 2021 15:48:01 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=UXJVvijXgO4v6Rpm7 OtgbBk/I4wolna1poAH1uDKIT0=; b=kQQs9IgAVc8TYt1S/oqT44uuF2AkIRBDd 1LQoZ4OE2G10V9RGRdmgGvIbivbLFEDsYNzzOwPNH5V2KPiZE4Svqe97CYPxosiw gCaBx7ZykscSHVAREDJ//31BMIUW3e10cfS8KevKBjp91B+wJm8oJMZQtYMI7mGI yDaqOve9Tg=
Received: from hp8x-60 (85-76-5-58-nat.elisa-mobile.fi [85.76.5.58]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Mon, 08 Mar 2021 15:48:00 +0200 id 00000000005A1C65.0000000060462B10.0000123F
Date: Mon, 8 Mar 2021 15:48:00 +0200 (EET)
From: Markku Kojo <kojo@cs.helsinki.fi>
To: Bob Briscoe <ietf@bobbriscoe.net>
cc: Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, Joe Touch <touch@strayalpha.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
In-Reply-To: <1e038b64-8276-3515-ac45-e0fc84e1c413@bobbriscoe.net>
Message-ID: <alpine.DEB.2.21.2103081540280.3820@hp8x-60.cs.helsinki.fi>
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> <1e038b64-8276-3515-ac45-e0fc84e1c413@bobbriscoe.net>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_script-4815-1615211281-0001-2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/WSP16TjwS-vP3AaCv7cChVTqZmc>
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 13:48:18 -0000

Hi Bob,

this issue and text on it seems acceptable to me.

However, the other issue with the two contradictory SHOULD's - that I now 
notice I have never replied to - seems not ok, I think. I'm now 
occupied for the next few hours, so I'll come back with more detailed 
reasoning after the tsvwg meeting today.

Cheers,

/Markku

On Mon, 8 Mar 2021, Bob Briscoe wrote:

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