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

Pete Heist <pete@heistp.net> Thu, 07 November 2019 16:25 UTC

Return-Path: <pete@heistp.net>
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 7DC49120935 for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 08:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 (2048-bit key) header.d=heistp.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 VWvE2EdlIDSC for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 08:25:14 -0800 (PST)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF011200B3 for <tsvwg@ietf.org>; Thu, 7 Nov 2019 08:25:14 -0800 (PST)
Received: by mail-vs1-xe2a.google.com with SMTP id q21so1692024vsg.3 for <tsvwg@ietf.org>; Thu, 07 Nov 2019 08:25:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zdktcdCNf3OWcJ+alDkmdip/OtNJ/z7Pp9DbBoIkYDE=; b=Rmz2GO99saYjGO7dL59y0MIHjXLt02e/1/rhlgTpucNjmyyoRN04ryUT5iVmzR9mHI 2sOKWVxarCh2Qnii9IK4OkREeKeijLvfre/YjpSWmqO3Rowbci/EteI/AVNXHRQwlLUk AI0mNKjnOC5H4peVBGrC5ftn6W7FDjrGThieG4dpil2lk1/puvFrS60+3mAM7WswKA/R RGURTe/od6XBiP1dhT3ykkXlw0ny75sQOyM6Fu/8BHzaJYLn36RbtxVNy99X9cUaFDRX Oso+69+YemjMjYMnXw7D+O5LPfe/V3f15FqrxUHXzcX7moOHmuZLYUm/cT/mlstbEnre zAEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zdktcdCNf3OWcJ+alDkmdip/OtNJ/z7Pp9DbBoIkYDE=; b=bRNp1pSLAP+0yBDNwqoYhk27K5njNOlCDpk3y0Q3BtStdf13xeg1u1zloozdULTEv7 UgsBye28kp0IirDINSXM4JUj5ssmjjChs3chCtBxz1OQU1hoPsD5TCvzBFUcYeeoTIsJ WVaZ9GOb3wE4dXMl5eASj/KtxTrJ1PM/SyVZ9GULfcNjKoJ8ITbroXNw86qS70SXF44+ 8lzG2S0aVa4jTHaldK1jcdlHppCz2PexugAUo2KZsmPcvSgI2LCjgXF1o7XzvDZc5AQN T3bcEEr3xROEX+TWBdSYZoXIiLPKZ02uBiF5p5rzeJm2VJnhzQlnzSmNNpdlcRlnjNlS lFcQ==
X-Gm-Message-State: APjAAAU85/QA+EuZgirOc/jXvyR7VHwePhWUraL0ti6xf0XwSxlYNILO vfqQ8t0PYYnbadiatsJoO3DifA==
X-Google-Smtp-Source: APXvYqyUvYvxVzfD9ubHHVlIkKq8WO+WZv0lYc8yxjPzPVMaQD1Z3+Kqq6Uj+dyc1LjEQfOW54QtqA==
X-Received: by 2002:a67:f34d:: with SMTP id p13mr3308530vsm.159.1573143913268; Thu, 07 Nov 2019 08:25:13 -0800 (PST)
Received: from ?IPv6:2601:344:4100:df70:b0dc:5583:6d14:3b83? ([2601:344:4100:df70:b0dc:5583:6d14:3b83]) by smtp.gmail.com with ESMTPSA id e21sm236754vsb.7.2019.11.07.08.25.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Nov 2019 08:25:12 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Pete Heist <pete@heistp.net>
In-Reply-To: <1053591400.593303.1573131284597@mail.yahoo.com>
Date: Thu, 7 Nov 2019 11:25:11 -0500
Cc: Greg White <g.white@cablelabs.com>, Jonathan Morton <chromatix99@gmail.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEF08BBB-379B-42F8-8344-9E8DA3B341C7@heistp.net>
References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com> <B58A5572-510E-42C7-8181-42A0BE298393@gmail.com> <D2E12331-F504-4D5F-B8E7-A1A5E98DDF7E@cablelabs.com> <2275E6A5-C8F8-477F-A24A-3E6168917DDF@gmail.com> <55F724CD-6E74-40D9-8416-D1918C2008DD@cablelabs.com> <BBE7C7A9-0222-4D84-BF27-8D5CAE2F995E@gmail.com> <6f189711-ffa0-90f4-fd16-3464ba4df3ce@mti-systems.com> <4A706B11-3239-4DAC-BE85-0B4BFF2D8FF8@heistp.net> <8B28ECE4-FF4B-4BB2-ACBE-80B30708F97E@cablelabs.com> <AAEA9AC2-B8A1-4837-A7C9-8EEA21A7C523@gmx.de> <D5D560CB-BC47-45BE-811E-E73E2D4909E3@cablelabs.com> <090EDC6E-7B69-401D-931D-E9C3101E68DD@gmail.com> <1053591400.593303.1573131284597@mail.yahoo.com>
To: "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/WXjhd77F4lpbN2nYB0_RrNBWF78>
Subject: Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
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: Thu, 07 Nov 2019 16:25:17 -0000

> On Nov 7, 2019, at 7:54 AM, alex.burr@ealdwulf.org.uk wrote:
> 
> On Thursday, November 7, 2019, 3:35:06 AM GMT, Jonathan Morton <chromatix99@gmail.com> 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. :)