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

"Gorry (erg)" <gorry@erg.abdn.ac.uk> Tue, 02 March 2021 16:15 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 DD4293A2959 for <tsvwg@ietfa.amsl.com>; Tue, 2 Mar 2021 08:15:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 i3rd7jvJg0kh for <tsvwg@ietfa.amsl.com>; Tue, 2 Mar 2021 08:15:03 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB0F3A2948 for <tsvwg@ietf.org>; Tue, 2 Mar 2021 08:15:03 -0800 (PST)
Received: from [137.50.167.31] (oa-edu-167-31.wireless.abdn.ac.uk [137.50.167.31]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5C7CD1B001FE; Tue, 2 Mar 2021 16:14:59 +0000 (GMT)
Content-Type: multipart/alternative; boundary=Apple-Mail-4B26A205-A17E-40C7-BC72-067D8368A7BA
Content-Transfer-Encoding: 7bit
From: "Gorry (erg)" <gorry@erg.abdn.ac.uk>
Mime-Version: 1.0 (1.0)
Date: Tue, 2 Mar 2021 16:14:58 +0000
Message-Id: <E777149D-0136-4525-A417-AF16ED786604@erg.abdn.ac.uk>
References: <c761aae5-ab39-44d8-2e69-716e9f51f11a@bobbriscoe.net>
Cc: tsvwg@ietf.org
In-Reply-To: <c761aae5-ab39-44d8-2e69-716e9f51f11a@bobbriscoe.net>
To: Bob Briscoe <in@bobbriscoe.net>
X-Mailer: iPhone Mail (18D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/uj08V35JMDTKApOe25HAz0pTgWE>
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 16:15:07 -0000


> On 2 Mar 2021, at 14:30, Bob Briscoe <in@bobbriscoe.net> wrote:
> 
>  Gorry,
> 
> On 02/03/2021 09:47, 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.
>> 
> 
> [BB] I don't believe the studies themselves have 'hinted' or 'suggested' this. 
> 
> 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."
> 
> Cheers
> 
> 
> 
> Bob
> 
Thanks.

OK: Improving thiswould be good - and refs are probably helpful.

Gorry 
>> 
>> (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                               http://bobbriscoe.net/