Re: [tsvwg] path forward on L4S issue #16

Jonathan Morton <> Wed, 10 June 2020 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9816D3A082C for <>; Wed, 10 Jun 2020 05:58:18 -0700 (PDT)
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 q0bFqmvjeGgJ for <>; Wed, 10 Jun 2020 05:58:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1196F3A0826 for <>; Wed, 10 Jun 2020 05:58:17 -0700 (PDT)
Received: by with SMTP id i27so2303032ljb.12 for <>; Wed, 10 Jun 2020 05:58:16 -0700 (PDT)
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=vLQbeTJAwfhK9wQOtHo6viF4+oK5swXysCKfg9EQgDc=; b=DIMGlKcJ3QIvSJqN9JlXyib1S70qpxSHrwi0YDMOLv31meivwIVJ4p56o1vcZvLyjW 6rOLVXhsgXdq08Zc4y0X8fR8LuHrSmsmrH3S4mjWyFGgiqpYyWE1zewFbW7Yrl9E/KXl C5nU00HMLN8HJHwRjytpVgOD5By9s6MCgnK3jd9bRkoLOyPBowom7TBUB9xksbSkH+m2 qxgEF8JecQ4r6u433Thv2Gbuh0J0iTe21shGCwTMRkyC36DM/8rWIc6Qv5ZQ2OwhbfT7 x6jB4bHs0Rf/4ei9LwGkgHOo/j1R48l1Xu6A1qU7c80WDbruQa6XoHbdZohhhqov4okH vJ9Q==
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=vLQbeTJAwfhK9wQOtHo6viF4+oK5swXysCKfg9EQgDc=; b=XysIzE7lc5aE63/444x9q2THN08K6BWYqmhJwBJsfTVAYjuzxZ0cZLK5kwBxIT5Tzc srsMmYawhAPHX5tPWrPL+R61nmw5bc4jWoF5PhLkCwTU+axYmCcJIjomTM5gc9wr3aEe q1BjLpMjwDhTQV0IViLWmv5gE7We10hGA9S8bn6AS+KOPd4K3qiLSYpGn9mOWzszk/Iv HWARQ8NoqERZyMjhonGbC1s1Zbk2VI1qRMaiUWswnMLu5uwPJbMBVTkDCKJd+nVZDorF yPX9ZpFfriJtSXk6RBLwOmg502jOjKh6sXYtyp2r6x72YRTcrl93fhbLLt19M0nzXcgB I2KQ==
X-Gm-Message-State: AOAM533YhIYIUtwqtUCQRGS7HKpfd+kQm5rhmTQbdQIn8lYYn8FHaczz C/NVqDda4ci3EbDi/vdRXbA=
X-Google-Smtp-Source: ABdhPJxHPVm10j6ZArmzybW9qxfYujTQNZ2A5MxwYW33KQgU0WRtmFO8yIV7s6i70iRfZrmfqUFvfQ==
X-Received: by 2002:a2e:4812:: with SMTP id v18mr1788769lja.353.1591793895205; Wed, 10 Jun 2020 05:58:15 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id y4sm4970295ljd.111.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2020 05:58:14 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Wed, 10 Jun 2020 15:58:11 +0300
Cc: Sebastian Moeller <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: Ingemar Johansson S <>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <>
Subject: Re: [tsvwg] path forward on L4S issue #16
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: Wed, 10 Jun 2020 12:58:19 -0000

> On 10 Jun, 2020, at 11:35 am, Ingemar Johansson S <> wrote:
> 1) How widely are  RFC3168 ECN capable AQMs deployed _and_ enabled ?

Enough for the effects to be visible on about 0.1-1.0% of current Internet traffic - and rising steadily.  That's some combination of endpoints negotiating ECN support, and middleboxes implementing an AQM, but not necessarily both on the same path.  Deployment of ECN-enabled AQM is very high across a small number of forward-thinking ISPs, including a very large one in France and a major one in Norway.

Basically every endpoint out there today implements RFC-3168 ECN, and every Linux endpoint runs an ECN-enabled AQM by default on each Ethernet interface.  If Linux and/or Microsoft had decided to switch it on by default a decade ago, rather than hiding it behind a non-default configuration flag, we would not be having this conversation, because the deployment numbers would be too big and obvious to ignore.  It's been a long, slow chicken-and-egg situation which the major consumer ISPs have essentially refused to help resolve.

But now there are commercial, off-the-shelf CPE products which anyone can buy and install, and which implement the sort of bufferbloat mitigation measures that most ISPs have not.  I've found at least one of those on the physical retail shelf, here in Finland.  I don't have sales numbers, but they must account for most of the deployment on ISPs that haven't deployed it themselves.

> 2) If they are deployed _and_ enabled, can/will they be updated ?

Some can and will.  But some is baked in hardware so would be difficult to update, and some is managed by people/vendors who do not know or care about L4S, so would tend to keep using the old system which is RFC-compliant today.  When was the last time your CPE devices got a firmware update?  So L4S has to be able to cope with the existence of such deployments in at least the medium term.

Frankly, if you believe that tunnels are an intractable problem, then this is just as bad.  So please finally drop this argument; you're not convincing anyone who matters.

 - Jonathan Morton