From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7E3F33B29E for ; Tue, 12 Apr 2022 11:51:22 -0400 (EDT) Received: from app9.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D970E2489B; Tue, 12 Apr 2022 11:51:21 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app9.wa-webapps.iad3a (Postfix) with ESMTP id B0E1DA1166; Tue, 12 Apr 2022 11:51:21 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Tue, 12 Apr 2022 11:51:21 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Tue, 12 Apr 2022 11:51:21 -0400 (EDT) From: "David P. Reed" To: "Michael Welzl" Cc: "Dave Taht" , "ECN-Sane" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20220412115121000000_42093" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <4430DD9F-2556-4D38-8BE2-6609265319AF@ifi.uio.no> References: <4430DD9F-2556-4D38-8BE2-6609265319AF@ifi.uio.no> X-Client-IP: 209.6.168.128 Message-ID: <1649778681.721621839@apps.rackspace.com> X-Mailer: webmail/19.0.13-RC X-Classification-ID: 9ed33811-8ba1-48b8-8b66-92529a0e0caf-1-1 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 15:51:22 -0000 ------=_20220412115121000000_42093 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI strongly object to congestion control *in the network* attempting to m= easure RTT (which is an end-to-end comparative metric). Unless the current = RTT is passed in each packet a router cannot enforce fairness. Period. =0A = =0AToday, by packet drops and fair marking, information is passed to the se= nding nodes (eventually) about congestion. But the router can't know RTT to= day.=0A =0AThe result of *requiring* RTT fairness would be to put the rando= m bottleneck router (chosen because it is the slowest forwarder on a conten= ded path) become the endpoint controller.=0A =0AThat's the opposite of an "= end-to-end resource sharing protocol".=0A =0ANow, I'm not saying it is impo= ssible - what I'm saying it is asking all endpoints to register with an "In= ternet-wide" RTT real-time tracking and control service.=0A =0AThis would b= e the technical equivalent of an ITU central control point.=0A =0ASo, eithe= r someone will invent something I cannot imagine (a distributed, rapid-conv= ergence algortithm that rellects to *every potential user* of a shared rout= er along the current path the RTT's of ALL other users (and potential users= ).=0A =0AIMHO, the wish for RTT fairness is like saying that the entire sol= ar system's gravitational pull should be equalized so that all planets and = asteroids have fair access to 1G gravity.=0A =0A =0AOn Friday, April 8, 202= 2 2:03pm, "Michael Welzl" said:=0A=0A=0AHi,=0AFWIW, we= have done some analysis of fairness and convergence of DCTCP in:=0APeyman = Teymoori, David Hayes, Michael Welzl, Stein Gjessing: "Estimating an Additi= ve Path Cost with Explicit Congestion Notification", IEEE Transactions on C= ontrol of Network Systems, 8(2), pp. 859-871, June 2021. DOI 10.1109/TCNS.2= 021.3053179=0ATechnical report (longer version):=0A[ https://folk.universit= etetioslo.no/michawe/research/publications/NUM-ECN_report_2019.pdf ]( https= ://folk.universitetetioslo.no/michawe/research/publications/NUM-ECN_report_= 2019.pdf )=0Aand there=E2=80=99s also some in this paper, which first intro= duced our LGC mechanism:=0A[ https://ieeexplore.ieee.org/document/7796757 ]= ( https://ieeexplore.ieee.org/document/7796757 )=0ASee 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=99= m getting quite happy with the results we get with our LGC scheme :-) )= =0A=0ACheers,=0AMichael=0A=0AOn Apr 8, 2022, at 6:33 PM, Dave Taht <[ dave.= taht@gmail.com ]( mailto:dave.taht@gmail.com )> wrote:=0A=0AI have managed = to drop most of my state regarding the state of variousdctcp-like solutions= . At one level it's good to have not been keepingup, washing my brain clean= , as it were. For some reason or another Iwent back to the original paper l= ast week, and have been poundingthrough this one again:Analysis of DCTCP: S= tability, Convergence, and Fairness"Instead, we propose subtracting =CE=B1/= 2 from the window size for each marked ACK,resulting in the following simpl= e window update equation:One result of which I was most proud recently was = of demonstratingperfect rtt fairness in a range of 20ms to 260ms with fq_co= del[ https://forum.mikrotik.com/viewtopic.php?t=3D179307 ]( https://forum.m= ikrotik.com/viewtopic.php?t=3D179307 ) )- and I'm prettyinterested in 2-260= ms, but haven't got around to it.Now, one early result from the sce vs l4s = testing I recall was severelatecomer convergence problems - something like = 40s to come into flowbalance - but I can't remember what presentation, pape= r, or rtt thatwas from. ?Another one has been various claims towards some l= evel of rttunfairness being ok, but not the actual ratio, nor (going up to = thepaper's proposal above) whether that method had been tried.My opinion ha= s long been that any form of marking should look moreclosely at the observe= d RTT than any fixed rate reduction method, andcompensate the paced rate to= suit. But that's presently just reducedto an opinion, not having kept up w= ith progress on prague, dctcp-sce,or bbrv2. As one example of ignorance, ar= e 2 packets still paced backto back? DRR++ + early marking seems to lead to= one packet beingconsistently unmarked and the other marked.-- I tried to b= uild a better future, a few times:[ https://wayforward.archive.org/?site=3D= https%3A%2F%2Fwww.icei.org ]( https://wayforward.archive.org/?site=3Dhttps%= 3A%2F%2Fwww.icei.org )Dave T=C3=A4ht CEO, TekLibre, LLC____________________= ___________________________Ecn-sane mailing listEcn-sane@lists.bufferbloat.= nethttps://lists.bufferbloat.net/listinfo/ecn-sane ------=_20220412115121000000_42093 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I strongly object to c= ongestion control *in the network* attempting to measure RTT (which is an e= nd-to-end comparative metric). Unless the current RTT is passed in each pac= ket a router cannot enforce fairness. Period. 

=0A

 

=0A

Today, by packet drops and fair marki= ng, information is passed to the sending nodes (eventually) about congestio= n. But the router can't know RTT today.

=0A

 =0A

The result of *requiring* RTT fairness would be t= o put the random bottleneck router (chosen because it is the slowest forwar= der on a contended path) become the endpoint controller.

=0A

 

=0A

That's the opposite of an "end-t= o-end resource sharing protocol".

=0A

 

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 10pt; overflow= -wrap: break-word;">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-tim= e tracking and control service.

=0A

 

=0A

This would be the technical equivalent of an ITU central = control point.

=0A

 

=0A

So, either someone will invent something I cannot imagine (a distributed, = rapid-convergence algortithm that rellects to *every potential user* of a s= hared router along the current path the RTT's of ALL other users (and poten= tial users).

=0A

 

=0A

I= MHO, 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.

=0A

 

=0A

 

=0A

On Friday, April 8, 202= 2 2:03pm, "Michael Welzl" <michawe@ifi.uio.no> said:

= =0A
Hi,=0A
FWIW, we have don= e some analysis of fairness and convergence of DCTCP in:
=0A
Peyman Teymoori, David Hayes, Michael Welzl, Stein Gjessing: "Estimat= ing an Additive Path Cost with Explicit Congestion Notification", IEEE Tran= sactions on Control of Network Systems, 8(2), pp. 859-871, June 2021. = DOI 10.1109/TCNS.2021.3053179
=0A
Technical report (lon= ger version):
=0A
= https://folk.universitetetioslo.no/michawe/research/publications/NUM-ECN_re= port_2019.pdf
=0A
and there=E2=80=99s also some in = this paper, which first introduced our LGC mechanism:
=0A
http= s://ieeexplore.ieee.org/document/7796757
=0A
See th= e 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 w= ith=E2=80=A6   I=E2=80=99m getting quite happy with the results we get= with our LGC scheme   :-)   )
=0A

