Re: [tsvwg] path forward on L4S issue #16

Sebastian Moeller <> Tue, 23 June 2020 07:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E8D03A17EB; Tue, 23 Jun 2020 00:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Status: No, score=-2.347 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7AZebnu251iM; Tue, 23 Jun 2020 00:25:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E7A23A0979; Tue, 23 Jun 2020 00:25:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1592897113; bh=23TVWeHcTKv1V9e/Oxep7V5QBZCxBPXED+oqbBxztCw=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=V9FOavLApxU9dzJUAFLKoJVZp3RkCyGNAHs9EcHoHTb4pswwLJNJ1GZF8c6SMUD6M Yhu/47hufoMn++RrIuPkXNmbAdKjtxVCTfX9DyijO0/jjQz+aspdRvW8l6v+WfO48z xN9eW+0UosUUTRxNr7UmiOLtCJm8Ag0fqmhvkEks=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1MYvY2-1jIt0j0nqK-00UtfF; Tue, 23 Jun 2020 09:25:13 +0200
Date: Tue, 23 Jun 2020 09:25:13 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----NOZUJ3V2KH3ARHR8HO7LX1Z04H5TC7"
Content-Transfer-Encoding: 7bit
To:, Wesley Eddy <>, "Rodney W. Grimes" <>
CC: "Holland, Jake" <>, "" <>
From: Sebastian Moeller <>
Message-ID: <>
X-Provags-ID: V03:K1:MfPoBhIO/l8ljDO9QjzHsZLvPsOcb6LIQ60wdarnd77coi33bdJ y35GlQTv8U8mK7rNgqWmVOWV8nGo4VBRsfYmO+PT0AsxyS2clNppZEaDVcflnFhD7/tQm4C CmJdlGuRUdTP92N9/BMcreC+BGzhwWFBabQELW0VgyQEhmg6L5j7EA4i61+4T/9T6d90ydI uOGhzLPqTpF3ne+kFb8sw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:BgE+hx3/NiQ=:wRceqL7DungMwpRuTTyjJ4 CHsu5A4lIrCQwiLEaTJ1HVE3Hco5nuBGmaN9RbcFSU4+nNm8aQh9OrJXImzXuJ9jJ36o4RS3D 1TRtSNcmNIXdsJAr+MMBd4M8xqAWhThf3DJQJgp3oMLAla7X0qUDn8XUtWm4j42/oUJVVb5uz 1VpD8WwCfYu15t6V31VIPVfe8B6foy1Lvqe+yanBLJ2UJCsk7KAY8mgDuwrVu1kDFf9JnXGI2 ocHnpFJ2ZTEDJ2HUM3m9iAQJZ0DD2cV0jKrNxElH/SRO5e3Pe9OkGhwUZd/GtwaQP95Sx+Cfu ubqKMLHdbXRv/6phlIuq2+wuaPUqdWAzvL8so+xwxo/VGaxViQQ37TAJVuXLwAskAr974cC48 nn3n6JWCcDidWkDViSAro7Y6AKb1MUgLK7zyOJu+mx/y4llsFQ3yf5wYFCgWQtGYT+h29yeOb iwypP35OgTAFiGeqVcoWBlVYFMYdMtgW4gxHkoLbotxHxLwTZvyQMto4kf7yL/cN3BhxCLDwl LPdZ3K0VHkTc9yHRnOiHRCGNVqx91yApCBbGRGWjSBbher9qU88/tSP5nUWMViyIHS4CJajJ8 x5cx+4ZQ74zYpIFWHEjU4oI7qo6OQqkZqwJ5OhSWZPKCVWdUY8yp7EHllzyV+VO7CTxQNn+vT cFQxpGv7pGr2UdSeKcBz+jUTe4ke5nYGyQxJRLCwtwIye4R1mhQ7wN0sQvrQW54+Y/3E0kqz8 GFJ8oRh+La+WtcLGTlj2Rs7RVwmn/fvD/y3E2RDZOGFcRh/6gx6qTyuctzq19fwl3bx3dyf+v Nw3xlPQFs+U9WS+uWnBzleo3w41WpN8I9a8nfKpQJTeafh3vVlqO0GrhbjxbVDjWiwa5IrlnQ 3TTpd3h80VTCwWB0Rb3eAGzBWexca3qLDP08bDzJvdNkUIXkzLR/ua9r8OKyR/4sCrQAp/QjP mTv3lZMZwvYOCtn21yIR1NRoVY9WkN2GU8IbqkiRaCj30uvOqKurcv2ET1nsSO7xRaqA+82y7 JE2ddFeDlFtdvXfvElr27YeIM0Dxu1u1XWr9jg4eXJqEJsHwz2A4pdE+DW1500vmmxCr4B0P5 JQIo/ucEkwJgsfbYjqywVAhqwY1pePJwa9DUe1fuBJnojXVCPLx0DPC5RfSPf2Hr+6/6wC9Yk k4bIMbkWVyWPDeynwkIKqReqA7zmMHCwf3KsbDJWk+YGIDB9Q56SWoXLFx06T1q2auwTo=
Archived-At: <>
Subject: Re: [tsvwg] path forward on L4S issue #16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jun 2020 07:25:34 -0000

