Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: SuggestedFragmentation/Reassembly text
Markku Kojo <kojo@cs.helsinki.fi> Sun, 17 November 2019 08:46 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 F2A8B1200C4 for <tsvwg@ietfa.amsl.com>; Sun, 17 Nov 2019 00:46:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 9KJpeOKo-rtz for <tsvwg@ietfa.amsl.com>; Sun, 17 Nov 2019 00:46:39 -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 CD4DB12007A for <tsvwg@ietf.org>; Sun, 17 Nov 2019 00:46:38 -0800 (PST)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Sun, 17 Nov 2019 10:46:29 +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=xIFcIAxwU/0fqjegr Z1Lxh9K8BdfmqJTcDkHa2EifsA=; b=X76jrsOYVySJnfHdfN0ut/9tF+Ua9h51S AOTj4COfzlko36r2XC+zasP03kZaNEhYuSjB+tivgvirRn2oxo1i/CYyyoYHO/O9 XVLGPh79ku/bXps9RJunQBPLTHn/skX5dc9r4YE1mV7wHGWbF+xMecwV9g8rd4tC ZYxT6LNfgg=
Received: from hp8x-60 ([38.98.37.141]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Sun, 17 Nov 2019 10:46:22 +0200 id 00000000005A02E2.000000005DD108E0.00006BE8
Date: Sun, 17 Nov 2019 10:46:10 +0200
From: Markku Kojo <kojo@cs.helsinki.fi>
To: David Black <David.Black@dell.com>
cc: Joe Touch <touch@strayalpha.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936307688C5@MX307CL04.corp.emc.com>
Message-ID: <alpine.DEB.2.21.1911171041020.5835@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>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_script-27660-1573980389-0001-2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/wSbY_l30jyPGJnKBjqMnuPOYQNE>
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: Sun, 17 Nov 2019 08:46:41 -0000
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. 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 >>> > >
- [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