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