Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs

Sebastian Moeller <> Thu, 07 November 2019 16:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E833812082E for <>; Thu, 7 Nov 2019 08:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Status: No, score=-1.647 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VKkh2lTsYlNb for <>; Thu, 7 Nov 2019 08:47:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3378A120113 for <>; Thu, 7 Nov 2019 08:47:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1573145258; bh=0LSWpp1EB1bC7vchfuHabimZ/oTm3D6bXKi6nAA3Vt8=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=jj20KWHBNflJLDcklhzoqToa6rUabIuqWiDWIqw0WTWxa1Al6ifUSZ61CLH4VnDs4 QiHcJkJIkrdgopmqiolEwefy+angO7r9MfhySPPp4U51TdKSYmyE8txJu52bpsRqXY xVL5V3c9N/lH1kmNpaD0lqn6heGxxO2RjNFpqppw=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx005 []) with ESMTPSA (Nemesis) id 1MEV3I-1iikIy2jIw-00G3Nd; Thu, 07 Nov 2019 17:47:38 +0100
Date: Thu, 07 Nov 2019 17:47:31 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----5MF4O92TB43QFH7HM62ZJ444NMGXM8"
Content-Transfer-Encoding: 7bit
To:, Pete Heist <>, "" <>
CC: "" <>
From: Sebastian Moeller <>
Message-ID: <>
X-Provags-ID: V03:K1:1pXm4e02KWqs9irb3qIOPqffxjOOsYJXlzhtsm1RuGbZjMOOJnt PYO8NKq53OfIhX0kMhlLsnR2SygzVeL7sw+6cDTiTtIbqGdrk1zb7yn1IhDd2mTndo/n+Uf tcRlC6OIZeNDkbFiRLfUWPNfenoA86DolqaECCMCqBULGJlLPRx0o2eJ/qB9Ho1RXDd6Y2s pGBFpRARUT4/ZCklfSNfQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:fv77J+4RBs8=:OtTGsjcw+T9IaRpIV8ZQf9 Z15BqnQyIhRvIo3E+Joa6nIEKbqLQUxuFyeQZrIHp9EE9+tl7PqkeWprfynrRtkgpUi+U+wZf jNhwfA/By0ZatrEbMkdaVrnHNoOPtMreIyfF+EVLbWmV1vlD21YJRSyLfVIurD+DJXJyPae3w ab80MFna/qCyxXgcqbz2qQSwlvIgFf3wWIm1GDl1T/DLXhuHfpd77G22P1Iu7aqZY8cBmOnBk lJKNRYUXJrcdeRSiIU6yfBERSAL3WAphYW2n5WuznaUwSmrMyO50iR/bXu29IZAMUQ/HzyGbL OylREMdtjD0eAaKi55DAuN8DfH95eqisSAEuFvOWjicidL1eRWJVpOByFU4VjEGzvAoZrWNjn fR5L5Qn+ti8Dy1Voz6y9YLK4dQzv1V9UX9j2VqVtZ7NWuTblz6PQzfKu5BWmGhp7ilZqfHAuz UjyHB0zfDKJuiS6RIspSxrxI8eVZuUpWC4/8sG+mhUjyNnKJz59Soo4K8yZGiUYCU5sGeYXmR K2yuEObvDGm6Jeujil3I759Qxob00WDJcLDOfxLW65GgxEJGrI9yyqrpuY+Gcm3ZcJ2bw1Fb4 tycG4jAiSDhxlHDDBst+J9IWyER54O/6iAkyx8ptHNu+aOHevZ8xJ8AO82oZjCGWeM7S80vYO j75WSlTYefR8ZQWhz+elGOp/bCdmEk4dU3s5zSvQs+XXNTILW6GRILc89KxbKgAMlz1wKQQQB CO5q7ngI2kCs2jVGdXllpC3Nmkgdgmly1kEhKBdv3R2weIYAc4x1dGcDN/gBvulvxCa4wGb4Q 4zGxErLDkc/DL/HJgTqEwfDi0gUEx8xFcRN6P1EuEKR8ADHdIh1QGknukrDCXZM94HF3/k1K3 fDK9OsFjvR/UY5nDai6b2kzHv18uz80jjB2Xk96RoWkPe0K08eXq203v+EUgOze+QGtssqPj6 0fvHjwcmz+kqmzi23MIO2X6uCKRs6Zfj4b6IO6szoQZyLXE3cKQothpRldUTp6YQh9Qvnn5R5 5Yscflj0ew3bKI7b/MGgtzhivQJdvugD1OpVsmym3c5i/iHID8+bKVw6eSJqYuVBXxVgr+NJn sZ2V7+uwoFK4MSo6+H1vgP0IhjEgS+7/pIDmrll6KwCf0rdGtm/soZxXwptM/OOxLxaGw7aTy wx3ObXPgBnCbYxV+ib1MqWjrPN4hC4b7vnNqJFihTZWL1CYVpnhe4R+5QO4f6zze7fYixQRIM epKye98y2bb4SymMxF1anb7zgeJcj/t4VTR24IA==
Archived-At: <>
Subject: Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
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: Thu, 07 Nov 2019 16:47:47 -0000

See below....

On November 7, 2019 5:25:11 PM GMT+01:00, Pete Heist <> wrote:
>> On Nov 7, 2019, at 7:54 AM, wrote:
>> On Thursday, November 7, 2019, 3:35:06 AM GMT, Jonathan Morton
><> wrote:
>> > > - if the CoDel queue is upgraded to perform Immediate AQM on L4S
>flows, the latency spike can be largely avoided.
>> > This is not relevant, since the point of this exercise is to
>establish the extent of L4S' compatibility with existing, unmodified
>networks, in which Codel happens to be the most widely deployed > AQM. 
>You cannot reasonably expect the entire Internet to "upgrade" to L4S
>compatible AQMs before you can safely begin deployment.
>> I wonder if Codel actually is the most widely deployed AQM. This is
>not to dispute your point, which is correct - proposing an update to
>Codel doesn't addess existing deployments..
>I can’t contribute any information to which is the most widely
>deployed, however to counter any suggestion that CoDel _isn’t_ widely
>deployed, Ubiquiti’s UniFi and EdgeMAX line of products use fq_codel in
>what they call their “smart queueing” feature, and are often deployed
>at bottlenecks (CPE equipment and backhauls). In their UniFi
>administrative controller, they also passively monitor TCP RTT, and
>according to some internal heuristic, send notifications to the
>administrator to consider turning on smart queueing (i.e. fq_codel) at
>the UniFi gateway. In the subtitle for the UniFi product page is the
>text “millions of shipments per year in 180+ countries”. Although
>that’s only marketing, it gives some idea of the scale of deployment
>from this vendor.
>It does look like the issue is being worked on though, so this is just
>to add some weight to the importance of handling it well, which to me
>means minimizing false positives or negatives for non-L4S queue
>detection, minimizing detection time, and taking into account path
>changes that might move the bottleneck at any time. :)

 [SM] I guess it is worth repeating that the obvious solution to all of these challenges would be to fix the actual root cause of the issue, instead of trying to paper over the symptoms. If L4S would not try to make the ECT(1) and the CE codepoint do the work that would require 2 independent bits neither issue 16 nor 17 would exist in the first place. I wonder how, after having eloquently argued for the requirement of strict isolation/separation between tcp-friendly and dctcp-style traffic, one could have converged on this clearly sub-optimal approach. 
I have read the discussion of the alternatives in the L4S draft and while clearly none of the options is perfect, most have less undesirable side effects on normal traffic than the admittedly clever 'overload ECN codepoints' variant that currently is being pushed.

Best Regards