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 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" 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 > 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