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

Bob Briscoe <> Tue, 02 March 2021 14:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F9863A18FE for <>; Tue, 2 Mar 2021 06:30:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Status: No, score=-1.433 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Ja-9ZsI7jUw for <>; Tue, 2 Mar 2021 06:29:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD3F83A18FB for <>; Tue, 2 Mar 2021 06:29:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7tjXEY/8UN1Cr0caCydZxWZl4uJtjALCX/l9qg602ok=; b=T4TvdKWc8hsQmKaLPL8lV76S/ k3bGwnt+7ag9j6O7yN8xpY1JQu4SvG1tPlvo3wCEiLSM9ILWeDdMhmwbVoBP9x7l0BNdIesCo/uFf Av8OwF/LYpiijLNKOUDdGiXD8k3580Z/bFrS80W4BlPC5bc/gtLWRu5ChVyqjovCfnhis8Nmbo5CU fvFag7JxCYhFwPQWJQFLBqD6QwWVFpcGaWd2pI2OpFc6ORpP/JT/mP46RwUzxPg+Czo6qkdaNPuHA tR4sohUbzcMWkM/ueoAZ2L1FJR3Gl/RavqX/ZR8FLyKHkSJ/IfgMQTWjl0Z9DsZgftwfIi7uH2+P1 eE/e9vy3Q==;
Received: from ([]:42210 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1lH62A-0005zx-3d; Tue, 02 Mar 2021 14:29:58 +0000
To: Gorry Fairhurst <>, "" <>
References: <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Tue, 02 Mar 2021 14:29:56 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------6026A9BDE88DE8B1D38E3021"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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 14:30:02 -0000


On 02/03/2021 09:47, Gorry Fairhurst wrote:
> I've just looked at theL4S 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.

[BB] I don't believe the studies themselves have 'hinted' or 'suggested' 

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."



> (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?
> Best wishes,
> Gorry

Bob Briscoe