Subject: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 29 Oct 2020 06:58:48 +0000

Hi
I agree with the statement below. If one take 5G access as example, the
bearer concept and the scheduling mechanism will for the vast majority of
use cases prevent that one "user" cause harm to others. 
Thus it should not be mandatory to implement queue protection.
 
/Ingemar 

>You will recall that I and others have argued against QProt being 
>mandatory to implement using arguments about incentives. That is still 
>the main argument, which I can summarize if necessary, but that's not 
>the purpose of this email.
 
>Here. I want to add another argument that is about modularity. In the 
>latest revision of the l4s architecture you will find seven examples 
>listed of how queue protection could be implemented (eight if you count 
>the null case of no protection):
> <https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-07#section-8.2>
https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-07#section-8.2
>Only two have the queue protection integrated with the AQM. Five use 
>distributed arrangements, with characterization of the traffic 
>congestion located remote from the bottleneck queues that are being 
>protected.
 
>For a distributed solution, when a developer implements an L4S AQM in 
>one box, it doesn't even make sense for the IETF to mandate that she 
>must implement queue protection with it. In a distributed approach, 
>queue protection would be an independent module running on a different box.
 
>The only way that would make sense would be if the IETF was writing a 
>normative standard for a complete traffic control system. Then we would 
>be telling operators what to do, not implementers. System standards are 
>usually the territory of the ITU, or the broadband forum, etc. The IETF 
>is usually expected to specify component parts - protocols, algorithms - 
>"Do one thing and do it well".

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 29 Oct 2020 09:51:16 +0100

Hi Ingemar,
 
more below in-line, prefixed with [SM]

Gesendet: Donnerstag, 29. Oktober 2020 um 07:58 Uhr
Von: "Ingemar Johansson S" <ingemar.s.johansson=[email-masked]>
An: "Bob Briscoe ([email-masked])" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Ingemar Johansson S" <[email-masked]>
Betreff: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?

Hi
I agree with the statement below. If one take 5G access as example, the bearer concept and the scheduling mechanism will for the vast majority of use cases prevent that one “user” cause harm to others.
 [SM] What makes you believe that cross-user unfairness is the only rationale for queue-protection? Unless 5G will mandate that L4S services need to be opt-in/configurable by the end-user, considering queue-protection only between users seems rather haphazard. AND the same flawed rationale against queue protection will also hold for the intended roll-out of L4S aas part of low latency DOCSIS at CMTS, as these already implement a per-user traffic shaper to keep each user to her/his contracted speeds. Thus it should not be mandatory to implement queue protection.

 [SM] Given the development of the L4S drafts in this WG I am confident, that in the end you will get your way, after all L4S is getting away with promising no starvation for non-L4S flows without properly defining what starvation is suposed to mean in this context*. That said, IMHO mandating implementation (but not activation by default) of queue protection methods seems like a prudent hedge against future misbehaviour of L4S AQM. Given that L4S has not yet been proven to work over the internet at all (who ever believes it has been shown, please post a link to the test results and an explanation why those tests were braod enough to cover sufficiently many relevant real-world conditions), mandating the existence of such circuit-breaker features like queue protection should be a clear "conditio sine que non".

*) Here, again my proposeal for the meaning of starvation in the context of AQMs: if a flow receives less than 1/8 (three orders of magnitude in base2) of its _intended_ share of the link#s capacity it is starved. "Intended share" allows for conscious rate limiting of flows based on secondary properties to allow traffic engineering and traffic shaping (to the point of even allowing starvation of flows, if that starvation is intentional, like e.g. for flows participating in a DOS attack).
Best Regards   Sebastian  

/Ingemar

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 29 Oct 2020 12:15:47 +0000

Hi Sebastian
Please see inline

/Ingemar

