Subject: [tsvwg] Updates to all 3 main L4S drafts (mostly minor)

From: Bob Briscoe <[email-masked]>
Date: Mon, 16 Nov 2020 09:40:26 +0000

tsvwg, and chairs,

You will have seen all three main L4S drafts were updated again last night.

Summary of changes:

l4s-arch: https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-08
All editorial:
* squashed any misconceptions that this is only about TCP, starting 
earlier in the doc
* fixes to confusion between protocols and CC algorithms, esp regarding 
RTP pointed out by Ingemar
* cited a recent official IETF RFC about honouring layering to enable 
encryption, rather than Kevin Smith's individual draft.
* added Ingemar's use case about reducing dejitter buffer on receiver
* spell-checked and grammar checked.

ecn-l4s-id: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-12
Technical / normative
* changed overload protection from SHOULD to MUST
* new normative wording of RTT-bias requirement (initiated by Gorry 
offlist).
* added IANA allocation of ECT(1)
Editorial
* MWelzl's improvement to the abstract
* I reviewed Appendix A for consistency with recent changes, and nits
* spell-checked and grammar checked.

aqm-dualq-coupled: 
https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-13
Editorial
* Improved description of Tom's contribution (with Tom's agreement)
* spell-checked and grammar checked.

Bob

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

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 16 Nov 2020 11:09:30 +0100

Dear chairs,

> On Nov 16, 2020, at 10:40, Bob Briscoe <[email-masked]> wrote:
> 
> tsvwg, and chairs,
> 
> * squashed any misconceptions that this is only about TCP, starting earlier in the doc
> * fixes to confusion between protocols and CC algorithms, esp regarding RTP pointed out by Ingemar
> * cited a recent official IETF RFC about honouring layering to enable encryption, rather than Kevin Smith's individual draft.
> * new normative wording of RTT-bias requirement (initiated by Gorry offlist).

	[SM] 

"A scalable congestion control MUST eliminate RTT bias as much as
      possible in the range between the minimum likely RTT and typical
      RTTs expected in the intended deployment scenario (see Appendix A.1.5 for rationale)."

This is still wrong, as Pete Heist's data demonstrated, the TCP Prague/DualPi2 combination will result in even more RTT bias than typical in the current internet with Cubic/Reno and dumb FIFO bottlenecks. Giving L4S a pass here amounts to giving the WG's blessing to building a fast lane to close by targets. 
	I have addressed the list with my objection towards the proposed change, and repeat my objection again. This is making a bad situation worse. 

	I also object against the term "typical RTT" which is how team L4S names what AQM RFCs like Codel's and PIE's call the latency target or acceptable standing queue, it helps nobody to re-name this term now (even if typical RTT would be a better description, which it is not), it rather indicates that the authors might not have read or understood the existing RFCs sufficiently well.

Best Regards
	Sebastian

> aqm-dualq-coupled: https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-13
> Editorial

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 16 Nov 2020 11:21:42 +0000

Sebastian,

> 	I have addressed the list with my objection towards the proposed change, and repeat my objection again. This is making a bad situation worse.

[SM] You are mixing criticism of an implementation (which we need to 
address) with criticism of a goal written in the draft.

> 	I also object against the term "typical RTT" which is how team L4S names what AQM RFCs like Codel's and PIE's call the latency target or acceptable standing queue, it helps nobody to re-name this…

[BB] It's the other way round. PIE and Codel set their default target to 
work well with what their implementation communities believes is a 
typical RTT for its deployment. Note that says 'work well with', not 
'equal to' (see 'detail' below). There are also pressures to set the 
operating point of an AQM lower than the typical RTT, to get lower delay 
benchmark figures at the expense of a little under-utilization.

The IETF does not define a requirement relative to what a certain 
implementation community decides an implementation parameter default 
should be, because it's subject to all the above noise. In contrast, the 
'typical RTT' in the intended deployment scenario is measurable and 
widely reported from measurement studies.

_____________
Detail:
There is a further complication in that the variable called 'target' in 
different AQMs means different things.
* In CoDel you would set target below the operating point you want. 
target is more like a minimum, above which the CoDel machinery starts 
its interval timer.
* In PIE's case, you would set target roughly to the operating point you 
want, because the PI controller aims for it from above and below.
That's part of the reason for the difference between the two defaults 
for the targets (CoDel: 5ms, PIE: 15ms).
But there's also different judgements about the relative importance of 
low Q delay vs utilization.