=0A
Cheers,
=0A
Michael
=0A

= =0A
=0A
On Apr 8, 2022, at 6:33 PM, Da= ve Taht <dave.taht@gma= il.com> wrote:
=0A
=0A
I have man= aged 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 ano= ther 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 th= e window size for each marked ACK,
resulting in the followi= ng simple window update equation:

One resu= lt 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 pret= ty
interested in 2-260ms, but haven't got around to it.

Now, one early result from the sce vs l4s tes= ting I recall was severe
latecomer convergence problems - s= omething like 40s to come into flow
balance - but I can't r= emember 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 ha= s long been that any form of marking should look more
close= ly at the observed RTT than any fixed rate reduction method, and
compensate the paced rate to suit. But that's presently just reduce= d
to an opinion, not having kept up with progress on prague= , dctcp-sce,
or bbrv2. As one example of ignorance, are 2 p= ackets still paced back
to back? DRR++ + early marking seem= s to lead to one packet being
consistently unmarked and the= other marked.

--
I tried= to build a better future, a few times:
http= s://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org

Dave T=C3=A4ht CEO, TekLibre, LLC
= _______________________________________________
Ecn-sane ma= iling list
Ecn-sane@lists.bufferbloat.net
h= ttps://lists.bufferbloat.net/listinfo/ecn-sane
=0A
=0A=0A
=0A
=0A
 ------=_20220412115121000000_42093--