> -----Original Message-----
> From: Sebastian Moeller <[email-masked]>
> Sent: den 29 oktober 2020 09:51
> To: Ingemar Johansson S
> <ingemar.s.johansson=[email-masked]>
> Cc: Bob Briscoe ([email-masked]) <[email-masked]>;
> [email-masked]; Ingemar Johansson S <[email-masked]>
> Subject: Aw: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to
> Implement?
> 
> 
> Hi Ingemar,
> 
> Von: "Ingemar Johansson S"
> <ingemar.s.johansson=[email-masked]>
> bearer concept and the scheduling mechanism will for the vast majority of use
> cases prevent that one “user” cause harm to others.
>  [SM] What makes you believe that cross-user unfairness is the only rationale
> for queue-protection? Unless 5G will mandate that L4S services need to be
> opt-in/configurable by the end-user, considering queue-protection only
> between users seems rather haphazard. AND the same flawed rationale
> against queue protection will also hold for the intended roll-out of L4S aas
> part of low latency DOCSIS at CMTS, as these already implement a per-user
> traffic shaper to keep each user to her/his contracted speeds. Thus it should
> not be mandatory to implement queue protection.
[IJ] There is unfairness and then there is unfairness. I would say that the case where certain flows outcompete other flows on the same radio-bearer is a lesser concern than the case that the traffic on one bearer outcompetes the traffic on another bearer. I outlined the latter above. There is little incentive to build applications that misbehave either by mistake or on purpose as these put the end user experience at risk for the application itself as well as other applications running over the same bearer. The typical example is that teleconferencing users  turn off the video when the audio begins to stutter. 
There are of course 5G cases where several users can share the same bearer, one such is FWA (Fixed Wireless Access), this may need some kind of queue protection. But that does not mean that it should be mandated.

> 
>  [SM] Given the development of the L4S drafts in this WG I am confident, that
> in the end you will get your way, after all L4S is getting away with promising no
> starvation for non-L4S flows without properly defining what starvation is
> suposed to mean in this context*. That said, IMHO mandating implementation
> (but not activation by default) of queue protection methods seems like a
> prudent hedge against future misbehaviour of L4S AQM. Given that L4S has
> not yet been proven to work over the internet at all (who ever believes it has
> been shown, please post a link to the test results and an explanation why
> those tests were braod enough to cover sufficiently many relevant real-world
> conditions), mandating the existence of such circuit-breaker features like
> queue protection should be a clear "conditio sine que non".
> 
> *) Here, again my proposeal for the meaning of starvation in the context of
> AQMs: if a flow receives less than 1/8 (three orders of magnitude in base2) of
> its _intended_ share of the link#s capacity it is starved. "Intended share"
> allows for conscious rate limiting of flows based on secondary properties to
> allow traffic engineering and traffic shaping (to the point of even allowing
> starvation of flows, if that starvation is intentional, like e.g. for flows
> participating in a DOS attack).
> Best Regards   Sebastian
> 
> 
> /Ingemar
> 
> 
> >is usually expected to specify component parts - protocols, algorithms
> >- "Do one thing and do it well".
>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 29 Oct 2020 14:36:52 +0000

Ingemar,

You are talking about per-user queue protection, which is already widely 
deployed by nearly all ISPs, whatever the access technology (outside the 
mobile phone sector 'user' is generalized as 'customer site'). That 
practice is not controversial, and I'm not questioning it here.

Here I am responding to David's proposal that per-application-flow 
(5-tuple) queue protection is mandatory to implement for L4S.
David proposed it on tsvwg a long time ago, and brings it up whenever 
issue #26 is discussed in meetings. (However, I don't actually see 
David's proposal referenced under Issue #26 on the tracker.)

l4s-arch defines 'site' to include single user sites (mobiles). If you 
search for 'site' throughout the draft, you will get the idea.

Section 8.2 of l4s-arch that I am referring to here consistently says 
per-flow queue protection, and the first time it adds '(5-tuple)' to 
define what flow means in this context.

Bob

On 29/10/2020 06:58, Ingemar Johansson S wrote:
> Hi
> I agree with the statement below. If one take 5G access as example, 
> the bearer concept and the scheduling mechanism will for the vast 
> majority of use cases prevent that one “user” cause harm to others.

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

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 29 Oct 2020 14:53:26 +0000