Sorry, I had noticed this misconception in earlier emails and let it go, 
so I thought I should pick it up here.
For more on this distinction, see:
Khademi, N.; Ros, D. & Welzl, M. "The new AQM kids on the block: An 
experimental evaluation of CoDel and PIE" IEEE 17th Global Internet 
Symposium (GI 2014), 2014

Regards

Bob

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Nov 2020 11:24:02 +0000

See bwlow.

> 	I also object against the term "typical RTT" which is how team L4S names what AQM RFCs like Codel's and PIE's call the latency target or acceptable standing queue, it helps nobody to re-name this…

Noted, and I agree appropiate words need to be found.

I like that this expresses a desire to control RTT bias, rather than a 
requirement to eliminate.

I do see differences in the term "latency target" and "typical RTT", but 
I can see that "typical" is not so helpful - what's typical for one is 
not for another, for an Internet transport spec.

Gorry

-- 
G. Fairhurst, School of Engineering

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 16 Nov 2020 12:41:13 +0100

Hi Bob,

more below in-line, pre-fixed [SM2].

> On Nov 16, 2020, at 12:21, Bob Briscoe <[email-masked]> wrote:
> 
> Sebastian,
> 
> [SM] You are mixing criticism of an implementation (which we need to address) with criticism of a goal written in the draft.

	[SM2] At this point I am not convinced that this is an implementation issue, but rather an unavoidable consequence of your AQM and protocol design. Sure that is fixable, but will likely require changes to the design and not just the implementation. But if you come up with patches that make the issue disappear in the implementation alone I would also be positively surprised.

> [BB] It's the other way round.

	[SM2] Then why do neither of the other RFCs use the term "typical RTT", and why do both claim to work well with the default settings for RTTs in the range from "0"->100 ms? 

> PIE and Codel set their default target to work well with what their implementation communities believes is a typical RTT for its deployment.

	[SM2] Please re-read the Codel RFC, the latency target is a direct function of the selection of the interval, sure the interval has some rationale in expectesd RTTs, but there the default is 100ms, there is a nice section on TARGET :

"TARGET is the maximum acceptable persistent queue delay above which
   CoDel is dropping or preparing to drop and below which CoDel will not
   drop.  TARGET SHOULD be set to 5 ms for normal Internet traffic.

   The calculations of Section 3.2 show that the best TARGET value is
   5-10% of the RTT, with the low end of 5% preferred.  Extensive
   simulations exploring the impact of different TARGET values when used
   with mixed traffic flows with different RTTs and different bandwidths
   show that below a TARGET of 5 ms, utilization suffers for some
   conditions and traffic loads; above 5 ms showed very little or no
   improvement in utilization."

This is not compatible with typical RTT, really. 

> Note that says 'work well with', not 'equal to' (see 'detail' below). There are also pressures to set the operating point of an AQM lower than the typical RTT, to get lower delay benchmark figures at the expense of a little under-utilization.
> 
> The IETF does not define a requirement relative to what a certain implementation community decides an implementation parameter default should be, because it's subject to all the above noise. In contrast, the 'typical RTT' in the intended deployment scenario is measurable and widely reported from measurement studies.

	[SM2] Look, my argument boils down to, stick to the established nomenclature,  even if you disagree. By all means add a section in which you explain your interpretation of what the latency target should be interpreted as. 

	More to the point:
https://tools.ietf.org/html/rfc8033:
 		[PIE] can effectively control the average queuing latency to a target value

https://tools.ietf.org/html/rfc8289#section-4.3:
A congested (but not overloaded) CoDel link with traffic composed
   solely or primarily of long-lived TCP flows will have a median delay
   through the link that will tend to the target.

We can quibble all day that a mean is not a median, but it is clear to anybody having read those RFCs that neither target is thought of in terms of a flow's RTT, which is implied by the term "typical RTT".

> 
> _____________
> Detail:
> There is a further complication in that the variable called 'target' in different AQMs means different things.
> * In CoDel you would set target below the operating point you want. target is more like a minimum, above which the CoDel machinery starts its interval timer.
> * In PIE's case, you would set target roughly to the operating point you want, because the PI controller aims for it from above and below.
> That's part of the reason for the difference between the two defaults for the targets (CoDel: 5ms, PIE: 15ms).

	[SM2] you notice that these differences are quite minor compared to your "typical RTT" interpretation. Since DualQ really just used modified PIEs it really really should stick to the nomenclature established be the PIE RFCs.

