From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 3F6DF3B29E for ; Tue, 12 Apr 2022 14:52:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1649789567; bh=wjNkLyEnZHqC8jpzlcAK+eTF4GOjZBN/ELkDKVoJxJk=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References; b=lSD5tLdwWswD2Ttz5OrGWLnP3cY6WP4bpspJA2GldDyXasXH/dPftWohZmDWGeT3Q h9k8laVbLElMAyTx9fHfPRSRfebxXbLRLMDq4hAh1+3WS0pXoswVd9ZqVcUf7jDQXf evOoN2EchnX2K+rLhJj2hhnmGsFs8rnHyAHoeWj8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [127.0.0.1] ([80.187.121.249]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mt75H-1nxere08i1-00tUSH; Tue, 12 Apr 2022 20:52:47 +0200 Date: Tue, 12 Apr 2022 20:52:30 +0200 From: Sebastian Moeller To: ecn-sane@lists.bufferbloat.net, Michael Welzl , "David P. Reed" CC: ECN-Sane User-Agent: K-9 Mail for Android In-Reply-To: <0026CF35-46DF-4C0C-8FEE-B5309246C1B7@ifi.uio.no> References: <4430DD9F-2556-4D38-8BE2-6609265319AF@ifi.uio.no> <1649778681.721621839@apps.rackspace.com> <0026CF35-46DF-4C0C-8FEE-B5309246C1B7@ifi.uio.no> Message-ID: <08F92DA0-1D59-4E58-A289-3D35103CF78B@gmx.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----I8RYUQBCU9AWGJK720O8GO8SS0IJ2P Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:lEqg/HyiPZIXnyjC8B5kRsm6eONBjSFTdTIW0BscsO/rJewTpYU ZFuWPk/57XNkTQdmetpYc3EqRBSnj3LLqVWcsqL9gjKUP9xj/B2Gl2H3N2PJuvGur9ICEHX ++6Syuz4XpjCOQeVGdRnazEg3oN9XmkAoxjYVE4DcerUrJvYVu8ZVT1eTOZN6iUaKkCfJ/b MA8/itezxJbL+gcLEpZ3Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:01iQ9h33n+0=:DLXi6W/AdrOid4818cuNFi k0LUm038toHB5g5Zr6POkhWafaBCCEa32fj18Kf4antEdzRW6lutSGJy+GiCZPMdPx4JKqtPC fYGDi5hxLytOTJn3EzFF4/ofdN4JsL315VJIKTZmOeKHnqRzCS/jVQ+sa9x+rzi8dZb0reV6X VAIkkFczr8p73ChXFV294ET5418yqS4iN3itPuQhD+0QtV3uuQ879H5Efl8lGUQlN67O2MYTt p95R4e+WijOFOj0OHTdFS80JoIADkWLAIW73ZfxMvhu8GsL3A3kVBry1PyUK/3St0ghHjJG/l tRqjo+9zl9MvUSaHxUwIkV9M24tggGcrDHcLi922X5YomhC0u7aYi5Ul0LAqcfFJw2BSemu0L qozdHNaFv/XjR58MOKVNgwAjQnL4EB1hY2QpuvNLHBOoZoybWoOggTXbLjOXmIn+fxSS4XtMq uDJR8FncQzTQ2kMEEQF0U50wOIPNUT3N5P6bzfRIfM4QLWVrifdeGCx9X2tJAhWT+JDJHszuR eIOMVWkfY2EMexZIQ5DGR82zICol1THnmruiWYZsdmLjdX7Nhzf2bXaTStaaT7FZQRHT16yR8 /KEb8OgVAv25uY4uQifLS7+rQhdKmSKvLqcKt/siXRYE50UOGAKVXDmD/vy3GTv7R5oER5wxA zZO8hYcGRQFue3dBmv5bWCZIF2WinugKdmi4tNCmAQj8fW5ncx2QF+eL3xrq7SMKg3YXiUGIE 8enw68NCJyrxSyMDfm/jjYmWql8P94Wp2akzEL3Vgn2iXIg61WQOIPZzHHBdfPYmhyWCbKWqv vBNqoAGr807u1NSuO8ggIXuyvaXigZERKEi42BmaxU1/pSskkHwN371V6YBHB+FO5iQLQ/VwU XfpV2r6N0zRUOr6WvffsYJlY4wiiXzn+ZoAxZS4jLuFDGrIIJvZ8IwIf5U8xUMKiXNCpwgmLb G44esWZVQtwKpZq2ZBF61NmxEF9LlZjXofVKaE/nEicUoWYykTw4oUryKR8hJJxJdPHgcCWY5 efYorjO5x1AF90sE9J0hvM0wSk2lFkzwSrgXzXKJiL9ynFxKOWs586GyWyDX2kgjfpoYOONuD B/zxko/cJEGuoc= 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 18:52:50 -0000 ------I8RYUQBCU9AWGJK720O8GO8SS0IJ2P Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Question: is QUIC actually using the spin bit as an essential part of the p= rotocol? Otherwise endpoints might just game this if faking their RTT at a = router yields an advantage=2E=2E=2E This is why pping's use of tcp timestamps is elegant, little incentive for= the endpoints to fudge=2E=2E=2E=2E Regards Sebastian On 12 April 2022 18:00:15 CEST, Michael Welzl wro= te: >Hi, > >Who or what are you objecting against? At least nothing that I describe= d does what you suggest=2E > >BTW, just as a side point, for QUIC, routers can know the RTT today - usi= ng the spin bit, which was designed for that specific purpose=2E > >Cheers, >Michael > > >> On Apr 12, 2022, at 5:51 PM, David P=2E Reed wr= ote: >>=20 >> I strongly object to congestion control *in the network* attempting to = measure RTT (which is an end-to-end comparative metric)=2E Unless the curre= nt RTT is passed in each packet a router cannot enforce fairness=2E Period= =2E=20 >> =20 >> Today, by packet drops and fair marking, information is passed to the s= ending nodes (eventually) about congestion=2E But the router can't know RTT= today=2E >> =20 >> The result of *requiring* RTT fairness would be to put the random bottl= eneck router (chosen because it is the slowest forwarder on a contended pat= h) become the endpoint controller=2E >> =20 >> That's the opposite of an "end-to-end resource sharing protocol"=2E >> =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 c= ontrol service=2E >> =20 >> This would be the technical equivalent of an ITU central control point= =2E >> =20 >> So, either someone will invent something I cannot imagine (a distribute= d, 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 po= tential users)=2E >> =20 >> IMHO, the wish for RTT fairness is like saying that the entire solar sy= stem's gravitational pull should be equalized so that all planets and aster= oids have fair access to 1G gravity=2E >> =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 i= n: >> Peyman Teymoori, David Hayes, Michael Welzl, Stein Gjessing: "Estimatin= g an Additive Path Cost with Explicit Congestion Notification", IEEE Transa= ctions on Control of Network Systems, 8(2), pp=2E 859-871, June 2021=2E DOI= 10=2E1109/TCNS=2E2021=2E3053179 >> Technical report (longer version): >> https://folk=2Euniversitetetioslo=2Eno/michawe/research/publications/NU= M-ECN_report_2019=2Epdf >> and there=E2=80=99s also some in this paper, which first introduced our= LGC mechanism: >> https://ieeexplore=2Eieee=2Eorg/document/7796757 >> See the technical report on page 9, section D: a simple trick can impro= ve DCTCP=E2=80=99s fairness (if that=E2=80=99s really the mechanism to sta= y with=E2=80=A6 I=E2=80=99m getting quite happy with the results we get w= ith 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=2E At one level it's good to have not been keeping >> up, washing my brain clean, as it were=2E 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=2Emikrotik=2Ecom/viewtopic=2Ephp?t=3D179307 )- and I'm pretty >> interested in 2-260ms, but haven't got around to it=2E >>=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=2E ? >>=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=2E >>=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=2E But that's presently just reduced >> to an opinion, not having kept up with progress on prague, dctcp-sce, >> or bbrv2=2E 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=2E >>=20 >> --=20 >> I tried to build a better future, a few times: >> https://wayforward=2Earchive=2Eorg/?site=3Dhttps%3A%2F%2Fwww=2Eicei=2Eo= rg >>=20 >> Dave T=C3=A4ht CEO, TekLibre, LLC >> _______________________________________________ >> Ecn-sane mailing list >> Ecn-sane@lists=2Ebufferbloat=2Enet >> https://lists=2Ebufferbloat=2Enet/listinfo/ecn-sane > --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------I8RYUQBCU9AWGJK720O8GO8SS0IJ2P Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Question: is QUIC actually= using the spin bit as an essential part of the protocol? Otherwise endpoin= ts might just game this if faking their RTT at a router yields an advantage= =2E=2E=2E

This is why pping's use of tcp timestamps is elegant, litt= le incentive for the endpoints to fudge=2E=2E=2E=2E

Regards
= Sebastian


On 12 April 2022 18:00:1= 5 CEST, Michael Welzl <michawe@ifi=2Euio=2Eno> wrote:
Hi,

Who or what are yo= u objecting against?   At least nothing that I described does what you= suggest=2E

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=2E

Cheers,
Mic= hael


On Apr 12, 2022, at 5:51 PM, David P= =2E Reed <dpreed@dee= pplum=2Ecom> wrote:

I strongly object to congestion control *in the netw= ork* attempting to measure RTT (which is an end-to-end comparative metric)= =2E Unless the current RTT is passed in each packet a router cannot enforce= fairness=2E Period=2E 

 

Today, by packet drops and fair = marking, information is passed to the sending nodes (eventually) about cong= estion=2E But the router can't know RTT today=2E

 

The result o= f *requiring* RTT fairness would be to put the random bottleneck router (ch= osen because it is the slowest forwarder on a contended path) become the en= dpoint controller=2E

 

That's the opposite of an "end-to-end re= source sharing protocol"=2E

 

=
Now, I'm not saying it is impossi= ble - what I'm saying it is asking all endpoints to register with an "Inter= net-wide" RTT real-time tracking and control service=2E

 

This = would be the technical equivalent of an ITU central control point=2E
<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 10pt; overflow= -wrap: break-word;" class=3D""> 

So, either someone will invent something I cannot imagine (a distri= buted, rapid-convergence algortithm that rellects to *every potential user*= of a shared router along the current path the RTT's of ALL other users (an= d potential users)=2E

 

IMHO, the wish for RTT fairness is like= saying that the entire solar system's gravitational pull should be equaliz= ed so that all planets and asteroids have fair access to 1G gravity=2E

 

=  

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

<= /div>
Hi,
FWIW, we have done some analysis of fairness and convergen= ce of DCTCP in:
Peyman Teymoori, David Hayes, Michael Welzl, Stein Gjessin= g: "Estimating an Additive Path Cost with Explicit Congestion Notification"= , IEEE Transactions on Control of Network Systems, 8(2), pp=2E 859-871,&nbs= p;June 2021=2E DOI 10=2E1109/TCNS=2E2021=2E3053179
Technical report (longer version):
https://folk=2E= universitetetioslo=2Eno/michawe/research/publications/NUM-ECN_report_2019= =2Epdf
and there=E2=80=99s also some in this paper, which first i= ntroduced our LGC mechanism:
https://ieeexplore=2Eieee=2Eorg/document/7796757
See the technical report on page 9, section D: a simple tr= ick can improve DCTCP=E2=80=99s fairness  (if that=E2=80=99s really th= e mechanism to stay with=E2=80=A6   I=E2=80=99m getting quite happy wi= th the results we get with our LGC scheme   :-)   )

Cheers,
Michael

On Apr 8, 2022, at 6:33 PM, Dave Taht <dave=2Etaht@gmail=2Ecom> wrote= :
I have managed to drop most of my state regarding the stat= e of various
dctcp-like solutions=2E At one level it's good t= o have not been keeping
up, washing my brain clean, as it wer= e=2E For some reason or another I
went back to the original p= aper last week, and have been pounding
through this one again= :

Analysis of DCTCP: Stability, Convergence, a= nd 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=2Emikrotik=2Ecom/viewtopic=2Ephp?t=3D179307 )- and I'm pretty
interested in 2-260ms, but haven't got a= round to it=2E

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 f= rom=2E ?

Another one has been various claims t= owards some level of rtt
unfairness being ok, but not the act= ual ratio, nor (going up to the
paper's proposal above) wheth= er that method had been tried=2E

My opinion ha= s 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=2E But that's presently just reducedto an opinion, not having kept up with progress on prague, dctc= p-sce,
or bbrv2=2E As one example of ignorance, are 2 packets= still paced back
to back? DRR++ + early marking seems to lea= d to one packet being
consistently unmarked and the other mar= ked=2E

--
I tried to build a be= tter future, a few times:
https://wayfo= rward=2Earchive=2Eorg/?site=3Dhttps%3A%2F%2Fwww=2Eicei=2Eorg

Dave T=C3=A4ht CEO, TekLibre, LLC
______= _________________________________________
Ecn-sane mailing li= st
Ecn-sane@lists=2Ebufferbloat=2Enet
https://lists= =2Ebufferbloat=2Enet/listinfo/ecn-sane

--=
Sent from my Android device with K-9 Mail=2E Please excuse my brevity= =2E
------I8RYUQBCU9AWGJK720O8GO8SS0IJ2P--