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 895E63B29E for ; Tue, 12 Apr 2022 15:07:23 -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 1neLrD-0009gi-RZ; Tue, 12 Apr 2022 21:07:19 +0200 Received: from 91.141.36.150.wireless.dyn.drei.com ([91.141.36.150] helo=[192.168.1.162]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1neLrB-00073a-9R; Tue, 12 Apr 2022 21:07:19 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AEADDFFD-50D8-4E7A-B079-8781CD6CEC0F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 12 Apr 2022 21:07:11 +0200 In-Reply-To: <08F92DA0-1D59-4E58-A289-3D35103CF78B@gmx.de> Cc: ecn-sane@lists.bufferbloat.net, "David P. Reed" To: Sebastian Moeller References: <4430DD9F-2556-4D38-8BE2-6609265319AF@ifi.uio.no> <1649778681.721621839@apps.rackspace.com> <0026CF35-46DF-4C0C-8FEE-B5309246C1B7@ifi.uio.no> <08F92DA0-1D59-4E58-A289-3D35103CF78B@gmx.de> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.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: B96B7DA5C09796EC457D7794EAE04F985799E714 X-UiOonly: 4271198B477AD0ECDE003B51CA1D0E403DAEC0DB 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 19:07:23 -0000 --Apple-Mail=_AEADDFFD-50D8-4E7A-B079-8781CD6CEC0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 12, 2022, at 8:52 PM, Sebastian Moeller = wrote: >=20 > Question: is QUIC actually using the spin bit as an essential part of = the protocol? The spec says it=E2=80=99s optional: = https://www.rfc-editor.org/rfc/rfc9000.html#name-latency-spin-bit = > Otherwise endpoints might just game this if faking their RTT at a = router yields an advantage... This was certainly discussed in the QUIC WG. Probably perceived as an = unclear incentive, but I didn=E2=80=99t really follow this. Cheers, Michael > This is why pping's use of tcp timestamps is elegant, little incentive = for the endpoints to fudge.... >=20 > Regards > Sebastian >=20 >=20 > On 12 April 2022 18:00:15 CEST, Michael Welzl = wrote: > Hi, >=20 > Who or what are you objecting against? At least nothing that I = described does what you suggest. >=20 > 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. >=20 > Cheers, > Michael >=20 >=20 >> 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 >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. --Apple-Mail=_AEADDFFD-50D8-4E7A-B079-8781CD6CEC0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 12, 2022, at 8:52 PM, Sebastian Moeller <moeller0@gmx.de> = wrote:

Question: is QUIC = actually using the spin bit as an essential part of the = protocol?

The spec = says it=E2=80=99s optional:  https://www.rfc-editor.org/rfc/rfc9000.html#name-latency-spin-b= it


Otherwise endpoints = might just game this if faking their RTT at a router yields an = advantage...

This was certainly discussed in the QUIC WG. = Probably perceived as an unclear incentive, but I didn=E2=80=99t really = follow this.

Cheers,
Michael



This is why pping's use of tcp timestamps is elegant, little = incentive for the endpoints to fudge....

Regards
Sebastian


On 12 April 2022 = 18:00:15 CEST, Michael Welzl <michawe@ifi.uio.no> wrote:
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

--
Sent from = my Android device with K-9 Mail. Please excuse my = brevity.

= --Apple-Mail=_AEADDFFD-50D8-4E7A-B079-8781CD6CEC0F--