> But there's also different judgements about the relative importance of low Q delay vs utilization.
> 
> Sorry, I had noticed this misconception in earlier emails and let it go, so I thought I should pick it up here.
> Khademi, N.; Ros, D. & Welzl, M. "The new AQM kids on the block: An experimental evaluation of CoDel and PIE" IEEE 17th Global Internet Symposium (GI 2014), 2014

	[SM2] A reference is not an argument... What is your point?

Best Regards
	Sebastian

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 16 Nov 2020 15:11:31 +0000

Sebastian,

> 	[SM2] At this point I am not convinced that this is an implementation issue, but rather an unavoidable consequence of your AQM and protocol design. Sure that is fixable, but will likely require ch…

[BB] It is true that RTT bias is intrinsic to using Reno-like 
window-based AIMD (which is what was in DCTCP, which we built off).
The way Koen & Olivier modified the design is one of a number of ways to 
do this. BBRv2 does it a different way.

Pls explain why you are trying to blame L4S for this. It's a problem 
with any attempt to cut out queuing delay. Why didn't you point out the 
increased RTT bias in the Internet when CoDel or PIE reduced queue 
delay? The difference is that the L4S proponents drew attention to the 
issue from day 1.

> 	[SM2] Then why do neither of the other RFCs use the term "typical RTT", and why do both claim to work well with the default settings for RTTs in the range from "0"->100 ms?

[BB] There are 8 occurrences of 'typical RTT' in aqm-dualq-coupled

Typical RTT is not formally defined, but the point is that it takes the 
normal meaning of the word 'typical', i.e. the most common (or if you 
want to be formal, the mode of the distribution of all the RTTs that 
average users access).

This clearly shows you have never read the draft, because 'typical RTT' 
is a central concept in the management section (and well-illustrated in 
the configuration internals shown in the header file (Fig 2) of the 
DualPI2 appendix).
The management API takes the human-understandable concepts of typical 
RTT and max RTT and uses them to calculate the internal AQM parameters.

It means you could drop DualPI2 (or any DualQ algorithm, e.g. Curvy RED) 
into a particular private network (e.g. corporate, or DC, or set of 
interconnected DCs) and type in the typical and max RTTs, and it 
auto-configures the internal parameters.

I guess it would be too much to ask you to be impressed by this API.

>     drop.  TARGET SHOULD be set to 5 ms for normal Internet traffic.

[BB] That is exactly what I just said, quoting from my text at the 
bottom of this thread:
"In CoDel you would set target below the operating point you want. 
target is more like a minimum, above which the CoDel machinery starts 
its interval timer."

>     5-10% of the RTT, with the low end of 5% preferred.

[BB] I know the CoDel RFC says this, and it doesn't help anyone, because 
no-one knows what it means by 'the RTT'.
For instance, if you deploy CoDel in an access link, by definition, that 
link gives access to all the RTTs on the Internet (other than any 
machines on your side of the access link). RTTs over an access link to 
the Internet range from ~3ms to 200ms.

Perhaps each time a user wants to click a link, they are meant to hover 
over the link, ping the server that the link points to, login to their 
home router, reconfigure their CoDel to 5% of that, then click the link? 
At least, when they finally get the page, the delay will be perfect :)

> Extensive

[BB] That's a problem with the paragraph, not with the term 'typical RTT'.
The above paragraph is presumably about the public Internet. It doesn't 
include any concept of the distribution of RTTs experienced by most 
users. So it is certainly not compatible with a useful term like 
'typical RTT'.

> 	[SM2] Look, my argument boils down to, stick to the established nomenclature,  even if you disagree. By all means add a section in which you explain your interpretation of what the latency target…

[BB] Typical RTT starts from the real world, to help operators know how 
to configure a machine for /their/ scenario. You don't have that useful 
approach in CoDel. So, no, we're not going to stick to the bad practice 
of telling people what to set internal parameters to. Which doesn't help 
anyone unless they have all the same presumptions as the community that 
wrote the advice.

>     through the link that will tend to the target.