Sebastien,

>   [SM] What makes you believe that cross-user unfairness is the only rationale for queue-protection? Unless 5G will mandate that L4S services need to be opt-in/configurable by the end-user, conside…

[SM] I'm afriad this discussion about fairness between users is 
immediately going off in two different directions from where the thread 
started.
* It's about per-flow (5-tuple) not per-user (see email to Ingemar just 
now).
* And it's about latency policing, not rate policing. We coined the term 
'queue protection' to have a term that was distinct from rate policing, 
because we found that when we used the term 'latency policing', many 
people assumed we meant some variant of rate policing.

>
>   [SM] Given the development of the L4S drafts in this WG I am confident, that in the end you will get your way, after all L4S is getting away with promising no starvation for non-L4S flows without properly defining what starvation is suposed to mean in this context*. That said, IMHO mandating implementation (but not activation by default) of queue protection methods seems like a prudent hedge against future misbehaviour of L4S AQM.

[BB] From this I take it that you haven't really understood the original 
email, which said it's not even possible for the IETF to mandate queue 
protection, given it will often be separately implemented. The IETF 
doesn't write RFCs that mandate how operators build their whole systems.

Other aspects of this email go-off topic in other directions, so I'll 
stop here.

Bob

> Given that L4S has not yet been proven to work over the internet at all (who ever believes it has been shown, please post a link to the test results and an explanation why those tests were braod enough to cover sufficiently many relevant real-world conditions), mandating the existence of such circuit-breaker features like queue protection should be a clear "conditio sine que non".
>
>> must implement queue protection wI take it ith it. In a distributed approach,

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 29 Oct 2020 15:01:55 +0000

OK

Thanks for the correction, my misunderstanding. 

I have on the todo list to read L4S arch. Will comment on it after the
weekend.

/Ingemar

From: Bob Briscoe <[email-masked]> 
Sent: den 29 oktober 2020 15:37
To: Ingemar Johansson S <[email-masked]>; [email-masked]
Subject: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?

Ingemar,

You are talking about per-user queue protection, which is already widely
deployed by nearly all ISPs, whatever the access technology (outside the
mobile phone sector 'user' is generalized as 'customer site'). That practice
is not controversial, and I'm not questioning it here.

Here I am responding to David's proposal that per-application-flow (5-tuple)
queue protection is mandatory to implement for L4S.
David proposed it on tsvwg a long time ago, and brings it up whenever issue
#26 is discussed in meetings. (However, I don't actually see David's
proposal referenced under Issue #26 on the tracker.) 

Section 8.2 of l4s-arch that I am referring to here consistently says
per-flow queue protection, and the first time it adds '(5-tuple)' to define
what flow means in this context.

Bob

Hi
 
/Ingemar 

 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
<https://protect2.fireeye.com/v1/url?k=acf915a2-f249883a-acf95539-861fcb972b
fc-7277e51f261e0fef&q=1&e=16d8b77b-d97e-4b23-93ac-e6ec88cd7554&u=http%3A%2F%
2Fbobbriscoe.net%2F>

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 29 Oct 2020 17:20:31 +0200

> On 29 Oct, 2020, at 4:53 pm, Bob Briscoe <[email-masked]> wrote:
> 
> [SM] I'm afriad this discussion about fairness between users is immediately going off in two different directions from where the thread started.
> * It's about per-flow (5-tuple) not per-user (see email to Ingemar just now).
> * And it's about latency policing, not rate policing. We coined the term 'queue protection' to have a term that was distinct from rate policing, because we found that when we used the term 'latency policing', many people assumed we meant some variant of rate policing.

Thanks for this clarification.  I take it that you consider "queue protection" to be all about protecting the latency characteristics of the L4S queue against incursions from non-L4S traffic.  I think I understood that already from the context of previous discussions, but it's nice to have it explicitly confirmed.

