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 (EET)
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
>>>
>
>