[BB] But CoDel's median delay does /not/ tend to target. Read the paper 
I pointed you at. That's the point. Two different AQMs each give one of 
their parameters the name 'target'. But, if you set them both to the 
same value, you don't get the median in the same place. Why am I not 
surprised - this is a parameter that happens to have been given the same 
name. But they both have very different functions, as I already 
explained (still quoted at the bottom of this thread).

> We can quibble all day that a mean is not a median, but it is clear to anybody having read those RFCs that neither target is thought of in terms of a flow's RTT, which is implied by the term "typic…

[BB] No-one has mentioned mean. But anyway, I'm not sweating about any 
distinction between median and mode here. I'm explaining to you why 
Typical RTT is a useful config parameter, particularly for an operator's 
general-purpose management system, so they can set it once, and it can 
be internally translated into the specific parameters need for different 
AQM algorithms on different equipment.

The CoDel and PIE RFCs don't even have a section about operations and 
management (I don't know how they got through the IETF's operations area 
review without one). They also have nothing about gathering stats.

> 	[SM2] you notice that these differences are quite minor compared to your "typical RTT" interpretation.

[BB] Opinion.

Anyway, not the point. 'Typical RTT' is a human-comprehensible 
parameter. It might well map to values that are close for two different 
algorithms, but it might not for others (e.g. Curvy RED).

> Since DualQ really just used modified PIEs it really really should stick to the nomenclature established be the PIE RFCs.

[BB] I think you just missed the point big-time. DualQ does not "just 
use modified PIEs" DualPI2 is one example in aqm-dualq-coupled, which is 
a framework for different algorithms. Curvy RED is given as another 
example (which is implemented in the Broadcom StrataDNX chipsets).

Why do you have to make everything /you/ don't understand into a 
criticism of others?

Bob

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 16 Nov 2020 18:33:47 +0100

Hi Bob,

more below in-line, pre-fixed [SM3]

> On Nov 16, 2020, at 16:11, Bob Briscoe <[email-masked]> wrote:
> 
> Sebastian,
> 
> [BB] It is true that RTT bias is intrinsic to using Reno-like window-based AIMD (which is what was in DCTCP, which we built off).

        [SM3] Let me repeat it once more and let it sink in, RTT bias, as you call it is an unavoidable consequence of tight control loops being nimbler than loose control loops. A properly configured TCP will be able to (almost) saturate any given link (within reason, I am not claiming that current TCPs scale ad infinitum, as that is not the point here), demonstrating clearly that the RTT-dependent throughput loss a long RTT TCP will gain compared to a shorter RTT TCP is not a function of RTT, but it is a consequence of the interaction of the different RTT flows TCPs at the bottleneck buffer. Clearly that management unit of that buffer, active or advances or what ever you may call it, is in the best position trying to ameliorate that effect.

> The way Koen & Olivier modified the design is one of a number of ways to do this. BBRv2 does it a different way.

	[SM3] The point is compared to PIE with two Cubics and even a FIFO with two CUBICS, DualPI2+TCP Prague make the situation noticeably worse, you increase the effect you call RTT-dependence, and that is something I consider a design flaw, unless the stated goal is to built a sort-RTT, low hop-count fast-lane. But according to your internet drafts the TCP Prague DualPI2 combination is supposed to be suitable for internet wide roll-out.
	Let's leave BBRv1/2 out of this discussion and focus on L4S, please.

> 
> Pls explain why you are trying to blame L4S for this.

	[SM3] I am not blaming L4S for anything, I am looking at the data and describe what L4S does, that are two different things.

Let's look at some data, shall we?
This is a plot showing the rates achieved by two CUBIC flows (80ms pRTT and 20 ms pRTT) in a bottlenech with a 200 packet FIFO at an egress rate of 50 Mbps
http://sce.dnsmgr.net/_archive/l4s-2020-11-07T203721-s1-s4/l4s-s1-rttfair/l4s-s1-rttfair-ns-cubic-vs-cubic-pfifo_200_-10Mbit-80ms-20ms_tcp_delivery_with_rtt.svg
Both flows actually get more or less the same thoughput.
	Now adding an AQM we expect things to get worse, especially single queue AQMs are known to do that, so here are "same" two CUBIC flows under the same conditions only the bottleneck now operates DualPI2 but since the flows are not ECT(1) they are handled by the PIE instance responsible for the shallow queue:
