Re: [tsvwg] [Ecn-sane] Comments on L4S drafts

Sebastian Moeller <> Fri, 19 July 2019 21:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 151F812011F for <>; Fri, 19 Jul 2019 14:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.349
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, SPF_HELO_NONE=0.001, SPF_PASS=-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 Mja0NXvVCZuK for <>; Fri, 19 Jul 2019 14:50:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23CF71200E0 for <>; Fri, 19 Jul 2019 14:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1563573002; bh=uC+NJXiRhORv8398tPR7eHdM6i7DqBrXmOeTnasZ/pU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=K7UcihGEM0kHD4npl9JPm6p/s63WmUY+UXLpuZihNNKn7XdPzXNYNYxvq2WqzxaB9 kwF6Evu9yDSTJO3dvo+J1QvBLKcpo95KrRddJI40IaYeuJRoVXzzfGXM1DSLY1bFab tb/u/llwQ5IdYfF2bZrLc0frch328Q6sHrKV8PuY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([]) by (mrgmx105 []) with ESMTPSA (Nemesis) id 1Mqs0X-1iAx231ewD-00mpAg; Fri, 19 Jul 2019 23:50:02 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <>
In-Reply-To: <>
Date: Fri, 19 Jul 2019 23:49:58 +0200
Cc: Dave Taht <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Wesley Eddy <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:Vzgb6J8RLdEs5+Ratm33p+Ef0uHXpeZuAYqkvGtEBwsbv9CxmLa K5D/z1qNEL9TzDRkOd+EDQSaykdN2FXb0OHMOKhrsBmHY3nFl2F1J2r23m0V8ZwWpohBDxh Woeq1MZJPY9/9eoLSCm41VVNx1GVZwFrJtDO6zHUeOYObgX+AFboLozuClY8flJTY78Bbwf YvYnj72ftysN6+HmH1Akw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:yHP1zxIfK0M=:01njOZ0mf/4G+1d//drjKe Q+NhT9kfOlDKX3m6YtMWigd9FU/vHqL+vc6cJUU+hwxqI8FxVQXQvKHv7ZcupAOBfW5wNPICw DcFRPPRlTF4gXwFJ0a1sdIZugwMOXRwhTYZ1qf0y/uWg/5ouYsVAWsAr/qeyqlZbPTlvRopCy f7VTzLOs4N3WO4iGn5ehuteIXuU+rhDcLQ4kwlS0ZbcQ+Ck/k/qTHLr6GucL5wwOCVtnxAvg4 I0gY15jvRgQbd4TH7YWz/MD+gj3nzu3sPZhdkvf67o5I0Q2aOVL1+h1top3UmgA8dz1V0d4yf pQFRKBBt+K0sQJHaVvz2nmPp6FHOCCGfx0kLI5pBeo1dfE4YcKjDvWVzd84hx91+/jm2WVbr5 hlujqC2ythAQgz6dPku2pHqcbgjh/KASn4JvvwtPRzDRgpOZAwQQ3FC0BtOJFIqgDf05OYTEk OL4nSEMpBZD68ONpMFTvNtBlPp8kUh68i5AkJDkT7oMVmXGB6auk/eR5hODNic7QBd61WqI29 udfHxSWnWnG24uAgVqv6Jnmetf2LT0EazAZ39F5AkXSYPTvdX5FoHn+HtRmxtU1MF2s3rnhwV hvUg6VBarD4g97yYx7Oe6vcJEUUWf8XucPYws5bVUN+nqhr9oOUgFPRYdzKHav0YrK0clbVUO UFTPzlkwtVQWl8zUuUmpfE0ueA94ArU5CLkd328ebXulf/ZNb8G0JbnfUHL8KoQ7rfwdpaCaa +07ZGKw3hxh25N+nQyAnfVs0oJsvYF85R+BhLlQWxhSBTXJ9xO2sTrh32ctzFr+BA88pzDyL7 k1aNsDzUZ3swWUy5e3wsZ9gD6G4KURqB3t47ImjEX2BKObqOAVia4ADBWNy7E79yd6jzzhGxX JPN3pXGPheLATiov5zMXYBHpbca9YAjf7ljJRe3udpY1QJtLMJLIF/jPWcDKqAP8jlHVofhxB dAtQVjQC/cknv2pRy1Z3tSysmyJ1kX4bpiXTu1hwRjKfd3uvakSU3nQAxV5RU8bRJvVhDSHEw tlt1pwuLWeEtdCHVsmpXBrtRo44y4EoC55RmV3tPjNb1DCWe+1g3tKI7mGBnSzUtYqW0rNiKk eHUdSCYllc9OZc=
Archived-At: <>
Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
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: Fri, 19 Jul 2019 21:50:13 -0000