However, I consider that queue protection is actually required for precisely the opposite reason - to protect conventional traffic from incursion by L4S traffic, which violates the principles that AIMD congestion control relies upon.  But that is covered more precisely by other issues than #26, so we can continue to discuss that under the other headings.

What issue #26 is really about from the WG's point of view is not latency, but the prospect of the L4S classifier being co-opted as a strict-priority "fast lane" identifier by ISPs.  This inevitably leads to rate unfairness which might materially degrade the user's experience, if the traffic being prioritised is not what he intuitively expects to be prioritised.  There is definitely an economic temptation for ISPs to do so, which must be carefully guarded against by technical means, not merely policy.  That is why "admission control" is included in the issue's title, corresponding to the de-facto status of L4S as defining a PHB (albeit outside the normal Diffserv structure).

In short, issue #26 *is* about rate policing.  I'm sorry if your attention has been focused on solving a different problem, but this is the one you actually need to solve somehow.

 - Jonathan Morton

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 29 Oct 2020 18:19:05 +0000

Jonathan,

On 29/10/2020 15:20, Jonathan Morton wrote:
>> [BB] I'm afriad this discussion about fairness between users is immediately going off in two different directions from where the thread started.

[BB] I just altered the tag above from [SM] to [BB] - sorry my brain 
fart - I must have thought I was someone else, but I'm not any more. 
Whatever, I don't think you were confused.

> Thanks for this clarification.  I take it that you consider "queue protection" to be all about protecting the latency characteristics of the L4S queue against incursions from non-L4S traffic.

[BB] Yes.

> I think I understood that already from the context of previous discussions, but it's nice to have it explicitly confirmed.
>

[BB] Indeed.

Can I ask that people don't use the term queue protection when they mean 
rate policing - the term rate policing precisely describes what you're 
talking about, so please don't smudge the meaning of a term intended to 
be distinct from rate policing.

> In short, issue #26 *is* about rate policing.  I'm sorry if your attention has been focused on solving a different problem, but this is the one you actually need to solve somehow.

Issue #26 is certainly about unresponsive flows, but I think you see 
this as a discussion about rate policing because you think that is the 
solution. Jake filed issue #26, and, if I look at the conversations 
between Jake and me that he has linked to from his later additions to 
the issue tracker, he is talking about the DOCSIS per-flow queue 
protection algo and I also talk about the bulk overload protection algo 
(referencing the DualQ draft). (I need to check whether I've missed 
responding, as it looks like I might have).

Maybe I need to spell this out. The DualQ qdisc was about modularity: 
"Do one thing and do it well". it was designed as a module to introduce 
*one* feature: ultra-low delay, and avoid introducing *two* features at 
once (i.e. avoid intervening in rate control). Per-flow rate policing 
can then be added if desired, but as a separate module.

The DualQ includes an overload protection algorithm to address the 
problem of unresponsive flows (see our reference Linux implementation or 
the DualQ draft). It's goal is to ensure that an unresponsive flow 
cannot exploit the DualQ's scheduler any more that it could exploit a 
FIFO. That's not a very ambitious goal, but intervening in rate control 
any more than that would be "mission creep", and should be confined to a 
separate 'rate policer' module.

Bob

---

From: Sebastian Moeller <[email-masked]>
Date: Thu, 29 Oct 2020 20:36:05 +0100

Dear Bob
 
more below in-line, prefixed with [SM2]

Gesendet: Donnerstag, 29. Oktober 2020 um 15:53 Uhr
Von: "Bob Briscoe" <[email-masked]>
An: "Sebastian Moeller" <[email-masked]>, "Ingemar Johansson S" <ingemar.s.johansson=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Ingemar Johansson S" <[email-masked]>
Betreff: Re: Aw: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?
Sebastien,

> [SM] What makes you believe that cross-user unfairness is the only rationale for queue-protection? Unless 5G will mandate that L4S services need to be opt-in/configurable by the end-user, consideri…

[SM]
 
        [SM2] that should have been BB, I believe?
 
