Re: [tsvwg] feedback and thoughts L4S / SCE

Jonathan Morton <> Mon, 30 November 2020 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26DA03A0D7D for <>; Mon, 30 Nov 2020 07:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IJOVrYKaG682 for <>; Mon, 30 Nov 2020 07:19:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F2873A03F1 for <>; Mon, 30 Nov 2020 07:19:45 -0800 (PST)
Received: by with SMTP id y16so18512453ljk.1 for <>; Mon, 30 Nov 2020 07:19:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nsLK5f/cqu/628BRdFqX8RkVjtv85gDJOruBtzphyuo=; b=pCNVuyXKIn3maHTh+RxvMvMtHt5vLzMKkAcUmBB+kCGPn//wXDv6DnsokQz9sGUE11 sjzepfZwh1kasnJCxAOiXY6cpLnT4cElJEYioIh3rOVEruNlB32RZqu19azF37LHJCJx YIYYIQx6Nu8TR+10ZA8GjjYX39LtpZTQNHDUDRq/bzbJ58VeG48cthmRd2bHmdXqwrbN il8Ww4JC2/XCr7ntu/ftrazqW4aV7eh16BMnYSIrRBoAATEv/vNgkt8Qrl/rt05LAQ0+ wCOtbD0qE0+KO2smsYM1t4JELKqawaYFMKrA4qwNLB8nAhVoT1VXNH9wlI4+ZuW27Q5S 2YSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nsLK5f/cqu/628BRdFqX8RkVjtv85gDJOruBtzphyuo=; b=KUW8SsvAKVLp6kiCpe4ZGpnI22420Ojpc+NajZ4APbo3NRERNxSeik1ggLJNIRSkFL r6B0U/oxk5pnxbJ+FF2kdJ/DzAfUXmIxHvWOwGhV5lKAY/ZisxDJcZhR7M97DS69gk99 Vs+MkF623N0EWrwNk1gWwXG+r8V1EyzluHs3JHDIUl3z0gzd2YjkX9pOc8yfJ4pf4G6R npOylM+/NT2QZvHzD00au1YIFtCq7YHKlt1fTD62qe1fpP+SzKxTgdocb5AIVVAN8txd gPWvTdOt8T10x7qEPKVFpTo5v6P0Wu3SkJsGkfHVSFRqUrVxlOwdNx3QVWvVlrhjGBsx FM+A==
X-Gm-Message-State: AOAM530MxwtpCxcq1fdGAb0RKjjI5De8DzyT8FPSFCzYI4aLZ/SaiPeS pZ2VQHKJCgMNUYS2VqoEnkQ=
X-Google-Smtp-Source: ABdhPJxRyerInRX+EiW1i+vsR32kXjfRxdZY8JnnhHju3nGkyjoEsWF9vX9dxH8rXe8w72hCc3wzoA==
X-Received: by 2002:a2e:b5a1:: with SMTP id f1mr7996683ljn.299.1606749583269; Mon, 30 Nov 2020 07:19:43 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id x8sm2491233lfq.143.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Nov 2020 07:19:42 -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 <>
In-Reply-To: <>
Date: Mon, 30 Nov 2020 17:19:40 +0200
Cc: Ingemar Johansson S <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: Sebastian Moeller <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] feedback and thoughts L4S / SCE
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: Mon, 30 Nov 2020 15:19:47 -0000

> On 30 Nov, 2020, at 11:51 am, Sebastian Moeller <> wrote:
>> That leaves us with the long discussion RFC3168 AQMs. Here the discussion
>> leaves me thinking that we are talking about a very limited actual
>> deployment in other words too much ado about very little.
> 	[SM] citation needed? The challenge is that we have no reliable numbers, one way or the other. Your assessment, says more about your leaning towards L4S than about the deployed reality in the internet. 
>> In addition, I get
>> the impression that these limited deployments are seen as monoliths that
>> cannot be modified and updated,
> 	[SM] So I wonder in what kind of blessed reality you seem to be living? In my experience updates for most consumer-grade networked equipment are pretty rare and often stop way before the useful live of such devices, assuming all of these can/will be updated in time is simply unrealistic. Any proposal that relies on that has the onus of convincing the reviewers why this time around this will be a successful approach. 

Bearing in mind that this is the Internet *Engineering* Task Force, when lacking reliable data the instinct should be to try and obtain it and to make pessimistic assumptions meanwhile, rather than to make optimistic assumptions.

For L4S, the appropriately pessimistic assumptions should, until clearly shown otherwise, be that RFC-3168 middlebox deployment is high but invisible, and that eliminating the majority of this deployment (in favour of L4S-aware middleboxes) would take several years.  The burden of proof is on L4S proponents to show otherwise, given the safety risks already demonstrated of deploying L4S into an RFC-3168 network.

At present the data clearly shows a non-zero active deployment rate of both RFC-3168 endpoints and RFC-3168 middleboxes.  Passive deployment (ie. not enabled by default) of RFC-3168 endpoints is much higher, constituting the overwhelming majority of current desktop and mobile operating systems.  Additionally, L4S clients communicating with existing RFC-3168 servers will generate RFC-3168 traffic from the server to the client, due to details of AccECN negotiation on the three-way handshake.  That much is (or should be) completely uncontroversial.

It is further believed that many RFC-3168 middlebox deployments are presently not easy to observe in traffic statistics, either because they are not always (or not often) bottlenecked at that point, or because the endpoints did not negotiate RFC-3168 capability for the observed traffic.

The former case (not deployed at the bottleneck) may result in AQM activity later, when the bottleneck shifts to the link where it is deployed, perhaps due to ISP-side upgrades or changing the location of wifi devices - or when the observed traffic moves to a closer endpoint in the network, such as a local CDN.  This last suggests that L4S traffic might see more AQM activity due to deployment on an advantageously-positioned CDN, than the existing vantage points from which data has so far been collected.  NB: even if the ISP network has been made L4S-aware prior to the CDN deployment, the end-user's network might not have been, and this is generally outside the ISP's control.

The latter case (non-negotiation of ECN) could still result in AQM activity that would only be observable as packet loss, and thus is difficult to distinguish from a dumb FIFO without deeper analysis.  That is the major source of uncertainty in the data.  This could become more visible if active (rather than passive) deployment of RFC-3168 endpoints increases, which would most likely be from changing the default setting in major operating systems.  Presently the default in both Windows and Linux is passive only.

I will remind readers that although TCP Prague responds appropriately with Multiplicative Decrease upon packet loss, that does not help it when encountering an RFC-3168 AQM that it shares with conventional AIMD traffic, even if the latter is Not-ECT.  This is because the RFC-3168 AQM will mark the L4S traffic at the same rate as it drops Not-ECT traffic and marks RFC-3168 traffic.  This therefore forces TCP Prague to rely on secondary protections such as FQ to avoid starving conventional traffic, but FQ is typically defeated by tunnel encapsulations.

All of the above will be repeated as open issues at any L4S WGLC, unless and until it is clearly shown to be false.  That, I think, should give the L4S team pause when calling for WGLC.

 - Jonathan Morton