Re: [Ecn-sane] rtt-fairness question

[Michael Welzl <michawe@ifi.uio.no>]

[-- Attachment #1: Type: text/plain, Size: 6109 bytes --]



> On Apr 12, 2022, at 8:52 PM, Sebastian Moeller <moeller0@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@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 <mailto: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 <mailto: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 <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@gmail.com <mailto: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 <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 <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 <mailto: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.


[-- Attachment #2: Type: text/html, Size: 11028 bytes --]