Re: [tsvwg] New rev of draft-ietf-tsvwg-ecn-l4s-id-17

Sebastian Moeller <moeller0@gmx.de> Fri, 21 May 2021 21:27 UTC

Return-Path: <moeller0@gmx.de>
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 C915E3A213B for <tsvwg@ietfa.amsl.com>; Fri, 21 May 2021 14:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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=gmx.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 mXNrT11TFfVV for <tsvwg@ietfa.amsl.com>; Fri, 21 May 2021 14:27:38 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 A4ED23A213A for <tsvwg@ietf.org>; Fri, 21 May 2021 14:27:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1621632404; bh=eoB28KBWAnzwgXJ8ZvCR5aivbsQDYMWxzqiF/NSfXXw=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=dYxRb715J0gZTaGYs0pQr68I+iiKdKDs5wd3SN7J2BBFA5FK6X3dT8eI5ylNUdpcC HqEPage/NvzwPvxe357ahNom1qVyXfZSs2CJkV6+NqLb7RI1u9zuD+qAYsBAXVsNPV Z/SprbNOfyvHHL5dfD1tFXu4g/lWJcR+ZCWAaWpM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.42.229] ([77.1.116.62]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mlw7f-1l38QC3eL5-00j5mj; Fri, 21 May 2021 23:26:43 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <f8ed1105-d1db-55ce-eb1f-00de8a83b0e8@bobbriscoe.net>
Date: Fri, 21 May 2021 23:26:40 +0200
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "Black, David" <David.Black@dell.com>, Wesley Eddy <wes@mti-systems.com>, tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F147A3D-BD68-4F0A-89FF-9A92284FF0A5@gmx.de>
References: <162158815765.22731.15608328324211025925@ietfa.amsl.com> <f8ed1105-d1db-55ce-eb1f-00de8a83b0e8@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.20)
X-Provags-ID: V03:K1:elQCv+ZiS4AG8FNyezU9pL8wpOaRo1UMdwwq2X8a4NwztLTim69 Xj3oanEBGeK+XbjtXNDXWAGd5xiVAsnmzS0a40VPbFUaTM5H/ZvF/yBCrv6VwyW2r5ofPZk i5yo+05Om4yVUWSINkzzU5OG2gzyncHYV7zQezADHwnZvEaD1f+b0x/FtIrSA5sk/vHUcAI VM8+wrBj3UOjwuaCIpB/A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:POnfZSlifmk=:a5gVupWeVnW3DXTN9YMeMw NyCmO7f3OHQHTWUy2L8aDLPlIbOLnCMhEoYQ0YhKdB9KUWk13QcdzMn2Uspmee4eIi84vMP5r VxGmnvKDSBbXUsKooQKrI6L4dZQ2TNXPM6yv2Th+i2/NQ8qo92nAnoh++i9wnvco3PT3NGfxO XjVbZAjcGZ6Cf+1Ex3i+4J5v5xV5LfKwSAguWtMglVJFBf7qTyeNZoWefRveENKINr4vtrqoP /wQvP9GSoZtoTUfjlfRZ+c3B2hZChXwJseDziq9d2UP6Zo0rEtllKOqn2RdDMsNGbngtHxbx5 MnFGLF6QNhw9PSi29phwx2qGVKolhfQhUw03JUJH6GthDKtAMxsw8LjZ+s4hLQ3Eaxq73AFy7 EzszKXYTGWxSgpASOQqF+ivhJzdIYih91qNoH4/ebJ6NO6EScpcaQJSHrQ2ITZO28fr9wDTY2 NPffhVvAgociH4ISTxzEDLxIIuPA+CwL3p/nM6cHN/plWeL7Fjg7r0HBWoJ5RXHapINb+4vSN dNFN5TAN6VttC2VgrEdFBbCnk9K4PA5uGOJBbuzD8hk8eFnnCAYgIldMH45iy9NpXmumHsFrU AyfJClMNi3VB76J57d4zVdnTqSE8u1kYp3Kak/Ma127QyKHHRzhMKSlE4n9vyiRH6NXTmAsAq u5NXTStxqf35JFxQaJ6REr/4slKE21P/+Y5Yvf6SMm25jqT6mVR7BAYM2wXpTZxey0xb426aZ oKMRqKFJvBY092UxgMBcUTQKkOwqUiwBDbkisz2N63c1okFmlNO+NB48L4wkfdBxY9tvMDC+R 1c07BOAkx/P4PmkJn5CWtEZM0to/ZLiqg3VkywLXmGohk8ILnWhLEtWc3IsLwxN0zkD2e/NbV a8JDGPoJeQMMs97/t41nsAcWg01MSBzEUWR+Ysqj2wPWcTCKDAoYwUKCZphrNeuEyWGZLwFbG EnnmmtOvTISimSJ3KkScSSJElVqMkKeTT5YJKz9w5guh9uApVZSoAsV0z1xPgI5sMGywa1iMy fN1MKh+ARW6Qt3/q7mRZ1FNwy386WwF7tF1hm+PmXCxMrKF/XDTgcgvUjA2DoIDqIT5Jw4qTF 32hkvQpHrQPogIioz62J1afPA0vSi1n4QdkQB/mKPpfH9nCJCSUruzSzUKL4AZlF8SOCzJnOf my2smdVYaRUxuVgKt8QD4u5RoDFMfyYEuK/TQfuD92d2cV30hw45sKwjVYALybOdVdRyU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/iJgobVCDGerPKu0mJQvawAJ9d9E>
Subject: Re: [tsvwg] New rev of draft-ietf-tsvwg-ecn-l4s-id-17
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: Fri, 21 May 2021 21:27:43 -0000

