Re: [tsvwg] A few comments on the L4S Operational Guidance draft

Jonathan Morton <chromatix99@gmail.com> Tue, 02 March 2021 18:04 UTC

Return-Path: <chromatix99@gmail.com>
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 696D53A0ADE for <tsvwg@ietfa.amsl.com>; Tue, 2 Mar 2021 10:04:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.com
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 4pTo67wPmWCd for <tsvwg@ietfa.amsl.com>; Tue, 2 Mar 2021 10:04:21 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 6E2113A0B1D for <tsvwg@ietf.org>; Tue, 2 Mar 2021 10:04:21 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id k12so16105218ljg.9 for <tsvwg@ietf.org>; Tue, 02 Mar 2021 10:04:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CRBFktevBjaaHGF7X/jXeMuzG/ZrP5HTq8nracV6DLE=; b=fa/QYI9ulXHj7Rb63r1MGUNdqxDb3egBvJY/XkwPdnnttgzwQaPSMULoebyaUPB1Vk dW6+XjVDttsE5a79pBhjh9m0mrcDbiR2pvZFgnTyQkMze1v8A0WU2TcFaai5jUaNbbxn Ble2k3X4gHsTM8SaDZr6bcUyy9Z1ayG9x5sPJvWd9ZwhQne1ZdEzskZ58jguLldPwKi7 or5Z2rhZ/lnThDfb/zuD8OFZpcgr0iHIhCYsxDeW3tcslvFUGVr5v7wZGMrvZ6/3tB0o 4wSxgIogSGa23XtUzlZKohsG7g/G1RKIEuRRyrJfPVlmZbyfpbHto5hkV+jcuRgfACbK 9YwA==
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=CRBFktevBjaaHGF7X/jXeMuzG/ZrP5HTq8nracV6DLE=; b=QGVL4U4kKuuhXyp9XeRMoLB6/Mj7/ltjL1BwjAV+rH1w/fHj0EoaUdmhUa3ipjtRBu Sm7z+sa8bBhUQ1b4J8OgXpbVxl3bnl+JDXQlOzqkJ/fBnY/Zq2QhAJOq58oG16KUaQ55 r6s/W3DeHLUtLLi87YFbMeql8jyGan4v2pGQeJOdahFSoMVxcc4xxdQplUh2EN8/brkf oQSPZKiGweCW/ff57+kAbTyK17IHQRxlwCFLE4j/iK9NH6OXFzHfvdFxyqMS9wqoBQx6 KhFLsgU7ItHLkcueZJM3Gag2KxDhMHGHQDEldkOMei6BxAVEJMOaheCtZNQ/gIPW1KYy 6gEQ==
X-Gm-Message-State: AOAM532V5Qrpc4Nr4pIeaIJ325nbW+oL1uiputoHfybBP+blJmcNjUJf XRiy/UzI2zgBrj51RHgEZsg=
X-Google-Smtp-Source: ABdhPJwGRXRVc7SUL+OD67zozVA8ciXm3q2UI0DJa7j8qudF3WmjLXq7bv92aUwXgTyDNGHrtebZUA==
X-Received: by 2002:a2e:2d02:: with SMTP id t2mr9898429ljt.488.1614708259326; Tue, 02 Mar 2021 10:04:19 -0800 (PST)
Received: from jonathartonsmbp.lan (176-93-29-60.bb.dnainternet.fi. [176.93.29.60]) by smtp.gmail.com with ESMTPSA id e9sm1536418ljj.52.2021.03.02.10.04.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Mar 2021 10:04:18 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <c761aae5-ab39-44d8-2e69-716e9f51f11a@bobbriscoe.net>
Date: Tue, 2 Mar 2021 20:04:17 +0200
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E38AC1E9-9396-4676-AF04-B53556CE95DC@gmail.com>
References: <5BA56FE9-9288-4C06-A59D-3F9C21D62486@cablelabs.com> <90d8d4f2-7de1-728e-6d33-ff164a9c1531@erg.abdn.ac.uk> <c761aae5-ab39-44d8-2e69-716e9f51f11a@bobbriscoe.net>
To: Bob Briscoe <in@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vf14kI28uWE-k0cQ05QtX3_DLnk>
Subject: Re: [tsvwg] A few comments on the L4S Operational Guidance draft
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: Tue, 02 Mar 2021 18:04:24 -0000

> On 2 Mar, 2021, at 4:29 pm, Bob Briscoe <in@bobbriscoe.net> wrote:
> 
> In the recent measurement studies where CE marking has been detected, I'm not aware of an experiment that has been designed to determine whether the marking is from an FQ or a FIFO. However, by using knowledge of the context of the paths being tested, in many cases the experimenters have made an educated guess that the CE marking is coming from FQ AQMs, sometimes by having traced some of it to FQ boxes on the ground (and sometimes traced to Diffserv-related bugs). This presumption has probably also been reinforced by the knowledge that measurement studies over the years before FQ was deployed found extremely low levels of CE. 
> 
> Perhaps say "The /interpretation/ of these studies and their deployment context has concluded that RFC3168 FIFO bottlenecks are likely to be rare."

While it is true that we haven't specifically identified significant deployment of single-queue ECN AQMs, I think there are three facts which the text in l4s-ops would be wise to highlight:

1: Single-queue AQMs are not prohibited by any RFC that I'm aware of, and are acknowledged to be easier to implement in high-speed hardware than flow-aware AQMs (if nothing else, by the design of DualQ).  There should thus be an expectation that single-queue AQMs *may* be deployed in future, and *may* already be deployed in ways we haven't yet detected.

2: Single-queue AQMs *without* ECN support, and mechanisms which resemble them such as policers, *are* widely deployed.  At least one of the fq_codel instances deployed in the Czech ISP that Pete Heist is associated with was deployed specifically to mitigate the poor performance of a policer, which came as part of a black-box backhaul link supplied by a large telecom.  If ECN support were turned on for these existing deployed AQMs, they would be single-queue ECN AQMs.  There may be significant risk for L4S deployment if future hardware of this type has ECN enabled by default.

3: Tunnels are capable of triggering very similar behaviour to that of a single-queue AQM when passing through a flow-aware AQM, because the latter cannot distinguish between flows encapsulated within the same tunnel.  The effects can be significantly greater when L4S and conventional traffic shares a tunnel, than when several conventional flows share a tunnel, and is always to the detriment of the conventional traffic.

Obviously these points should be accompanied by appropriate discussion of the associated risks and mitigation measures that might be required.  I will take the opportunity here to remind readers of the engineering principle of quantifying risk:

	Risk = Severity * Likelihood

It is also important to understand *who* incurs the downside of a risk.  The threshold for acceptable risk is much lower for uninvolved bystanders than for interested observers, which in turn is lower than for active participants in the activity generating the risk.

 - Jonathan Morton