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, 08 Mar 2021 15:48:00 +0200
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/ > >
- [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Sugg… Black, David
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: … Jonathan Morton
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: … Black, David
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: … Joe Touch
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: … Black, David
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: … Jonathan Morton
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: … Markku Kojo
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: … Bob Briscoe
- [tsvwg] ecn-encap: (was: draft-ietf-tsvwg-rfc6040… Bob Briscoe
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: … Jonathan Morton
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: … Markku Kojo
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: … Bob Briscoe
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:S… Markku Kojo
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:S… Bob Briscoe
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:S… Black, David
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:S… Markku Kojo
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:S… Bob Briscoe
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:S… Jonathan Morton
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:S… Black, David
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:S… Bob Briscoe
- [tsvwg] ecn-encap-guidelines reframing section Bob Briscoe
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:S… Black, David
- Re: [tsvwg] ecn-encap-guidelines reframing section Black, David
- Re: [tsvwg] ecn-encap-guidelines reframing section Bob Briscoe
- Re: [tsvwg] ecn-encap-guidelines reframing section Jonathan Morton
- Re: [tsvwg] ecn-encap-guidelines reframing section Jonathan Morton
- Re: [tsvwg] ecn-encap-guidelines reframing section Black, David
- Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:S… Markku Kojo
- Re: [tsvwg] ecn-encap-guidelines reframing section Markku Kojo
- Re: [tsvwg] ecn-encap-guidelines reframing section Markku Kojo