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

Dave Taht <> Tue, 02 March 2021 18:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AA3B3A0ADB for <>; Tue, 2 Mar 2021 10:02:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_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 ZJ7BCOvJaWt6 for <>; Tue, 2 Mar 2021 10:02:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA7123A0ADA for <>; Tue, 2 Mar 2021 10:02:01 -0800 (PST)
Received: by with SMTP id z13so22693712iox.8 for <>; Tue, 02 Mar 2021 10:02:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Fblwp9ClgeXP+WPL2CxlNH/znL5utSKlvg2hVBSsvns=; b=IRPp8WaRyNGAYdvd48lvAHEXcP3djca0Y8kkm9HDTJUB5POt8DGypBzR/EHMK9FEVB UHLuYaLMEERcaORkigAnC1taehDD8P5gk3V/+YrwDPot5W62Xs8l3qIkAK8mvOhsq52E cmGjAfJ0J/POl+CFyJ2sH8fam3vNB7fTjCp1avRFalp0gHlzjcnNjlCWirjGvE4pnBOP LP1PKut/7kJgITXy3YP2cNod2rErozlSsvXVxPQ/gxS1fiasXZuHsTBLRXQoLe3yI1Fy G7Gj0Tpxpk0SjkkIMDwVsUA0v1LWdFrWvhoKfqXx40MVtaUExk7dvGWVibcaWX1VyJNh SoDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Fblwp9ClgeXP+WPL2CxlNH/znL5utSKlvg2hVBSsvns=; b=TajIHe9m5OHfTcwiBykehSxVrwN0gZs8M56PsIZel+CN2hg/NB51iZDlXYyppmQmzM ZbSsjI2hOvoIQT1Y73DQ7yToHma2VY2wq4gmUNHVDzEbfnHq7KoenE2rIAz8CUB27lko upkGtsypYeArQLfSRENNQ7erKD2g8Juj6veqM4uzl7IXMiJKXcIDjYxvsemarAe0uwQv n291SfW+c4ROUiWd9s+sOIrUp6wgoQf9MNuMyPgo7WjX+VD8AT+CT8LqQcQOnUtsdEWv XBeSQFbAkjnS2mj5zfVjTzXXjQ7SAkmACGaRfY1helOTccT+XPPaQ0s9lAaG+ZXseiS4 goqQ==
X-Gm-Message-State: AOAM533n69ZAU7GhKb4CsadmMoKfTjlbB9msfD6VMoiKAz/CuabDtoNb WC4jkEdJ5Drra0DTrcFc1lSWIgKtpIu+rM0JPpKACRwxS5SZTQ==
X-Google-Smtp-Source: ABdhPJy7fpn0QdBUtwTxbd+a81ImLNKSc7A1gLgA6ETu96Kp8hxwUmI1ZVcRG8snZ/FbnNyzGrjHoOgzb53CAf6Dg4E=
X-Received: by 2002:a02:ce8d:: with SMTP id y13mr20514001jaq.29.1614708119788; Tue, 02 Mar 2021 10:01:59 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Dave Taht <>
Date: Tue, 02 Mar 2021 10:01:48 -0800
Message-ID: <>
To: Gorry Fairhurst <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] A few comments on the L4S Operational Guidance draft
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: Tue, 02 Mar 2021 18:02:03 -0000

On Tue, Mar 2, 2021 at 1:47 AM Gorry Fairhurst <> wrote:
> I've just looked at the L4S Operational Guidance draft as this will be presented at the next meeting and I do have a few comments/questions:
> (1) There is text that hints that RFC3168 FIFO bottlenecks are rare:
>    Since existing studies have hinted that RFC3168 FIFO bottlenecks are
>    rare, detections using these techniques may also prove to be rare.
>    Therefore, it may be possible for a host to cache a list of end host
>    ip addresses where a RFC3168 bottleneck has been detected.
> - I suggest “hinted” is not a great choice of words, maybe: suggested that FIFO bottlenecks might be rare, or talk about the possibility of these bottlenecks?
> - This really needs a reference to the suggested evidence? or method to detect?
> - I’m unsure  how such a caching would work, i.e. how the information would be aggregated - and how the timeliness could be managed. There appears some parallels here with TCB sharing - although different mechanism different problem?
> - Although perhaps awkward in some stack, the risk seems low: Some short explanation of the likely risk in incorrectly classifying a path would be helpful.
> (2) Text on Disable RFC3168 ECN Marking
>    Disabling [RFC3168] ECN marking eliminates the unfairness issue.
>    Clearly a downside to this approach is that classic senders will no
>    longer get the benefits of Explict Congestion Notification.
> - I wonder if this needs to be a lot more clear about what is being discussed - is this ECT(0) marking?
> (3) Could we cite more the IETF recommendations from RFC 7567?
> - I’m wondering whether the recommendations and mitigations can be related to RFC 7567, which is the BCP on AQM?

Many moons ago I'd started a RFC for BCP on home routers. It's
woefully out of date regarding what's happened since, and what's in
the field today is far, far in advance of it, but the start was here:

Too late to even start on updating it for this meeting (perhaps
restarting the AQM working group would be good)

In particular the treatment of dscp markings (and or remarking traffic
based on port numbers) is likely to be contentious.

> Best wishes,
> Gorry

"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729