http://sce.dnsmgr.net/_archive/l4s-2020-11-07T203721-s1-s4/l4s-s1-rttfair/l4s-s1-rttfair-ns-cubic-vs-cubic-dualpi2-50Mbit-80ms-20ms_tcp_delivery_with_rtt.svg
Here eye-balling it tells us that the 80ms pRTT flow only gets around half the thoughput of the 20ms one, not beautiful, but certainly acceptable by the concurrent decrease of the flows' queueing delay (roughly a reduction of 230ms per flow).
	But now, if we look at the same test with two TCP Prague flows running through the shallow-queue's modified? PIE instance we see a throughput imbalance of around 45:5 Mbps or 9:1.
	So from rough parity we went down to 9:1, that IMHO is a clear design issue in L4S because who in their right mind is going to use TCP Prague if that basically means such steep sacrifices in throughput through longer paths? Really, it is not that 80ms is an extreme RTT that is irrelevant, think trans Atlantic links.

	Trying to frame this as somehow reducing RTT bias seems simply counterfactual, L4S is making the situation worse (while using wording that makes the naive reader think it helps solving the issue).

What is wrong in that assessment?

> It's a problem with any attempt to cut out queuing delay.

	[SM3] It pains me to say, but your deep queue does a much better job, it still reduces the queueing delay by orders of magnitude, without introducing a level of RTT bias not witnessed before on the internet. And the 15ms latency target is by far not the last word in how ow you can go... (fq_codel does fine with a target of 5ms, and classic PIE with intact burst tolerance will also allow smaller targets without sacrificing too much throughput).

> Why didn't you point out the increased RTT bias in the Internet when CoDel or PIE reduced queue delay? The difference is that the L4S proponents drew attention to the issue from day 1.

	[SM3] Simply, because you bring the issue to a whole new game. Here is how the dual CUBIC test looks in fq_codel:
http://sce.dnsmgr.net/_archive/l4s-2020-11-07T203721-s1-s4/l4s-s1-rttfair/l4s-s1-rttfair-ns-cubic-vs-cubic-fq_codel-50Mbit-80ms-20ms_tcp_delivery_with_rtt.svg
Way less than the factor two throughput difference as seen in your PIE example. Judging from Figure 6 in Høiland-Jørgensen, Toke, Per Hurtig, and Anna Brunstrom. ‘The Good, the Bad and the WiFi: Modern AQMs in a Residential Setting’. Computer Networks 89 (4 October 2015): 90–106. https://doi.org/10.1016/j.comnet.2015.07.014. single-queue CoDel will behave quite close to songle-queue PIE.
	But neither PIE nor Codel claimed to have solved RTT bias, unlike the L4S drafts that imply that the transport protocol could fix what your AQM deliberately breaks...

> [BB] There are 8 occurrences of 'typical RTT' in aqm-dualq-coupled

	[SM3] Well, replace these with latency target, or queueing target, and explain, why you believe that the magnitude should be matched to some specific expected RTT.

> 
> Typical RTT is not formally defined, but the point is that it takes the normal meaning of the word 'typical', i.e. the most common (or if you want to be formal, the mode of the distribution of all the RTTs that average users access).

	[SM3] The argument I make is, "keep to the established nomenclature". Which holds doubly, since you build up on PIE, so using the matching terms as the PIE RFC will make things easier to follow and understand to the reader.

> 
> This clearly shows you have never read the draft, because 'typical RTT' is a central concept in the management section (and well-illustrated in the configuration internals shown in the header file (Fig 2) of the DualPI2 appendix).

	[SM3] I read it, but just because you repeat something it does not magically become true. And it does not retroactively change the nomenclature on the work you build up upon, like the PIE RFC.

> The management API takes the human-understandable concepts of typical RTT and max RTT and uses them to calculate the internal AQM parameters.
> 
> It means you could drop DualPI2 (or any DualQ algorithm, e.g. Curvy RED) into a particular private network (e.g. corporate, or DC, or set of interconnected DCs) and type in the typical and max RTTs, and it auto-configures the internal parameters.

	[SM3] And given how PIE operates, it would still be wrong...	

> I guess it would be too much to ask you to be impressed by this API.

	[SM3] Well, howabout getting a working design and implementation first, before worrying about additional layers of abstraction?