I'm afriad this discussion about fairness between users is
immediately going off in two different directions from where the thread
started.
* It's about per-flow (5-tuple) not per-user (see email to Ingemar just
now).
 
        [SM2] Yes, I agree, and I tried to argue such.

        [SM2] I believe that queue protection as mandated by docsis, does both. By ensuring that non-responsive flows exit the L4S fast queue the standard-queue is more likely to get its appropriate share of transmission slots. Unlike you I do not pretend that latency and rate are orthogonal to each other at least not on small timescales...

 
        [SM2] I wonder why you believe that the IETF can then rquire that implementers of L4S aware protocols actually follow the requirements you lay out in your internet drafts? Anybody deploying an L4S compatible AQM surely can be bothererd to make sure that AQM has a knob to enable some sort of queue protection (we are stillnot talking about enabling that on default, and hence this is orthogonal to any other queue protection scheme an operator might want to use). I would say, that the IETF is in a position to require such things, especially since the implementers here want something special from the IETF, the right to re-define what the ECN CE and ECT(1) code points mean, internet-wide. 
Now, if L4S would not introduce a real danger of starving non-L4S traffic to a trickle, you might have a point. But the reason for requesting a mandatory queue protection mechanisms is simply that L4S as currently designed and implementd has abysmal sharing behvior and is easily gamed. If you would propose the remove the requirement for implementing queue protection by implementing something with better worst case sharing behaviour in the core L4S design, I am all for dropping queue protection then. But I do not believe that is what you offer.
 
Best Regards
        Sebastian

Bob

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

---

From: Jonathan Morton <[email-masked]>
Date: Fri, 30 Oct 2020 19:06:58 +0200

> On 29 Oct, 2020, at 8:19 pm, Bob Briscoe <[email-masked]> wrote:
> 
> Maybe I need to spell this out. The DualQ qdisc was about modularity: "Do one thing and do it well". it was designed as a module to introduce *one* feature: ultra-low delay, and avoid introducing *two* features at once (i.e. avoid intervening in rate control).

Taking your advice, I'm going to focus on this one statement, and focus well.

DualQ actually does three different things, each of them poorly:

1: It divides traffic into two classes to apply differential service to them, using an input signal that can be ambiguous (ie. CE codepoints could belong to either class).

2: Traffic from each class is delivered with nearly strict priority to one class, ostensibly in support of the latency goal of that class.  This abdicates the attendant responsibility of sharing capacity equitably between traffic classes.  I use the word "equitably" advisedly, rather than "equally", acknowledging that there are several viewpoints on what is "equitable" in a differentiated-services context.

3: It performs Active Queue Management, using an algorithm that has been shown to perform poorly on paths that have significant latency jitter (eg. WiFi), or when traffic demand is very bursty (eg. realtime video over SCREAM).  On short paths, the difference in effective path latency combined with the equalising of congestion windows between the two traffic flows results in a large imbalance in throughput.

I agree that modularity is a good thing in engineering, but so many components of L4S rely on workarounds for each others' failings that I don't think it is actually very modular at all.  By contrast, SCE is designed so that any major part of it can be substituted with an improved version without difficulty - where "improvement" can be interpreted many different ways in various contexts.

 - Jonathan Morton

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 31 Oct 2020 11:06:00 +0000

Jonathan,

"Do one thing and do it well" is about providing features, not what is 
done internally to result in those features.

Try re-writing your characterization of SCE, starting from the features 
that a FIFO provides for flows using e2e congestion control, which is 
most of today's Internet. Then see if you can prove that SCE can be used 
to only add the one feature of low delay (without also intervening in 
rate control).

Even if you don't want end systems to be in control of their rate, "Do 
one thing and do it well" is intended to ensure that engineers allow 
other people to mix and match to get what /they/ want.

I'll respond to your detailed points about whether the DualQ achieves 
what it aims to do, but separately once the IETF deadline is over. I'd 
first like to keep on the topic of "Do One Thing and Do It Well".

