From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 29A673B29D for ; Fri, 8 Apr 2022 14:03:52 -0400 (EDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ncsxZ-00BjwX-BL; Fri, 08 Apr 2022 20:03:49 +0200 Received: from [185.176.244.89] (helo=[192.168.1.12]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1ncsxX-000Eml-47; Fri, 08 Apr 2022 20:03:49 +0200 From: Michael Welzl Message-Id: <4430DD9F-2556-4D38-8BE2-6609265319AF@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_F7014259-A933-4E5C-8498-2680E2D63093" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 8 Apr 2022 20:03:46 +0200 In-Reply-To: Cc: ECN-Sane To: Dave Taht References: X-Mailer: Apple Mail (2.3608.120.23.2.7) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 185.176.244.89 is neither permitted nor denied by domain of ifi.uio.no) client-ip=185.176.244.89; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.12]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: A612FEA0BFC2105151D98F48549F7E2F0D749719 X-UiOonly: BD289276B4FE5616D04880B9DB544D46E7927359 Subject: Re: [Ecn-sane] rtt-fairness question X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 18:03:52 -0000 --Apple-Mail=_F7014259-A933-4E5C-8498-2680E2D63093 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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_r= eport_2019.pdf = and there=E2=80=99s also some in this paper, which first introduced our = LGC mechanism: https://ieeexplore.ieee.org/document/7796757 = See the technical report on page 9, section D: a simple trick can = improve DCTCP=E2=80=99s fairness (if that=E2=80=99s really the = mechanism to stay with=E2=80=A6 I=E2=80=99m getting quite happy with = the results we get with our LGC scheme :-) ) Cheers, Michael > On Apr 8, 2022, at 6:33 PM, Dave Taht wrote: >=20 > 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: >=20 > Analysis of DCTCP: Stability, Convergence, and Fairness >=20 > "Instead, we propose subtracting =CE=B1/2 from the window size for = each marked ACK, > resulting in the following simple window update equation: >=20 > 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=3D179307 )- and I'm pretty > interested in 2-260ms, but haven't got around to it. >=20 > 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. ? >=20 > 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. >=20 > 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. >=20 > --=20 > I tried to build a better future, a few times: > https://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org >=20 > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Ecn-sane mailing list > Ecn-sane@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/ecn-sane --Apple-Mail=_F7014259-A933-4E5C-8498-2680E2D63093 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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/publication= s/NUM-ECN_report_2019.pdf

and there=E2=80=99s also some in this = paper, which first introduced our LGC mechanism:
https://ieeexplore.ieee.org/document/7796757

See the technical report = on page 9, section D: a simple trick can improve DCTCP=E2=80=99s = fairness  (if that=E2=80=99s really the mechanism to stay with=E2=80=A6=   I=E2=80=99m 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 =CE=B1/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=3D179307 )- = 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=3Dhttps%3A%2F%2Fwww.icei.o= rg

Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
Ecn-sane mailing list
Ecn-sane@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/ecn-sane

= --Apple-Mail=_F7014259-A933-4E5C-8498-2680E2D63093--