> [BB] That is exactly what I just said, quoting from my text at the bottom of this thread:
> "In CoDel you would set target below the operating point you want. target is more like a minimum, above which the CoDel machinery starts its interval timer."

	[SM3] Yes, and then you claim that this is completely different from what target specified in PIE. I grant you they are not identical, but they are quite similar on the design level, they are one of the reference measures used to determine whether the AQM should intervene.

> [BB] I know the CoDel RFC says this, and it doesn't help anyone, because no-one knows what it means by 'the RTT'.

	[SM3] I think you might want to re-read at  Section 3.2 of the CoDel RFC again, like it says in the quoted text. This section, accidentally comes before the elaboration of TARGET cited above. So an avid reader of the RFC, by that point already knows about RTT in this context.

> For instance, if you deploy CoDel in an access link, by definition, that link gives access to all the RTTs on the Internet (other than any machines on your side of the access link). RTTs over an access link to the Internet range from ~3ms to 200ms.

	[SM3] Yes, properly discussed in the CoDel RFC "4.2.  Setting INTERVAL", again, maybe re-read this next time before arguing about it?

> 
> Perhaps each time a user wants to click a link, they are meant to hover over the link, ping the server that the link points to, login to their home router, reconfigure their CoDel to 5% of that, then click the link? At least, when they finally get the page, the delay will be perfect :)

	[SM3] And again, please re?-read the CoDel RFC you will find it addresses your points. Maybe not to the level you desire, but certainly more so than you seem to believe.

> The above paragraph is presumably about the public Internet. It doesn't include any concept of the distribution of RTTs experienced by most users. So it is certainly not compatible with a useful term like 'typical RTT'.

	[SM3] Well, it would again be rather helpful, if you would read though the whole RFC and only then start to make hypotheses?

> [BB] Typical RTT starts from the real world, to help operators know how to configure a machine for /their/ scenario. You don't have that useful approach in CoDel. So, no, we're not going to stick to the bad practice of telling people what to set internal parameters to. Which doesn't help anyone unless they have all the same presumptions as the community that wrote the advice.

	[SM3] Look the connection between PIE's and CoDel's target parameters an a "typical RTT" exists mostly in your mind, either do a better job in the internet draft to explain, why you absolutely feel that the term needs to be re-defined or accept that existing nomenclature with known meaning has its own merits (even if the term could be better).

> [BB] But CoDel's median delay does /not/ tend to target.

	[SM3] But Bob, it does, taken from y own repeated measurements.

> Read the paper I pointed you at.

	[SM3] Well I did years ago. 

> That's the point. Two different AQMs each give one of their parameters the name 'target'. But, if you set them both to the same value, you don't get the median in the same place. Why am I not surprised - this is a parameter that happens to have been given the same name. But they both have very different functions, as I already explained (still quoted at the bottom of this thread).

	[SM3] Well, since you are easily confused, then just stick to the precedence in the PIE RFC which certainly is more topical for DulaPI2 and ignore the fact that Codel has a very similar toggle with a similar name. See how this does not make your gratuitous re-naming the same parameter in your version of PIE any more convincing.

> [BB] No-one has mentioned mean. But anyway, I'm not sweating about any distinction between median and mode here. I'm explaining to you why Typical RTT is a useful config parameter, particularly for an operator's general-purpose management system, so they can set it once, and it can be internally translated into the specific parameters need for different AQM algorithms on different equipment.

	[SM3] And calling Pi the circle-number has the same properties of being (slightly) more understandable for naive novices, and yet the word has stuck to Pi whih needs to be understood before usage.
	Also, I doubt that a user mostly using trans-atlantic flows with RTT in the 100ms range, will be happy with a PIE instance with target set to 100ms (nor would a CoDel user)... typical RTT might be a term a novice might think he/she understands the consequences of changing it, but I am not convinced that believe is actually true. In that case, actually not trying to give it an easy to mis-understand name might be doing the user a better service.

> 
> The CoDel and PIE RFCs don't even have a section about operations and management (I don't know how they got through the IETF's operations area review without one).

	Well, re-read the 4.2.  Setting INTERVAL section of the CoDel RFC again, as well as Appendix A. And next time preferably before making predictions about what the RFC might contain, please?

> They also have nothing about gathering stats.

	[SM3] How did that enter the discussion?

