> On Apr 12, 2022, at 8:52 PM, Sebastian Moeller wrote: > > Question: is QUIC actually using the spin bit as an essential part of the protocol? The spec says it’s optional: https://www.rfc-editor.org/rfc/rfc9000.html#name-latency-spin-bit > Otherwise endpoints might just game this if faking their RTT at a router yields an advantage... This was certainly discussed in the QUIC WG. Probably perceived as an unclear incentive, but I didn’t really follow this. Cheers, Michael > 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 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 > 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 > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.