Subject: [tsvwg] problematic numbers in draft-ietf-tsvwg-aqm-dualq-coupled

From: Sebastian Moeller <[email-masked]>
Date: Wed, 15 Sep 2021 11:42:08 +0200

Dear list

https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled#page-38

contains the following text:

"o  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]."

Which as I have already posted in response to PI2param as being factually wrong, but I had not realized that this number had leaked into the draft. 

The measurement this is based on reports for 2019 and each included country the average latency to the fastest CDN (out of a set of 7 CDNs), not the latency averaged over all CDNs, this alone makes the numbers not suited for Bob's purpose here. 
	In addition to that issue the numbers are not sufficiently sanity checked and I believe are giving the wrong impression:

For example Google operated a CDN-node (or similar) in Lagos (Nigeria), and the four Ripe ATLAS nodes active at that time in Nigeria where at most 12ms away, with an average of ~4ms, which is the number Bob used, but if one actually calculates the average latency of these 4 ATLAS nodes to the seven CDNs that were included in the study, Nigeria's average CDN-latency increases to 92.4ms. In other words the 34ms number in the dualQ draft is in all likelihood incorrect, because it is based on a) a misunderstanding what the cited study actually measured and a failure to make sure all included per-country-numbers are sufficiently representative (e.g. a sufficient hight number of probes, spread sufficiently wide over a countries area).
	I consider it worth mentioning, that Bob took the time to discuss the value for China, which appeared unexpectedly large, but failed to sanity check unexpected low RTTs, like Nigeria's. If this section of the draft is supposed to stand, these numbers will need to be put on more solid ground.

But since this exercise actually is intended to give solid backing for the recommended default reference target for the C-queue I would like to propose the following instead:

Heuristically test different values for the C-queue reference latency while looking at:
a) latency under load increase (queueing delay)
b) utilization at different RTTs
c) RTT bias/unfairness if flows of wildly different RTTs share the C-queue

It is well possible that in the light of such data, 15ms might seem like a rational and reasonable compromise, much more so than the current exercise of multiplying three more or less made up numbers and miraculously ending up at the pre-selected 15ms...

Regards
	Sebastian