>> 	[SM2] you notice that these differences are quite minor compared to your "typical RTT" interpretation.

	[SM3] True, opinion based op actually having read both RFC as well as supporting papers.

> 
> Anyway, not the point. 'Typical RTT' is a human-comprehensible parameter.

	[SM3] Well, again see my example above, will a user with most flows in the 100ms range really be well served with setting typical RTT to 100ms? I severely doubt that...

> It might well map to values that are close for two different algorithms, but it might not for others (e.g. Curvy RED).

	[SM3] Well, let's tackle Curvy RED the time someone offers an internet draft or a paper describing it. 

> [BB] I think you just missed the point big-time. DualQ does not "just use modified PIEs" DualPI2 is one example in aqm-dualq-coupled, which is a framework for different algorithms. Curvy RED is given as another example (which is implemented in the Broadcom StrataDNX chipsets).

	[SM3] -ENOINTERNETDRAFT_SUBMITTED, 

> 
> 
> Why do you have to make everything /you/ don't understand into a criticism of others?

	[SM3] ??? I do not agree with your assessment, and will leave it at that.

Bob, the point is typical RTT is a) wrong-ish (or at least requires ample context so that your reader will not set this to 100ms for a transatlantic, or 600ms for a geostationary satellite path, and b) is against established precedence.
	But I made my point, which I am sure will be ignored, and the next draft will proudly fly the "typical RTT" banner even higher...

Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 16 Nov 2020 19:34:22 +0100

Bob,

one thing requires special attention

> [...]
> Anyway, not the point. 'Typical RTT' is a human-comprehensible parameter. It might well map to values that are close for two different algorithms, but it might not for others (e.g. Curvy RED).

	[SM] To date DualI2 is the only L4S AQM for which any data has been published (IMHO neither deep or broad enough in scope to cover important conditions under which L4S is going to have to operate if deployed into the existing internet). Before CurvyRED has at least seen the same (still unimpressive) level of data showing its functionality under "internet" conditions, it seems rather far-fetched to argue that the DualQ draft is improved by the "typical RTT" re-naming of PIEs target to allow for plugging in different AQMs.
	Personally I am convinced by now, that the biggest issue DualQ has is not so much which AQM you base its two sibling AQMs on, but the fact that the leaky coupling between the queues, simply is not a robust and reliable solution to the underlaying hard problem. 
	Sure, it sounds elegant and maybe even charming at first, until one considers all the heuristic gunk and border-line layer-violations necessary to make it survive the modicum of testing it has seen, like the 15ms hack in TCP Prague's CC response dynamics...

Best Regards
	Sebastian

---

From: Sebastian Moeller <[email-masked]>
Date: Mon, 16 Nov 2020 19:58:27 +0100

Below.

> On Nov 16, 2020, at 12:24, Gorry Fairhurst <[email-masked]> wrote:
> 
> See bwlow.
> 
> I like that this expresses a desire to control RTT bias, rather than a requirement to eliminate.
> 
> I do see differences in the term "latency target" and "typical RTT", but I can see that "typical" is not so helpful - what's typical for one is not for another, for an Internet transport spec.

	What is more, this parameter is not really meaningfully directly related to RTT, neither minimal, maximal or typical. Naming it typical RTT is going to cause more harm than god (aka confusion), assuming these internet drafts will be advanced, but as far as I can tell that is pretty much settled already.
	In PIE the target delay is the reference-point which is used to measure current queue length/sojourn time against to figure out how (and by how much) to change the drop probability. Like the latency target in CoDel that is much better understood as the acceptable standing queue length measured in time to empty it, than as any specific RTT. It seems somewhat counter-intuitive that a project as interested in low queueing delay as L4S, manages to mis-understand and re-name a parameter that is almost directly implicated in queueing delay and not in RTT. 
	For what it is worth, the shorter the true RTTs of the flows traversing a link, the smaller a reference queueing delay target can be set without resulting in too large a utilization drop, but that is not the same thing as implying that target should match the dominant RTT across a link. On a transatlantic link with a minimum RTT ~100ms, a target value of 15ms is still going to better by leaps and bound than 100ms, unless all one cares for is pure throughput. In fact the default target of 15ms should get somewhere between 97 and 99% utilization at an test RTT of 100ms (according to PIE: A Lightweight Control Scheme to Address the Bufferbloat Problem).

Best Regards
	Sebastian