Bob

---

From: Jonathan Morton <[email-masked]>
Date: Sat, 31 Oct 2020 16:22:02 +0200

> On 31 Oct, 2020, at 1:06 pm, Bob Briscoe <[email-masked]> wrote:
> 
> "Do one thing and do it well" is about providing features, not what is done internally to result in those features.
> 
> Try re-writing your characterization of SCE, starting from the features that a FIFO provides for flows using e2e congestion control, which is most of today's Internet. Then see if you can prove that SCE can be used to only add the one feature of low delay (without also intervening in rate control).

I do not claim that SCE's middlebox elements do only one thing.  They are in fact systems of cooperating algorithms that are designed to provide favourable behavioural characteristics (plural) that fit into the SCE system.  But they are modular in the sense that there are many different ways to producing those characteristics, which are mutually compatible; the possibility of future innovation in any part of the system is left open.

Without getting too far into the weeds, I will simply note that DualQ does not meet the required specifications presented in your own documents.

 - Jonathan Morton

---

From: Sebastian Moeller <[email-masked]>
Date: Sat, 31 Oct 2020 17:01:29 +0100

Team L4S,
 
art its core the dual queue coupled AQM is a strict priority scheduler that gives (depending on config parameters) ~16 more throughput to L4S shallow-queue versus the L4S-deeper queue, ameliorated with a set of heuristics to rarely regress towards that sharing ratio. I am not saying that you can not defend that as a reasonable design choice (not that I agree with that choice), but claiming that DualQ does not do rate control does not seem to match what DualQ actually does., nor what its internet draft claims:
 
https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-12#section-2.2

