<font face="arial" size="2"><p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Am I to assume, then, that routers need not pay any attention to RTT to achieve RTT-fairness?</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">How does a server or client (at the endpoint) adjust RTT so that it is fair?</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Now RTT, technically, is just the sum of the instantaneous queue lengths in bytes along the path and the reverse path, plus a fixed wire-level delay. And routers along any path do not have correlated queue sizes.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">It seems to me that RTT adjustment requires collective real-time cooperation among all-or-most future users of that path.  The path is partially shared by many servers and many users, none of whom directly speak to each other.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">And routers have very limited memory compared to their throughput-RTdelay product. So calculating the RTT using spin bits and UIDs for packets seems a bit much to expect all routers to do.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">So, what process measures the cross-interactions among all the users of all the paths, and what control-loop (presumably stable and TCP-compatible) actually converges to RTT fairness IRL.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Today, the basis of congestion control in the Internet is that each router is a controller of all endpoint flows that share a link, and each router is free to do whatever it takes to reduce its queue length to near zero as an average on all timescales larger than about 1/10 of a second (a magic number that is directly derived from measured human brain time resolution).</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">So, for any two machines separated by less than 1/10 of a light-second in distance, the total queueing delay has to stabilize in about 1/10 of a second. (I'm using a light-second in a fiber medium, not free-space, as the speed of light in fiber is a lot slower than the speed of light on microwaves, as Wall Street has recently started recoginizing and investing in).</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">I don't see how RTT-fairness can be achieved by some set of bits in the IP header. You can't shorten RTT below about 2/10 of a second in that desired system state. You can only "lengthen" RTT by delaying packets in source or endpoint buffers, because it's unreasonable to manage all the routers.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">And the endpoints that share a path can't talk to each other and reach a decision in on the order of 2/10 of a second.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">So at the very highest level, what is RTT-fairness's objective function optimizing, and how can it work?</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Can it be done without any change to routers?</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;">On Tuesday, April 12, 2022 3:07pm, "Michael Welzl" <michawe@ifi.uio.no> said:<br /><br /></p>
<div id="SafeStyles1649953980"><br class="" />
<div><br class="" />
<blockquote class="">
<div class="">On Apr 12, 2022, at 8:52 PM, Sebastian Moeller <<a class="" href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> wrote:</div>
<div class="">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Question: is QUIC actually using the spin bit as an essential part of the protocol?</div>
</div>
</blockquote>
The spec says it’s optional:  <a class="" href="https://www.rfc-editor.org/rfc/rfc9000.html#name-latency-spin-bit">https://www.rfc-editor.org/rfc/rfc9000.html#name-latency-spin-bit</a></div>
<div>
<blockquote class="">
<div class="">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Otherwise endpoints might just game this if faking their RTT at a router yields an advantage...</div>
</div>
</blockquote>
<div>This was certainly discussed in the QUIC WG. Probably perceived as an unclear incentive, but I didn’t really follow this.</div>
Cheers,</div>
<div>Michael</div>
<div><br class="" />
<blockquote class="">
<div class="">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">This is why pping's use of tcp timestamps is elegant, little incentive for the endpoints to fudge....<br class="" /><br class="" />Regards<br class="" /> Sebastian<br class="" /><br class="" /><br class="" />
<div class="gmail_quote">On 12 April 2022 18:00:15 CEST, Michael Welzl <<a class="" href="mailto:michawe@ifi.uio.no">michawe@ifi.uio.no</a>> wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;">Hi,
<div class="">Who or what are you objecting against?   At least nothing that I described does what you suggest.</div>
<div class="">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.</div>
<div class="">Cheers,</div>
<div class="">Michael</div>
<div class=""><br class="" />
<div class=""><br class="" />
<blockquote class="">
<div class="">On Apr 12, 2022, at 5:51 PM, David P. Reed <<a class="" href="mailto:dpreed@deepplum.com">dpreed@deepplum.com</a>> wrote:</div>
<div class="">
<div class="" style="margin: 0px; padding: 0px; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">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. </div>
<p class="" style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<div class="" style="margin: 0px; padding: 0px; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">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.</div>
<p class="" style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<div class="" style="margin: 0px; padding: 0px; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">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.</div>
<p class="" style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<div class="" style="margin: 0px; padding: 0px; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">That's the opposite of an "end-to-end resource sharing protocol".</div>
<p class="" style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<div class="" style="margin: 0px; padding: 0px; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">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.</div>
<p class="" style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<div class="" style="margin: 0px; padding: 0px; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">This would be the technical equivalent of an ITU central control point.</div>
<p class="" style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<div class="" style="margin: 0px; padding: 0px; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">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).</div>
<p class="" style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<div class="" style="margin: 0px; padding: 0px; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">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.</div>
<p class="" style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p class="" style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<div class="" style="margin: 0px; padding: 0px; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">On Friday, April 8, 2022 2:03pm, "Michael Welzl" <<a class="" href="mailto:michawe@ifi.uio.no">michawe@ifi.uio.no</a>> said:<br class="" /><br class="" /></div>
<div id="SafeStyles1649778161" class="">Hi,
<div class="">FWIW, we have done some analysis of fairness and convergence of DCTCP in:</div>
<div class="">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</div>
<div class="">Technical report (longer version):</div>
<div class=""><a class="" href="https://folk.universitetetioslo.no/michawe/research/publications/NUM-ECN_report_2019.pdf">https://folk.universitetetioslo.no/michawe/research/publications/NUM-ECN_report_2019.pdf</a></div>
<div class="">and there’s also some in this paper, which first introduced our LGC mechanism:</div>
<div class=""><a class="" href="https://ieeexplore.ieee.org/document/7796757">https://ieeexplore.ieee.org/document/7796757</a></div>
<div class="">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   :-)   )</div>
<div class=""><br class="" />
<div class="">Cheers,</div>
<div class="">Michael</div>
<div class=""><br class="" />
<blockquote class="">
<div class="">On Apr 8, 2022, at 6:33 PM, Dave Taht <<a class="" href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:</div>
<div class="">
<div class="">I have managed to drop most of my state regarding the state of various<br class="" />dctcp-like solutions. At one level it's good to have not been keeping<br class="" />up, washing my brain clean, as it were. For some reason or another I<br class="" />went back to the original paper last week, and have been pounding<br class="" />through this one again:<br class="" /><br class="" />Analysis of DCTCP: Stability, Convergence, and Fairness<br class="" /><br class="" />"Instead, we propose subtracting α/2 from the window size for each marked ACK,<br class="" />resulting in the following simple window update equation:<br class="" /><br class="" />One result of which I was most proud recently was of demonstrating<br class="" />perfect rtt fairness in a range of 20ms to 260ms with fq_codel<br class="" /><a class="" href="https://forum.mikrotik.com/viewtopic.php?t=179307">https://forum.mikrotik.com/viewtopic.php?t=179307</a> )- and I'm pretty<br class="" />interested in 2-260ms, but haven't got around to it.<br class="" /><br class="" />Now, one early result from the sce vs l4s testing I recall was severe<br class="" />latecomer convergence problems - something like 40s to come into flow<br class="" />balance - but I can't remember what presentation, paper, or rtt that<br class="" />was from. ?<br class="" /><br class="" />Another one has been various claims towards some level of rtt<br class="" />unfairness being ok, but not the actual ratio, nor (going up to the<br class="" />paper's proposal above) whether that method had been tried.<br class="" /><br class="" />My opinion has long been that any form of marking should look more<br class="" />closely at the observed RTT than any fixed rate reduction method, and<br class="" />compensate the paced rate to suit. But that's presently just reduced<br class="" />to an opinion, not having kept up with progress on prague, dctcp-sce,<br class="" />or bbrv2. As one example of ignorance, are 2 packets still paced back<br class="" />to back? DRR++ + early marking seems to lead to one packet being<br class="" />consistently unmarked and the other marked.<br class="" /><br class="" />-- <br class="" />I tried to build a better future, a few times:<br class="" /><a class="" href="https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org">https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org</a><br class="" /><br class="" />Dave Täht CEO, TekLibre, LLC<br class="" />_______________________________________________<br class="" />Ecn-sane mailing list<br class="" /><a class="" href="mailto:Ecn-sane@lists.bufferbloat.net">Ecn-sane@lists.bufferbloat.net</a><br class="" /><a class="" href="https://lists.bufferbloat.net/listinfo/ecn-sane">https://lists.bufferbloat.net/listinfo/ecn-sane</a></div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<div class="" style="white-space: pre-wrap;">
<div class="k9mail-signature">-- <br class="" />Sent from my Android device with K-9 Mail. Please excuse my brevity.</div>
</div>
</div>
</div>
</blockquote>
</div>
</div></font>