This is why pping's use of tcp timestamps is elegant, little incentive for the endpoints to fudge....

Regards
Sebastian

On 12 April 2022 18:00:15 CEST, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

Who or what are you objecting against? At least nothing that I described does what you suggest.

BTW, just as a side point, for QUIC, routers can know the RTT today - using the spin bit, which was designed for that specific purpose.

Cheers,
Michael

On Apr 12, 2022, at 5:51 PM, David P. Reed <dpreed@deepplum.com> wrote:

I strongly object to congestion control *in the network* attempting to measure RTT (which is an end-to-end comparative metric). Unless the current RTT is passed in each packet a router cannot enforce fairness. Period.

Today, by packet drops and fair marking, information is passed to the sending nodes (eventually) about congestion. But the router can't know RTT today.

The result of *requiring* RTT fairness would be to put the random bottleneck router (chosen because it is the slowest forwarder on a contended path) become the endpoint controller.

That's the opposite of an "end-to-end resource sharing protocol".

Now, I'm not saying it is impossible - what I'm saying it is asking all endpoints to register with an "Internet-wide" RTT real-time tracking and control service.

This would be the technical equivalent of an ITU central control point.

So, either someone will invent something I cannot imagine (a distributed, rapid-convergence algortithm that rellects to *every potential user* of a shared router along the current path the RTT's of ALL other users (and potential users).

IMHO, the wish for RTT fairness is like saying that the entire solar system's gravitational pull should be equalized so that all planets and asteroids have fair access to 1G gravity.

On Friday, April 8, 2022 2:03pm, "Michael Welzl" <michawe@ifi.uio.no> said:

Hi,
FWIW, we have done some analysis of fairness and convergence of DCTCP in:

Peyman Teymoori, David Hayes, Michael Welzl, Stein Gjessing: "Estimating an Additive Path Cost with Explicit Congestion Notification", IEEE Transactions on Control of Network Systems, 8(2), pp. 859-871, June 2021. DOI 10.1109/TCNS.2021.3053179

Technical report (longer version):

https://folk.universitetetioslo.no/michawe/research/publications/NUM-ECN_report_2019.pdf

and there’s also some in this paper, which first introduced our LGC mechanism:

https://ieeexplore.ieee.org/document/7796757

See the technical report on page 9, section D: a simple trick can improve DCTCP’s fairness (if that’s really the mechanism to stay with… I’m getting quite happy with the results we get with our LGC scheme :-) )

Cheers,

Michael

On Apr 8, 2022, at 6:33 PM, Dave Taht <dave.taht@gmail.com> wrote:

I have managed to drop most of my state regarding the state of various
dctcp-like solutions. At one level it's good to have not been keeping
up, washing my brain clean, as it were. For some reason or another I
went back to the original paper last week, and have been pounding
through this one again:

Analysis of DCTCP: Stability, Convergence, and Fairness

"Instead, we propose subtracting α/2 from the window size for each marked ACK,
resulting in the following simple window update equation:

One result of which I was most proud recently was of demonstrating
perfect rtt fairness in a range of 20ms to 260ms with fq_codel
https://forum.mikrotik.com/viewtopic.php?t=179307 )- and I'm pretty
interested in 2-260ms, but haven't got around to it.

Now, one early result from the sce vs l4s testing I recall was severe
latecomer convergence problems - something like 40s to come into flow
balance - but I can't remember what presentation, paper, or rtt that
was from. ?

Another one has been various claims towards some level of rtt
unfairness being ok, but not the actual ratio, nor (going up to the
paper's proposal above) whether that method had been tried.

My opinion has long been that any form of marking should look more
closely at the observed RTT than any fixed rate reduction method, and
compensate the paced rate to suit. But that's presently just reduced
to an opinion, not having kept up with progress on prague, dctcp-sce,
or bbrv2. As one example of ignorance, are 2 packets still paced back
to back? DRR++ + early marking seems to lead to one packet being
consistently unmarked and the other marked.

--
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
_______________________________________________
Ecn-sane mailing list
Ecn-sane@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/ecn-sane

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.