Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-aqm-dualq-coupled-17.txt

From: [email-masked]
Date: Mon, 04 Oct 2021 06:28:17 -0700

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-17.txt
	Pages           : 58
	Date            : 2021-10-04

Abstract:
   The Low Latency Low Loss Scalable Throughput (L4S) architecture
   allows data flows over the public Internet to achieve consistent low
   queuing latency, generally zero congestion loss and scaling of per-
   flow throughput without the scaling problems of standard TCP Reno-
   friendly congestion controls.  To achieve this, L4S data flows have
   to use one of the family of 'Scalable' congestion controls (TCP
   Prague and Data Center TCP are examples) and a form of Explicit
   Congestion Notification (ECN) with modified behaviour.  However,
   until now, Scalable congestion controls did not co-exist with
   existing Reno/Cubic traffic --- Scalable controls are so aggressive
   that 'Classic' (e.g. Reno-friendly) algorithms sharing an ECN-capable
   queue would drive themselves to a small capacity share.  Therefore,
   until now, L4S controls could only be deployed where a clean-slate
   environment could be arranged, such as in private data centres (hence
   the name DCTCP).  This specification defines `DualQ Coupled Active
   Queue Management (AQM)', which enables Scalable congestion controls
   that comply with the Prague L4S requirements to co-exist safely with
   Classic Internet traffic.

   Analytical study and implementation testing of the Coupled AQM have
   shown that Scalable and Classic flows competing under similar
   conditions run at roughly the same rate.  It achieves this
   indirectly, without having to inspect transport layer flow
   identifiers.  When tested in a residential broadband setting, DCTCP
   also achieves sub-millisecond average queuing delay and zero
   congestion loss under a wide range of mixes of DCTCP and `Classic'
   broadband Internet traffic, 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-17.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-aqm-dualq-coupled-17

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 4 Oct 2021 14:33:14 +0100

Pls ignore this revision - I posted it after switching from v2 to v3 of 
the XML without making any changes to the content, just so as not to 
pollute the subsequent diff.
Reason: v3 introduces some arbitrary format changes throughout the doc 
(e.g. different bullet style, different table style, etc.

Bob

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

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 19 Oct 2021 11:19:07 +0200

Dear All,

After Bob's announcement I waited for versipn 18 to show up, but since that has not happened and my concern hopefully will result on a change on the DualQ draft, I will bring this up again.

with some disillusionment I find that version 17 of this text still contains the following factually wrong assertion:

"  *  RTT_typ is taken as 34 ms.  This is based on an average CDN
      latency measured in each country weighted by the number of
      Internet users in that country to produce an overall weighted
      average for the Internet [PI2param]."

The study that was mis-understood/-represented here, reported the average RTT from (1 to 50) measurement endpoints (in the ripe ATLAS measurement network) to the one of 7 CDNs that in a given country resulted in the lowest average RTT. That is NOT the average CDN latency in any meaningful sense. See https://mailarchive.ietf.org/arch/msg/tsvwg/yNWAPHhgVX3fou3xugtVjXZ0F3U/ for a detailed break-down for the case of Nigeria (relevant because Nigeria has a large population, and Bob, claimed an average RTT-2-CDN of 4ms for Nigeria, without ever questioning the plausibility of that claim).

This issue is important because it affects the default latency target choice for the C-queue in the reference DualQ AQM, which is still  not properly determined in spite of its choice having a noticeable effect on DualQs increased RTT-bias, that TCP Prague proved unable to fix generically.* 

I have posted before on this issue, and not even received an acknowledgment that my objection has been registered, let alone whether there is a plan to remedy the issue. I am fine with this taking time, but I would like to at least get an ACK.

Best Regards
	Sebastian

*) The found work-around, that apparently is disabled in the TCP Prague repository, is to make TCP Prague pretend its RTT is at least 15ms**, but that only works if the end-point TCPs are configured with exactly the same number as the bottleneck AQMs along the path, and the 15ms target is a) just a weak default recommendation and b) not even properly justified 
**) Which clearly does not solve the issue, it only tackles the case where the resulting unfairness is most obvious, extremely short RTTs, a gernic solution would at least make TCP Pragues CWND growth function behave as if all RTT were 15ms larger than the actually measured RTT. But that is pretty much moot, as this seems to be disabled in TCP Prague anyways.

> On Oct 4, 2021, at 15:28, [email-masked] wrote:
> 
>