Re: [tsvwg] I-D Action: draft-ietf-tsvwg-aqm-dualq-coupled-18.txt

[Sebastian Moeller <[e-mail]>]

Dear All,

The current version countains:

"For instance, it is recommended that the operator chooses R_b = 25
   ms, as a typical base RTT between Internet users and CDNs [
PI2param]."

The source data reports the average RTT to the closest of 7 CDNs for each country for a sample of 1-50 randomly selected nodes (for countries with less than 50 measurement probes, obviously it "randomly" selected all*). 
This is NOT a typical base RTT between Internet users and CDNs by any scientific standard. Since I have spend time and effort to clear up what appeared to be a genuine misunderstanding of the source-data, I am am puzzled why this still is not represented correctly. This is exactly why I do not trust any numbers presented by team L4S without scrutiny as I see a clear lack of sufficient attention to getting details right.


*) Prime example Nigeria, which only had one CDN location (~Lagos) in 2019 and only 4 measurement probes, with the furthest 12ms away from that CDN, resulting in an impressive 4ms "typical base RTT between Internet users and CDNs" completely ignoring that 4 measurement nodes in the vicinity of Lagos are not representative of the locations of all Nigerian internet users. Numerically the number is correct, but calling it a veridical description of "typical base RTT between Internet users and CDNs" is simply misleading. Initially that might have been a genuine oversight, but after my clarifications and dive into the source data, I consider this to be consciously misleading. Is that really what an IETF endorsed RFC should contain?


and later in the draft:
" *  [PI2param
] recommends target = RTT_typ * g * f = 25ms * 0.38 * 2 =
      19 ms.  However a further adjustment is warranted, because target
      is moving year on year.  The paper is based on data collected in
      2019, and it mentions evidence from speedtest.net that suggests
      RTT_typ reduced by 17% (fixed) or 12% (mobile) between 2020 and
      2021.  Therefore we recommend a default of target = 15 ms at the
      time of writing (2021)."


This is clearly still deficient. It is a well demonstrated fact that PIE with a target of 15ms works pretty well (with acceptable utilization, and did so since PIE wasd introduced some years ago) for traffic with at least 100ms RTT, it therefore is counter-factual to claim that the target for 25ms paths should be 19ms. For example https://datatracker.ietf.org/doc/html/rfc8034#page-5 DOCSIS PIE recommends a classic target of 10ms (published 2017). 
IMHO this clearly indicates that the theory presented how to deduce the classic target is insufficient... as it clearly results in inflated numbers. So the fix needs to be in adjusting the flawed theory/model and not in fudging the input numbers until the desired output number appears....

	As is, this still seems like an exercise to retro-actively "justify" the selection of a 15ms classic target, instead of doing a bit of empiric research to see what the consequences of different classic targets are for the measures of relevance (here probably RTT fairness, queueing delay distribution, utilization, measured for traffic with typical internet-scale distributions of RTTs) and recommending a target that balances performance along all relevant dimensions.





Regards
	Sebastian






> On Oct 26, 2021, at 00:54, [e-mail] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the IETF.
> 
>        Title           : DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)
>        Authors         : Koen De Schepper
>                          Bob Briscoe
>                          Greg White
> 	Filename        : draft-ietf-tsvwg-aqm-dualq-coupled-18.txt
> 	Pages           : 60
> 	Date            : 2021-10-25
> 
> Abstract:
>   This specification defines a framework for coupling the Active Queue
>   Management (AQM) algorithms in two queues intended for flows with
>   different responses to congestion.  This provides a way for the
>   Internet to transition from the scaling problems of standard TCP
>   Reno-friendly ('Classic') congestion controls to the family of
>   'Scalable' congestion controls.  These achieve consistently very Low
>   queuing Latency, very Low congestion Loss and Scaling of per-flow
>   throughput (L4S) by using Explicit Congestion Notification (ECN) in a
>   modified way.  Until the Coupled DualQ, these L4S senders could only
>   be deployed where a clean-slate environment could be arranged, such
>   as in private data centres.  The coupling acts like a semi-permeable
>   membrane: isolating the sub-millisecond average queuing delay and
>   zero congestion loss of L4S from Classic latency and loss; but
>   pooling the capacity between any combination of Scalable and Classic
>   flows with roughly equivalent throughput per flow.  The DualQ
>   achieves this indirectly, without having to inspect transport layer
>   flow identifiers and without compromising the performance of the
>   Classic traffic.  The solution has low complexity and requires no
>   configuration for the public Internet.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm-dualq-coupled-18.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-aqm-dualq-coupled-18
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
>