Bob, chairs,

section 6.2 with its, "use two SAs, one for ECT(1) and one for the rest" seems a bit limited since it ignores that VPNs might propagate both DSCPs and ECN bits between the layers, so IMHO a better approach might be to recommend to treat DSCP+ECN bits as one aggregate byte (let's cal it TOS ;) ) as the extra ECT(1)-SA seems to be required for all SAs that already exist to deal with multiple supported DSCPs. So in a sense the recommendation would be to double the number of SAs.

Also:
"and the current draft of DTLS 1.3 says "The receiver	
 	   SHOULD pick a window large enough to handle any plausible reordering,	
 	   which depends on the data rate."  However, in practice, the size of	
 	   the VPN's anti-replay window is not always scaled appropriately."

L4S on a 10 ms path under load can introduce re-ordering in the range of 50 ms (roughly twice the difference between the L- and C-queue delay targets), re-ordering tolerance 5 times of the path RTT seems to be a bit on the high side to expect, no?




Regards
	Sebastian


> On May 21, 2021, at 11:21, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> Chairs, list,
> 
> We've posted a new rev of draft-ietf-tsvwg-ecn-l4s-id-17 attempting to address all the discussion since the last posting just before the interim. In particular:
> * review comments on a careful read from Gorry and the chairs
> * the VPN anti-replay problem
> * added an out-of-band test for an RFC3168 ECN AQM in a shared queue.
> 
> There are a couple of outstanding discussions, which I'm sure will continue on the list, e.g. the role of RFC4774 and whether to remove any of Appx C. But it was considered better to get the queued up changes out, to re-base the discussions.
> 
> This is quite an extensive set of changes, so pls check and pass any comments to the list.
> 
> Thanks for everyone who is contributing, and particularly to the chairs for continuing to referee this all. We've added appropriate thanks in the Acks section.
> 
> 
> Bob
> 
> 
> On 21/05/2021 10:09, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Area Working Group WG of the IETF.
>> 
>>         Title           : Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)
>>         Authors         : Koen De Schepper
>>                           Bob Briscoe
>> 	Filename        : draft-ietf-tsvwg-ecn-l4s-id-17.txt
>> 	Pages           : 57
>> 	Date            : 2021-05-21
>> 
>> Abstract:
>>    This specification defines the protocol to be used for a new network
>>    service called low latency, low loss and scalable throughput (L4S).
>>    L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
>>    layer that is similar to the original (or 'Classic') ECN approach,
>>    except as specified within.  L4S uses 'scalable' congestion control,
>>    which induces much more frequent control signals from the network and
>>    it responds to them with much more fine-grained adjustments, so that
>>    very low (typically sub-millisecond on average) and consistently low
>>    queuing delay becomes possible for L4S traffic without compromising
>>    link utilization.  Thus even capacity-seeking (TCP-like) traffic can
>>    have high bandwidth and very low delay at the same time, even during
>>    periods of high traffic load.
>> 
>>    The L4S identifier defined in this document distinguishes L4S from
>>    'Classic' (e.g. TCP-Reno-friendly) traffic.  It gives an incremental
>>    migration path so that suitably modified network bottlenecks can
>>    distinguish and isolate existing traffic that still follows the
>>    Classic behaviour, to prevent it degrading the low queuing delay and
>>    low loss of L4S traffic.  This specification defines the rules that
>>    L4S transports and network elements need to follow with the intention
>>    that L4S flows neither harm each other's performance nor that of
>>    Classic traffic.  Examples of new active queue management (AQM)
>>    marking algorithms and examples of new transports (whether TCP-like
>>    or real-time) are specified separately.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/
>> 
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-17
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-l4s-id-17
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>