Hi Wes,

Sure Global dscp traversal might not be a reality right now.
BUT that did not stop the introduction of the NQB internet draft that in essence tries to standardize a PHB/dscp that is pretty much the missing L4S dscp*. 
AND there are currently no data backing up the assertion that L4S will actually be useful in long-haul paths to beginn with**. For the only tested use case, essentially short RTT low hop count CDN to end user path, dscp traversal will not be a showstopper, just look at the rationale in the NQB draft.
And given the status of the NQB draft, this might reach maturity/publication well before the L4S drafts, so the appropriate L4S PHB will be defined although it is claimed that dscp will not work, anybody else seeing a disconnect here?
So instead of trying to optimize for universal roll-out maybe it would behoofe the L4S effort to aim a bit lower and gain some real world experience first, like walk before you run? 


*) Currently the NQB draft excludes capacity seeking flows, but could be amended to allow such flows, if they use 1/p congestion signaling. As far as I can tell NQBs reason for existence is to have a method to have endpoints steer non ECT(1)-flows into potential LL-queues along the path. Such a method is also hinted at in one of the L4S drafts, so in spite of RSVPs being declared insufficient in all likelihood they will be used in the L4S ecosystem.

**) Testing with a single netem instance giving a constant delay of X milliseconds is not a realistic test of a high RTT high hop-count path, it is rather a test of a condition exceedingly rare in the real world, high RTT low hop count... I have been asking for realistic tests for some while now, and am beginning to assume that the lack of data might be an indication that the current L4S implementation and design simply does not cope well with the requested realistic conditions. With the existing testing harness used for the supporting papers testing the realistic scenarios I laid out in past emails should have been relative easy. I for one an done with giving L4S the benefit of the doubt.

On 23 June 2020 06:39:18 CEST, Wesley Eddy <> wrote:
>Hi Rod, I didn't say any of the things you're asking about; only that 
>DSCP global traversal does not appear viable to depend on in the near
>On 6/23/2020 12:27 AM, Rodney W. Grimes wrote:
>> Hello Wes,
>> Excuse me, but L4S itself even defined DSCP as one of the
>> alternative mechansims to ECT(1).  Are you saying we should
>> remove those alternatives from the draft?
>> Further on several occasions David Black, and others have asserted
>> DSCP is a viable path forward for L4S.
>> How are these solutions suddenly not to be included in the
>> of what may be a way to address Issue #16?  These are solutions that
>> can be used today, though the global traversal is not a requirement
>> for them to be used, and they are infact being used to conduct SCE
>> experimentation.  I find it unsettling that L4S proponets would not
>> consider this as a way to produce data that might influence the WG.
>> No comments inline,
>> Regards,
>> Rod
>>> Hi Rod, I just have a short comment from what I have seen as the WG
>>> interests.
>>> I have not noticed much interest in DSCP global traversal,
>>> from the parties that would need to support it.? Since that is also
>>> explicitly against the DiffServ architecture that incorporates
>>> re-marking, suggesting it is a rather big change to all of how
>>> has been defined, unless I misunderstand.? I believe any activity or
>>> proposals on global DSCP traversal are very interesting and totally
>>> to discuss, but can't be a gate for L4S.
>>> On 6/19/2020 11:14 PM, Rodney W. Grimes wrote:
>>>> Jake,
>>>> 	Thank you for spending the time to collect this
>>>> detailed summary.
>>>> 	I believe you left out: (adding one to your last one and listing)
>>>>    7.  Use a DSCP to seperate the experiment, leaving ECT(1) and CE
>>>>        currently specified in the L4S draft.
>>>>    8.  Use a DSCP to classify the traffic as L4S and leave ECT(1)
>>>>        altering CE semantics.
>>>>    9.  Use a DSCP to classify the traffic, and use ECT(1) as a 1/p
>>>>        leaving CE semantics in place.
>>>> 10.  Dropping L4S as over promising and short delivering with
>>>>        that almost certainly sets it up for a failed deployment.
>>>> Note that in all 4 of these solutions bleaching is unlikely to be
>>>> used if there are problems, and the experiment is rather trivial to
>>>> terminate if there are problems.  These also keep ECT(1) avaliable
>>>> for a future non-experiment version of L4S should the experiment
>>>> or something else should it fail.  7 to 9 can even be started today
>>>> without an IETF consenses and some real operational data created.
>>>> On the side, IMHO, the work going into L4S would be better spent
>>>> a)  DSCP global traversal
>>>> b)  ack thinning being underspecified such that it creates protocol
>>>>       problems.  Specifically the fact it tosses out changes in
>>>>       bits by thinning packets with different bit values.  This was
>>>>       identified years ago and left as a problem, it needs cleaned
>>>> c)  Revision to RFC6040 and other tunnel related drafts to clear
>>>>       the issues there.  Again, identified years ago and left to
>>>>       up.

Sent from my Android device with K-9 Mail. Please excuse my brevity.