2.2[https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-12#section-2.2]. Dual Queue
Classic traffic needs to build a large queue to prevent under- utilization. Therefore a separate queue is provided for L4S traffic, and it is scheduled with priority over the Classic queue. Priority is conditional to prevent starvation of Classic traffic. Nonetheless, coupled marking ensures that giving priority to L4S traffic still leaves the right amount of spare scheduling time for Classic flows to each get equivalent throughput to DCTCP flows (all other factors such as RTT being equal).
 
It clearly involves throttling "classic" traffic which some would call controlling its rate, no?
 
Bet Regards
        Sebastian

Gesendet: Samstag, 31. Oktober 2020 um 12:06 Uhr
Von: "Bob Briscoe" <[email-masked]>
An: "Jonathan Morton" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Betreff: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?
Jonathan,

Bob

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 31 Oct 2020 18:41:22 +0000

See below,

> On 31 Oct 2020, at 16:02, Sebastian Moeller <[email-masked]> wrote:
> 
> 
> Team L4S,
>  
I understand the WG is working on L4S, and that it changes the way we understand the default forwarding, so do you have some clarification to the text you can suggest? 

As we move towards a WGLC it is really helpful to address comments directed at particular text sections, where we can more clearly see what can or should be changed. 

Gorry

---

From: Sebastian Moeller <[email-masked]>
Date: Sat, 31 Oct 2020 21:19:09 +0100

Hi Gory.

More below in-line, prefixed with [SM].

Gesendet: Samstag, 31. Oktober 2020 um 19:41 Uhr
Von: "Gorry Fairhurst" <[email-masked]>
An: "Sebastian Moeller" <[email-masked]>
Cc: "Bob Briscoe" <[email-masked]>, "[email-masked]" <[email-masked]>
Betreff: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?
See below,

> 2.2[https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-12#section-2.2[https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-12#section-2.2]]. Dual Queue

        [SM] My argument, in this instance was not so much complaining about text in the draft, but more against Bob's assertion that "The DualQ qdisc was about modularity: "Do one thing and do it well". it was designed as a module to introduce *one* feature: ultra-low delay, and avoid introducing *two* features at once (i.e. avoid intervening in rate control)."
        This simply is not what the RFC rightly says about DualQ's implementation. This all seems to boil down to Bob's unwritten assumption, that rate and latency are orthogonal, but in reality they are not. Since Bob is one of the authors of the DualQ draft, the fact that he appears to be confused about how DualQ is designed and implemented leaves me puzzled. As does the fact that you seem to expect me to propose changes to the RFC text to match Bob's IMHO wrong ideas about how things work.

        [SM] In this case it might be helpful to Bob, to spell out that DualQ at its core is a rate policer set up that the shallow-queue mainly harvests a latency advantage over the deep queue, as long as dualQ's heuristics trigger, otherwise (in a set of so far under-explored conditions) the shallow queue traffic will get by default u the 15/16 of the available egress rate (and accordingly lower latency). Interpreting that design as a clean way to supply low-latency without "intervening in rate control" does not strike me as a fitting characterization.

Sebastian

Gorry

> Bob Briscoe http://bobbriscoe.net/[http://bobbriscoe.net/][http://bobbriscoe.net/[http://bobbriscoe.net/]]
>

---

From: Jonathan Morton <[email-masked]>
Date: Sat, 31 Oct 2020 23:13:51 +0200

> On 31 Oct, 2020, at 8:41 pm, Gorry Fairhurst <[email-masked]> wrote:
> 

The known technical problems with L4S are not being addressed.  The "Prague requirements" in themselves are reasonably sound, but the reference implementation does not meet them (as we showed in the last consensus call), and no effort has apparently been expended towards making it compliant in the subsequent six months or so.

Meanwhile, L4S documents are being updated, but these do not put forward the sort of robust administrative workarounds that could make L4S palatable for deployment; if anything, they attempt to weaken the technical requirements in ways that the authors perhaps hope we don't notice.

The basic problem is, and always has been, equitable coexistence between L4S and conventional AIMD traffic.  The entire point of L4S' existence is to convert DCTCP from a scheme that can only be deployed in datacentres, into a scheme that is safe to use on the Internet.  If L4S fails at that basic goal, it has no right to even exist, let alone to take up as much IETF WG time as it has so far.

Buried deep in the text are suggestions that the "few" networks that implement single-queue Classic ECN might apply admission control on L4S traffic, if they do not themselves participate in L4S.  This is a very strange way of doing things: to place requirements on an established network to protect itself from a new proposal, and not even to use language which conveys the strength of the risk posed.

Quoting l4s-arch-07, §8.1:

>   In some cases, networks that solely support Classic ECN [RFC3168] in	
>   a single queue bottleneck might opt to police L4S traffic in order to	
>   protect competing Classic ECN traffic.

Nowhere, in what I have had my attention drawn to, is there a firm description of what network operators and/or technical implementors MUST or SHOULD do to ensure equitable coexistence between L4S and conventional traffic.  There are only vague lists of suggestions as to what MAY be done, OPTIONALLY.  In this assessment I explicitly discount all references to DualQ, for the following reason.

The one in-network L4S component that can tackle this problem, with full knowledge of both traffic types' characteristics, is DualQ.  But DualQ has been shown to fail spectacularly at this simple task, and all suggestions of methods to improve its performance have been flatly ignored.  This includes the very simple technique of applying round-robin delivery scheduling between the two queues, a suggestion which would be entirely in keeping with a desire to keep DualQ simple and suitable for high-speed hardware implementations.

Concerns about interactions at existing network nodes, backed up by significant test data, have been similarly dismissed by the L4S team.  Existing FQ-AQMs at least solve the coexistence problem to a large extent, but do not offer the DCTCP signalling method which L4S relies on for low-latency performance.  But even FQ-AQMs are defeated by many tunnel encapsulations, which hide the distinctions between flows.

So it is very difficult to understand why a WGLC for L4S is being contemplated.  In its current form, I am certain that similarly stiff opposition would be encountered at WGLC as was seen at the consensus call in March.  This is not something that can be addressed by small textual changes to the L4S drafts; it requires a real technical overhaul which genuinely addresses the issues.  Thus far I have seen no willingness to perform such an overhaul.

 - Jonathan Morton