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

[Bob Briscoe <[e-mail]>]

Gorry,

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' 
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

>
> (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/