<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><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=""><br class=""></div><div class="">Technical report (longer version):</div><div class=""><a href="https://folk.universitetetioslo.no/michawe/research/publications/NUM-ECN_report_2019.pdf" class="">https://folk.universitetetioslo.no/michawe/research/publications/NUM-ECN_report_2019.pdf</a></div><div class=""><br class=""></div><div class="">and there’s also some in this paper, which first introduced our LGC mechanism:</div><div class=""><a href="https://ieeexplore.ieee.org/document/7796757" class="">https://ieeexplore.ieee.org/document/7796757</a></div><div class=""><br class=""></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>Cheers,</div><div>Michael</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 8, 2022, at 6:33 PM, Dave Taht <<a href="mailto:dave.taht@gmail.com" class="">dave.taht@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><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 href="https://forum.mikrotik.com/viewtopic.php?t=179307" class="">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 href="https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org" class="">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="">Ecn-sane@lists.bufferbloat.net<br class="">https://lists.bufferbloat.net/listinfo/ecn-sane<br class=""></div></div></blockquote></div><br class=""></div></body></html>