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

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 2 Mar 2021 09:47:33 +0000

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.

(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

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 2 Mar 2021 14:29:56 +0000

Gorry,

On 02/03/2021 09:47, Gorry Fairhurst wrote:
> - This really needs a reference to the suggested evidence? or method 
> to detect?
> - 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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Gorry (erg)" <[email-masked]>
Date: Tue, 2 Mar 2021 16:14:58 +0000

> On 2 Mar 2021, at 14:30, Bob Briscoe <[email-masked]> wrote:
> 
>  Gorry,
> 
>> 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:
>> 
>> - 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 
>> - I wonder if this needs to be a lot more clear about what is being discussed - is this ECT(0) marking?
>> 
>> - I’m wondering whether the recommendations and mitigations can be related to RFC 7567, which is the BCP on AQM?
>>  
>> 
>> Best wishes,
>> 
>> Gorry
>> 
>> 
>> 
>> 
>> 
> 
> --

---

From: Dave Taht <[email-masked]>
Date: Tue, 2 Mar 2021 10:01:48 -0800

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

https://github.com/dtaht/bufferbloat-rfcs/blob/master/home_gateway_queue_management/middle.mkd

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.

-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

[email-masked] <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729

---

From: Jonathan Morton <[email-masked]>
Date: Tue, 2 Mar 2021 20:04:17 +0200

> On 2 Mar, 2021, at 4:29 pm, Bob Briscoe <[email-masked]> wrote:
> 

While it is true that we haven't specifically identified significant deployment of single-queue ECN AQMs, I think there are three facts which the text in l4s-ops would be wise to highlight:

1: Single-queue AQMs are not prohibited by any RFC that I'm aware of, and are acknowledged to be easier to implement in high-speed hardware than flow-aware AQMs (if nothing else, by the design of DualQ).  There should thus be an expectation that single-queue AQMs *may* be deployed in future, and *may* already be deployed in ways we haven't yet detected.

2: Single-queue AQMs *without* ECN support, and mechanisms which resemble them such as policers, *are* widely deployed.  At least one of the fq_codel instances deployed in the Czech ISP that Pete Heist is associated with was deployed specifically to mitigate the poor performance of a policer, which came as part of a black-box backhaul link supplied by a large telecom.  If ECN support were turned on for these existing deployed AQMs, they would be single-queue ECN AQMs.  There may be significant risk for L4S deployment if future hardware of this type has ECN enabled by default.

3: Tunnels are capable of triggering very similar behaviour to that of a single-queue AQM when passing through a flow-aware AQM, because the latter cannot distinguish between flows encapsulated within the same tunnel.  The effects can be significantly greater when L4S and conventional traffic shares a tunnel, than when several conventional flows share a tunnel, and is always to the detriment of the conventional traffic.

Obviously these points should be accompanied by appropriate discussion of the associated risks and mitigation measures that might be required.  I will take the opportunity here to remind readers of the engineering principle of quantifying risk:

	Risk = Severity * Likelihood

It is also important to understand *who* incurs the downside of a risk.  The threshold for acceptable risk is much lower for uninvolved bystanders than for interested observers, which in turn is lower than for active participants in the activity generating the risk.

 - Jonathan Morton