[Ecn-sane] rtt-fairness question

Thu Apr 14 12:54:32 EDT 2022

Am I to assume, then, that routers need not pay any attention to RTT to achieve RTT-fairness?

How does a server or client (at the endpoint) adjust RTT so that it is fair?

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.

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.

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.

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.

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).

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).

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.

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.

So at the very highest level, what is RTT-fairness's objective function optimizing, and how can it work?

Can it be done without any change to routers?

On Tuesday, April 12, 2022 3:07pm, "Michael Welzl" <michawe at ifi.uio.no> said:

On Apr 12, 2022, at 8:52 PM, Sebastian Moeller <[ moeller0 at gmx.de ]( mailto:moeller0 at gmx.de )> 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 ]( 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 <[ michawe at ifi.uio.no ]( mailto:michawe at 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 at deepplum.com ]( mailto:dpreed at 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 at ifi.uio.no ]( mailto:michawe at 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 ]( 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 ]( 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 at gmail.com ]( mailto:dave.taht at gmail.com )> wrote:

I have managed to drop most of my state regarding the state of variousdctcp-like solutions. At one level it's good to have not been keepingup, washing my brain clean, as it were. For some reason or another Iwent back to the original paper last week, and have been poundingthrough 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 demonstratingperfect rtt fairness in a range of 20ms to 260ms with fq_codel[ https://forum.mikrotik.com/viewtopic.php?t=179307 ]( https://forum.mikrotik.com/viewtopic.php?t=179307 ) )- and I'm prettyinterested in 2-260ms, but haven't got around to it.Now, one early result from the sce vs l4s testing I recall was severelatecomer convergence problems - something like 40s to come into flowbalance - but I can't remember what presentation, paper, or rtt thatwas from. ?Another one has been various claims towards some level of rttunfairness being ok, but not the actual ratio, nor (going up to thepaper's proposal above) whether that method had been tried.My opinion has long been that any form of marking should look moreclosely at the observed RTT than any fixed rate reduction method, andcompensate the paced rate to suit. But that's presently just reducedto an opinion, not having kept up with progress on prague, dctcp-sce,or bbrv2. As one example of ignorance, are 2 packets still paced backto back? DRR++ + early marking seems to lead to one packet beingconsistently 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 ]( https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org )Dave Täht CEO, TekLibre, LLC_______________________________________________Ecn-sane mailing list[ Ecn-sane at lists.bufferbloat.net ]( mailto:Ecn-sane at lists.bufferbloat.net )[ https://lists.bufferbloat.net/listinfo/ecn-sane ]( https://lists.bufferbloat.net/listinfo/ecn-sane )

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/ecn-sane/attachments/20220414/e02f98fc/attachment.html>