From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 2DF373B29E for ; Tue, 12 Apr 2022 12:00:23 -0400 (EDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1neIwE-009In8-LN; Tue, 12 Apr 2022 18:00:18 +0200 Received: from 91.141.36.150.wireless.dyn.drei.com ([91.141.36.150] helo=[192.168.1.162]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1neIwC-0007JR-Lo; Tue, 12 Apr 2022 18:00:18 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_5460DB5F-0E1F-49B2-8FAE-3D2AE5EC27C1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: <1649778681.721621839@apps.rackspace.com> Date: Tue, 12 Apr 2022 18:00:15 +0200 Cc: Dave Taht , ECN-Sane Message-Id: <0026CF35-46DF-4C0C-8FEE-B5309246C1B7@ifi.uio.no> References: <4430DD9F-2556-4D38-8BE2-6609265319AF@ifi.uio.no> <1649778681.721621839@apps.rackspace.com> To: "David P. Reed" X-Mailer: Apple Mail (2.3608.120.23.2.7) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 91.141.36.150 is neither permitted nor denied by domain of ifi.uio.no) client-ip=91.141.36.150; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.162]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 0D4A19D7E83468CACE5BE85DD04E0D733B60DD47 X-UiOonly: 358FAB0A85FE66297696A2BC7D2D2361B74BEA34 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: Tue, 12 Apr 2022 16:00:23 -0000 --Apple-Mail=_5460DB5F-0E1F-49B2-8FAE-3D2AE5EC27C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = wrote: >=20 > 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.=20 > =20 > 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. > =20 > 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. > =20 > That's the opposite of an "end-to-end resource sharing protocol". > =20 > 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. > =20 > This would be the technical equivalent of an ITU central control = point. > =20 > 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). > =20 > 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. > =20 > =20 > On Friday, April 8, 2022 2:03pm, "Michael Welzl" = said: >=20 > 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 :-) ) >=20 > Cheers, > Michael >=20 > On Apr 8, 2022, at 6:33 PM, Dave Taht > 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: >=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=_5460DB5F-0E1F-49B2-8FAE-3D2AE5EC27C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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>= 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> 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/researc= h/publications/NUM-ECN_report_2019.pdf
and there=E2=80=99s also some in this paper, which first = introduced our LGC mechanism:
https://ieeexplore.i= eee.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.org

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=_5460DB5F-0E1F-49B2-8FAE-3D2AE5EC27C1--