> On Jul 19, 2019, at 20:33, Wesley Eddy <> wrote:
> On 7/19/2019 11:37 AM, Dave Taht wrote:
> [...]
>> In particular conflating "low latency" really confounds the subject
>> matter, and has for years. FQ gives "low latency" for the vast
>> majority of flows running below their fair share. L4S promises "low
>> latency" for a rigidly defined set of congestion controls in a
>> specialized queue, and otherwise tosses all flows into a higher latency
>> queue when one flow is greedy.
> I don't think this is a correct statement.  Packets have to be from a "scalable congestion control" to get access to the L4S queue.  

	With the current proposal, a packet needs to set the ECT(1) codepoint, there is _no_ checking whether there is a "scalable congestion control" operational on this flow. Even worse every CE-marked packet will be put into the L4S queue; the latter is a consequence of the currently preferred choice of using ECT(1) as L4S classifying bit. Sure the queue protection feature might help to demote flows not playing along the L4S rules back into the RFC3168 queue, but queue protection is advertized as optional....

> There are some draft requirements for using the L4S ID, but they seem pretty flexible to me.  Mostly, they're things that an end-host algorithm needs to do in order to behave nicely,

	Except there is no real enforcement/measurement whether flows "behave nicely", at least as far as I can see.

> [...]
>> So to me, it goes back to slamming the door shut, or not, on L4S's usage
>> of ect(1) as a too easily gamed e2e identifier. As I don't think it and
>> all the dependent code and algorithms can possibly scale past a single
>> physical layer tech, I'd like to see it move to a DSCP codepoint, worst
>> case... and certainly remain "experimental" in scope until anyone
>> independent can attempt to evaluate it.
> That seems good to discuss in regard to the L4S ID draft.  There is a section (5.2) there already discussing DSCP, and why it alone isn't feasible.  There's also more detailed description of the relation and interworking in

	IMHO a new protocol ID is the solution:

'B.4.  Protocol ID

   It has been suggested that a new ID in the IPv4 Protocol field or the
   IPv6 Next Header field could identify L4S packets.  However this
   approach is ruled out by numerous problems:

   o  A new protocol ID would need to be paired with the old one for
      each transport (TCP, SCTP, UDP, etc.);

   o  In IPv6, there can be a sequence of Next Header fields, and it
      would not be obvious which one would be expected to identify a
      network service like L4S;

   o  A new protocol ID would rarely provide an end-to-end service,
      because It is well-known that new protocol IDs are often blocked
      by numerous types of middlebox;

   o  The approach is not a solution for AQMs below the IP layer;"

None of these points are show stoppers, IMHO:
1) Especially since in all likelihood only two new protocol IDs will be needed, "AIAD TCP" and "AIAD UDP". 
2) The IPv6 issue is a bit of a red herring as the next header field typically seems to contain the exact same number as IPv4's protocol field and chained headers are probably rare. Also if the primary next header is not of an L4S type, simply treating the flow as RFC3168 compliant seems like a safe option.
3) Okay that is a challenge, but ig L4S is worth its salt, it will offer enough incentives to overcome this hurdle, otherwise why waste ECT(1) on something that the market/the network community does not seem to want?
Me: "Doctor it hurts if I put an AQM below the IP layer."
Physician: " Do not do that then!"
Honestly, how is an AQM below the IP layer (so L1/L2) going to act on IP's ECN code points as required for L4S, but going to fail to look at the protocol/next header field?

This is a really clean solution for L4S issues with the currently proposed badly fitting classifier, that solves all issues with interoperability with the rest of the current internet. 


Best Regards