From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com [173.203.187.89]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 82FD93B2A4 for ; Tue, 19 Apr 2022 16:40:10 -0400 (EDT) Received: from app35.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A444422FE8; Tue, 19 Apr 2022 16:40:09 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app35.wa-webapps.iad3a (Postfix) with ESMTP id 8E0EBA0082; Tue, 19 Apr 2022 16:40:09 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Tue, 19 Apr 2022 16:40:09 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Tue, 19 Apr 2022 16:40:09 -0400 (EDT) From: "David P. Reed" To: "Sebastian Moeller" Cc: "Michael Welzl" , ecn-sane@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20220419164009000000_65381" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: 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> <1649955272.49298319@apps.rackspace.com> X-Client-IP: 209.6.168.128 Message-ID: <1650400809.579413230@apps.rackspace.com> X-Mailer: webmail/19.0.13-RC X-Classification-ID: 65854920-7244-4f87-8acf-7a196b46a4b9-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, 19 Apr 2022 20:40:10 -0000 ------=_20220419164009000000_65381 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ASebastian - all your thoughts here seem reasonable.=0A =0AI would point = out only two things:=0A =0A1) 100 ms. is a magic number for human perceptio= n. It's basically the order of magnitude of humans' ability to respond to u= npredictable events outside the human. That's why it is magic. Now humans c= an actually perceive intervals much, much shorter (depending on how we pay = attention), but usually it is by comparing two events' time ordering. We ca= n even synchronize to external, predictable events with finer resolution (a= s in Jazz improv or just good chamber music playing). A century of careful= scientific research supports this, niot just one experiment. Which is why = one should take it seriously as a useful target. (the fact that one can ach= ieve it across the planet with digital signalling networks makes it a desir= able goal for anything interactive between a human and any entity, be it co= mputer or human). If one can do better, of course, that's great. I like tha= t from my home computer I can get lots of places in under 8 msec (15 msec R= TT).=0A =0A2) given that a particular heavily utilized link might be shared= for paths where the light-speed-in-fiber round trip for active flows varie= s by an order of magnitude, why does one try to make fair RTT (as opposed t= o all other possible metrics on each flow) among flows. It doesn't make any= sense to me why. Going back to human interaction times, it makes sense to = me that you might want to be unfair so that most flows get faster than 200 = ms. RTT, for example, penalizing those who are really close to each other a= nyway.=0AIf the RTT is already low because congestion has been controlled, = you can't make it lower. Basically, the ideal queue state is < 1 packet in = the bottleneck outbound queues, no matter what the RTT through that queue i= s.=0A =0A =0A =0AOn Thursday, April 14, 2022 5:25pm, "Sebastian Moeller" said:=0A=0A=0A=0A> Just indulge me here for a few crazy ide= as ;)=0A> =0A> > On Apr 14, 2022, at 18:54, David P. Reed wrote:=0A> >=0A> > Am I to assume, then, that routers need not pay any= attention to RTT to=0A> achieve RTT-fairness?=0A> =0A> Part of RTT-bias se= ems caused by the simple fact that tight control loops work=0A> better than= sloppy ones ;)=0A> =0A> There seem to be three ways to try to remedy that = to some degree:=0A> 1) the daft one:=0A> define a reference RTT (larger tha= n typically encountered) and have all TCPs=0A> respond as if encountering t= hat delay -> until the path RTT exceeds that=0A> reference TCP things shoul= d be reasonably fair=0A> =0A> 2) the flows communicate with the bottleneck = honestly:=0A> if flows would communicate their RTT to the bottleneck the bo= ttleneck could=0A> partition its resources such that signaling (mark/drop) = and puffer size is=0A> bespoke per-flow. In theory that can work, but relie= s on either the RTT=0A> information being non-gameably linked to the protoc= ol's operation* or everybody=0A> being fully veridical and honest=0A> *) th= ink a protocol that will only work if the best estimate of the RTT is=0A> c= ommunicated between the two sides continuously=0A> =0A> 3) the router being= verbose:=0A> If routers communicate the fill-state of their queue (global = or per-flow does not=0A> matter all that much) flows in theory can do a bet= ter job at not putting way too=0A> much data in flight remedying the cost o= f drops/marks that affects high RTT flows=0A> more than the shorter ones. (= The router has little incentive to lie here, if it=0A> wanted to punish a f= low it would be easier to simply drop its packets and be done=0A> with).=0A= > =0A> =0A> IMHO 3, while theoretically the least effective of the three is= the only one that=0A> has a reasonable chance of being employed... or rath= er is already deployed in the=0A> form of ECN (with mild effects).=0A> =0A>= > How does a server or client (at the endpoint) adjust RTT so that it is f= air?=0A> =0A> See 1) above, but who in their right mind would actually impl= ement something like=0A> that (TCP Prague did that, but IMHO never in earne= st but just to "address" the=0A> L4S bullet point RTT-bias reduction).=0A> = =0A> > Now RTT, technically, is just the sum of the instantaneous queue len= gths in=0A> bytes along the path and the reverse path, plus a fixed wire-le= vel delay. And=0A> routers along any path do not have correlated queue size= s.=0A> >=0A> > It seems to me that RTT adjustment requires collective real-= time cooperation=0A> among all-or-most future users of that path. The path = is partially shared by many=0A> servers and many users, none of whom direct= ly speak to each other.=0A> >=0A> > And routers have very limited memory co= mpared to their throughput-RTdelay=0A> product. So calculating the RTT usin= g spin bits and UIDs for packets seems a bit=0A> much to expect all routers= to do.=0A> =0A> If posed like this, I guess the better question is, what c= an/should routers be=0A> expected to do here: either equitably share their = queues or share queue=0A> inequitably such that throughput is equitable. Fr= om a pure router point of the=0A> view the first seems "fairest", but as fq= _codel and cake show, within reason=0A> equitable capacity sharing is possi= ble (so not perfectly and not for every=0A> possible RTT spread).=0A> =0A> = >=0A> > So, what process measures the cross-interactions among all the user= s of all=0A> the paths, and what control-loop (presumably stable and TCP-co= mpatible) actually=0A> converges to RTT fairness IRL.=0A> =0A> Theoreticall= y nothing, in reality on a home link FQ+competent AQM goes a long way=0A> i= n that direction.=0A> =0A> =0A> >=0A> > Today, the basis of congestion cont= rol in the Internet is that each router is=0A> a controller of all endpoint= flows that share a link, and each router is free to=0A> do whatever it tak= es to reduce its queue length to near zero as an average on all=0A> timesca= les larger than about 1/10 of a second (a magic number that is directly=0A>= derived from measured human brain time resolution).=0A> =0A> The typical a= pplies, be suspicious of too round numbers.... 100ms is in no way=0A> magic= and also not "correct" it is however a decent description of reaction time= s=0A> in a number of perceptul tasks that can be mis-interpreted as showing= things like=0A> the brain runs at 10Hz or similar...=0A> =0A> =0A> >=0A> >= So, for any two machines separated by less than 1/10 of a light-second in= =0A> distance, the total queueing delay has to stabilize in about 1/10 of a= second.=0A> (I'm using a light-second in a fiber medium, not free-space, a= s the speed of light=0A> in fiber is a lot slower than the speed of light o= n microwaves, as Wall Street has=0A> recently started recoginizing and inve= sting in).=0A> >=0A> > I don't see how RTT-fairness can be achieved by some= set of bits in the IP=0A> header. You can't shorten RTT below about 2/10 o= f a second in that desired system=0A> state. You can only "lengthen" RTT by= delaying packets in source or endpoint=0A> buffers, because it's unreasona= ble to manage all the routers.=0A> >=0A> > And the endpoints that share a p= ath can't talk to each other and reach a=0A> decision in on the order of 2/= 10 of a second.=0A> >=0A> > So at the very highest level, what is RTT-fairn= ess's objective function=0A> optimizing, and how can it work?=0A> >=0A> > C= an it be done without any change to routers?=0A> =0A> Well the goal here se= ems to undo the RTT-dependence of throughput so a router can=0A> equalize p= er flow throughput and thereby (from its own vantage point) enforce RTT=0A>= independence, within the amount of memory available. And that already work= s today=0A> for all identifiable flows, but apparently at a computational c= ost that larger=0A> routers do not want to pay. But you knew all that=0A> = =0A> =0A> >=0A> >=0A> >=0A> >=0A> > On Tuesday, April 12, 2022 3:07pm, "Mic= hael Welzl" =0A> said:=0A> >=0A> >=0A> >=0A> > On Apr 1= 2, 2022, at 8:52 PM, Sebastian Moeller =0A> wrote:=0A> > Q= uestion: is QUIC actually using the spin bit as an essential part of the=0A= > protocol?=0A> > The spec says it=E2=80=99s optional: =0A> https://www.rfc= -editor.org/rfc/rfc9000.html#name-latency-spin-bit=0A> > Otherwise endpoint= s might just game this if faking their RTT at a router=0A> yields an advant= age...=0A> > This was certainly discussed in the QUIC WG. Probably perceive= d as an unclear=0A> incentive, but I didn=E2=80=99t really follow this.=0A>= > Cheers,=0A> > Michael=0A> >=0A> > This is why pping's use of tcp timesta= mps is elegant, little incentive for=0A> the endpoints to fudge....=0A> >= =0A> > Regards=0A> > Sebastian=0A> >=0A> >=0A> > On 12 April 2022 18:00:15 = CEST, Michael Welzl =0A> wrote:=0A> > Hi,=0A> > Who or = what are you objecting against? At least nothing that I described=0A> does = what you suggest.=0A> > BTW, just as a side point, for QUIC, routers can kn= ow the RTT today - using=0A> the spin bit, which was designed for that spec= ific purpose.=0A> > Cheers,=0A> > Michael=0A> >=0A> >=0A> > On Apr 12, 2022= , at 5:51 PM, David P. Reed =0A> wrote:=0A> > I strong= ly object to congestion control *in the network* attempting to=0A> measure = RTT (which is an end-to-end comparative metric). Unless the current RTT is= =0A> passed in each packet a router cannot enforce fairness. Period.=0A> >= =0A> > Today, by packet drops and fair marking, information is passed to th= e sending=0A> nodes (eventually) about congestion. But the router can't kno= w RTT today.=0A> >=0A> > The result of *requiring* RTT fairness would be to= put the random bottleneck=0A> router (chosen because it is the slowest for= warder on a contended path) become the=0A> endpoint controller.=0A> >=0A> >= That's the opposite of an "end-to-end resource sharing protocol".=0A> >=0A= > > Now, I'm not saying it is impossible - what I'm saying it is asking all= =0A> endpoints to register with an "Internet-wide" RTT real-time tracking a= nd control=0A> 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,=0A> rapid-convergence algortith= m that rellects to *every potential user* of a shared=0A> router along the = current path the RTT's of ALL other users (and potential users).=0A> >=0A> = > IMHO, the wish for RTT fairness is like saying that the entire solar syst= em's=0A> gravitational pull should be equalized so that all planets and ast= eroids have fair=0A> access to 1G gravity.=0A> >=0A> >=0A> > On Friday, Apr= il 8, 2022 2:03pm, "Michael Welzl" =0A> said:=0A> >=0A>= > Hi,=0A> > FWIW, we have done some analysis of fairness and convergence o= f DCTCP in:=0A> > Peyman Teymoori, David Hayes, Michael Welzl, Stein Gjessi= ng: "Estimating an=0A> Additive Path Cost with Explicit Congestion Notifica= tion", IEEE Transactions on=0A> Control of Network Systems, 8(2), pp. 859-8= 71, June 2021. DOI=0A> 10.1109/TCNS.2021.3053179=0A> > Technical report (lo= nger version):=0A> >=0A> https://folk.universitetetioslo.no/michawe/researc= h/publications/NUM-ECN_report_2019.pdf=0A> > and there=E2=80=99s also some = in this paper, which first introduced our LGC=0A> mechanism:=0A> > https://= ieeexplore.ieee.org/document/7796757=0A> > See the technical report on page= 9, section D: a simple trick can improve=0A> DCTCP=E2=80=99s fairness (if = that=E2=80=99s really the mechanism to stay with=E2=80=A6=0A> I=E2=80=99m g= etting quite happy with the results we get with our LGC scheme :-) =0A> )= =0A> >=0A> > Cheers,=0A> > Michael=0A> >=0A> > On Apr 8, 2022, at 6:33 PM, = Dave Taht wrote:=0A> > I have managed to drop most of= my state regarding the state of various=0A> > dctcp-like solutions. At one= level it's good to have not been keeping=0A> > up, washing my brain clean,= as it were. For some reason or another I=0A> > went back to the original p= aper last week, and have been pounding=0A> > through this one again:=0A> >= =0A> > Analysis of DCTCP: Stability, Convergence, and Fairness=0A> >=0A> > = "Instead, we propose subtracting =CE=B1/2 from the window size for each=0A>= marked ACK,=0A> > resulting in the following simple window update equation= :=0A> >=0A> > One result of which I was most proud recently was of demonstr= ating=0A> > perfect rtt fairness in a range of 20ms to 260ms with fq_codel= =0A> > https://forum.mikrotik.com/viewtopic.php?t=3D179307 )- and I'm prett= y=0A> > interested in 2-260ms, but haven't got around to it.=0A> >=0A> > No= w, one early result from the sce vs l4s testing I recall was severe=0A> > l= atecomer convergence problems - something like 40s to come into flow=0A> > = balance - but I can't remember what presentation, paper, or rtt that=0A> > = was from. ?=0A> >=0A> > Another one has been various claims towards some le= vel of rtt=0A> > unfairness being ok, but not the actual ratio, nor (going = up to the=0A> > paper's proposal above) whether that method had been tried.= =0A> >=0A> > My opinion has long been that any form of marking should look = more=0A> > closely at the observed RTT than any fixed rate reduction method= , and=0A> > compensate the paced rate to suit. But that's presently just re= duced=0A> > to an opinion, not having kept up with progress on prague, dctc= p-sce,=0A> > or bbrv2. As one example of ignorance, are 2 packets still pac= ed back=0A> > to back? DRR++ + early marking seems to lead to one packet be= ing=0A> > consistently unmarked and the other marked.=0A> >=0A> > --=0A> > = I tried to build a better future, a few times:=0A> > https://wayforward.arc= hive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org=0A> >=0A> > Dave T=C3=A4ht CEO,= TekLibre, LLC=0A> > _______________________________________________=0A> > = Ecn-sane mailing list=0A> > Ecn-sane@lists.bufferbloat.net=0A> > https://li= sts.bufferbloat.net/listinfo/ecn-sane=0A> >=0A> > --=0A> > Sent from my And= roid device with K-9 Mail. Please excuse my brevity.=0A> >=0A> =0A> ------=_20220419164009000000_65381 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Sebastian - all your t= houghts here seem reasonable.

=0A

 

=0A

I would point out only two things:

=0A

 

=0A

1) 100 ms. is a magic number for human= perception. It's basically the order of magnitude of humans' ability to re= spond to unpredictable events outside the human. That's why it is magic. No= w humans can actually perceive intervals much, much shorter (depending on h= ow we pay attention), but usually it is by comparing two events' time order= ing. We can even synchronize to external, predictable events with finer res= olution (as in Jazz improv or just good chamber music playing).  A cen= tury of careful scientific research supports this, niot just one experiment= . Which is why one should take it seriously as a useful target. (the fact t= hat one can achieve it across the planet with digital signalling networks m= akes it a desirable goal for anything interactive between a human and any e= ntity, be it computer or human). If one can do better, of course, that's gr= eat. I like that from my home computer I can get lots of places in under 8 = msec (15 msec RTT).

=0A

 

=0A

2) given that a particular heavily utilized link might be shared for = paths where the light-speed-in-fiber round trip for active flows varies by = an order of magnitude, why does one try to make fair RTT (as opposed to all= other possible metrics on each flow) among flows. It doesn't make any sens= e to me why. Going back to human interaction times, it makes sense to me th= at you might want to be unfair so that most flows get faster than 200 ms. R= TT, for example, penalizing those who are really close to each other anyway= .

=0A

If the RTT is already low because congestion h= as been controlled, you can't make it lower. Basically, the ideal queue sta= te is < 1 packet in the bottleneck outbound queues, no matter what the R= TT through that queue is.

=0A

 

=0A

 

=0A

 

=0A

On Thursday, April 14, 2022 5:25pm, "Sebastian Moeller" <moeller0@= gmx.de> said:

=0A
=0A

> Just indulge me here for a few crazy ideas ;)
&g= t;
> > On Apr 14, 2022, at 18:54, David P. Reed <dpreed@deep= plum.com> wrote:
> >
> > Am I to assume, then, tha= t routers need not pay any attention to RTT to
> achieve RTT-fairne= ss?
>
> Part of RTT-bias seems caused by the simple fact t= hat tight control loops work
> better than sloppy ones ;)
>=
> There seem to be three ways to try to remedy that to some degre= e:
> 1) the daft one:
> define a reference RTT (larger than= typically encountered) and have all TCPs
> respond as if encounter= ing that delay -> until the path RTT exceeds that
> reference TC= P things should be reasonably fair
>
> 2) the flows commun= icate with the bottleneck honestly:
> if flows would communicate th= eir RTT to the bottleneck the bottleneck could
> partition its reso= urces such that signaling (mark/drop) and puffer size is
> bespoke = per-flow. In theory that can work, but relies on either the RTT
> i= nformation being non-gameably linked to the protocol's operation* or everyb= ody
> being fully veridical and honest
> *) think a protoco= l that will only work if the best estimate of the RTT is
> communic= ated between the two sides continuously
>
> 3) the router = being verbose:
> If routers communicate the fill-state of their que= ue (global or per-flow does not
> matter all that much) flows in th= eory can do a better job at not putting way too
> much data in flig= ht remedying the cost of drops/marks that affects high RTT flows
> = more than the shorter ones. (The router has little incentive to lie here, i= f it
> wanted to punish a flow it would be easier to simply drop it= s packets and be done
> with).
>
>
> IMHO= 3, while theoretically the least effective of the three is the only one th= at
> has a reasonable chance of being employed... or rather is alre= ady deployed in the
> form of ECN (with mild effects).
> > > How does a server or client (at the endpoint) adjust RTT so t= hat it is fair?
>
> See 1) above, but who in their right m= ind would actually implement something like
> that (TCP Prague did = that, but IMHO never in earnest but just to "address" the
> L4S bul= let point RTT-bias reduction).
>
> > Now RTT, technical= ly, is just the sum of the instantaneous queue lengths in
> bytes a= long the path and the reverse path, plus a fixed wire-level delay. And
> routers along any path do not have correlated queue sizes.
> = >
> > It seems to me that RTT adjustment requires collective = real-time cooperation
> among all-or-most future users of that path= . The path is partially shared by many
> servers and many users, no= ne of whom directly speak to each other.
> >
> > And = routers have very limited memory compared to their throughput-RTdelay
= > product. So calculating the RTT using spin bits and UIDs for packets s= eems a bit
> much to expect all routers to do.
>
>= If posed like this, I guess the better question is, what can/should router= s be
> expected to do here: either equitably share their queues or = share queue
> inequitably such that throughput is equitable. From a= pure router point of the
> view the first seems "fairest", but as = fq_codel and cake show, within reason
> equitable capacity sharing = is possible (so not perfectly and not for every
> possible RTT spre= ad).
>
> >
> > So, what process measures the= cross-interactions among all the users of all
> the paths, and wha= t control-loop (presumably stable and TCP-compatible) actually
> co= nverges to RTT fairness IRL.
>
> Theoretically nothing, in= reality on a home link FQ+competent AQM goes a long way
> in that = direction.
>
>
> >
> > Today, the b= asis of congestion control in the Internet is that each router is
>= a controller of all endpoint flows that share a link, and each router is f= ree to
> do whatever it takes to reduce its queue length to near ze= ro as an average on all
> timescales larger than about 1/10 of a se= cond (a magic number that is directly
> derived from measured human= brain time resolution).
>
> The typical applies, be suspi= cious of too round numbers.... 100ms is in no way
> magic and also = not "correct" it is however a decent description of reaction times
>= ; in a number of perceptul tasks that can be mis-interpreted as showing thi= ngs like
> the brain runs at 10Hz or similar...
>
>= ;
> >
> > So, for any two machines separated by less= than 1/10 of a light-second in
> distance, the total queueing dela= y has to stabilize in about 1/10 of a second.
> (I'm using a light-= second in a fiber medium, not free-space, as the speed of light
> i= n fiber is a lot slower than the speed of light on microwaves, as Wall Stre= et has
> recently started recoginizing and investing in).
>= >
> > I don't see how RTT-fairness can be achieved by some s= et of bits in the IP
> header. You can't shorten RTT below about 2/= 10 of a second in that desired system
> state. You can only "length= en" RTT by delaying packets in source or endpoint
> buffers, becaus= e it's unreasonable to manage all the routers.
> >
> >= ; And the endpoints that share a path can't talk to each other and reach a<= br />> decision in on the order of 2/10 of a second.
> >
> > So at the very highest level, what is RTT-fairness's objective f= unction
> optimizing, and how can it work?
> >
>= > Can it be done without any change to routers?
>
> We= ll the goal here seems to undo the RTT-dependence of throughput so a router= can
> equalize per flow throughput and thereby (from its own vanta= ge point) enforce RTT
> independence, within the amount of memory a= vailable. And that already works today
> for all identifiable flows= , but apparently at a computational cost that larger
> routers do n= ot want to pay. But you knew all that
>
>
> ><= br />> >
> >
> >
> > On Tuesday, Apr= il 12, 2022 3:07pm, "Michael Welzl" <michawe@ifi.uio.no>
> sa= id:
> >
> >
> >
> > On Apr 12, = 2022, at 8:52 PM, Sebastian Moeller <moeller0@gmx.de>
> wrote= :
> > Question: is QUIC actually using the spin bit as an essent= ial 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...
> &g= t; This was certainly discussed in the QUIC WG. Probably perceived as an un= clear
> incentive, but I didn=E2=80=99t really follow this.
&g= t; > Cheers,
> > Michael
> >
> > This i= s why pping's use of tcp timestamps is elegant, little incentive for
&= gt; the endpoints to fudge....
> >
> > Regards
&= gt; > Sebastian
> >
> >
> > On 12 April= 2022 18:00:15 CEST, Michael Welzl <michawe@ifi.uio.no>
> wro= te:
> > Hi,
> > Who or what are you objecting against= ? At least nothing that I described
> does what you suggest.
&= gt; > BTW, just as a side point, for QUIC, routers can know the RTT toda= y - using
> the spin bit, which was designed for that specific purp= ose.
> > Cheers,
> > Michael
> >
>= >
> > On Apr 12, 2022, at 5:51 PM, David P. Reed <dpreed@= deepplum.com>
> wrote:
> > I strongly object to conge= stion control *in the network* attempting to
> measure RTT (which i= s an end-to-end comparative metric). Unless the current RTT is
> pa= ssed in each packet a router cannot enforce fairness. Period.
> >= ;
> > Today, by packet drops and fair marking, information is pa= ssed to the sending
> nodes (eventually) about congestion. But the = router can't know RTT today.
> >
> > The result of *r= equiring* RTT fairness would be to put the random bottleneck
> rout= er (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 ask= ing all
> endpoints to register with an "Internet-wide" RTT real-ti= me tracking and control
> service.
> >
> > Th= is 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 rellect= s 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, "Michae= l Welzl" <michawe@ifi.uio.no>
> said:
> >
>= ; > Hi,
> > FWIW, we have done some analysis of fairness and = convergence of DCTCP in:
> > Peyman Teymoori, David Hayes, Micha= el Welzl, Stein Gjessing: "Estimating an
> Additive Path Cost with = Explicit Congestion Notification", IEEE Transactions on
> Control o= f Network Systems, 8(2), pp. 859-871, June 2021. DOI
> 10.1109/TCNS= .2021.3053179
> > Technical report (longer version):
> &= gt;
> https://folk.universitetetioslo.no/michawe/research/publicati= ons/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 te= chnical report on page 9, section D: a simple trick can improve
> D= CTCP=E2=80=99s fairness (if that=E2=80=99s really the mechanism to stay wit= h=E2=80=A6
> I=E2=80=99m getting quite happy with the results we ge= t 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
> &= gt; 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 an= other I
> > went back to the original paper last week, and have = been pounding
> > through this one again:
> >
&g= t; > Analysis of DCTCP: Stability, Convergence, and Fairness
> &= gt;
> > "Instead, we propose subtracting =CE=B1/2 from the windo= w size for each
> marked ACK,
> > resulting in the follo= wing simple window update equation:
> >
> > One resul= t of which I was most proud recently was of demonstrating
> > pe= rfect 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.
> &= gt;
> > Now, one early result from the sce vs l4s testing I reca= ll was severe
> > latecomer convergence problems - something lik= e 40s to come into flow
> > balance - but I can't remember what = presentation, paper, or rtt that
> > was from. ?
> ><= br />> > Another one has been various claims towards some level of rt= t
> > unfairness being ok, but not the actual ratio, nor (going = up to the
> > paper's proposal above) whether that method had be= en tried.
> >
> > My opinion has long been that any f= orm of marking should look more
> > closely at the observed RTT = than any fixed rate reduction method, and
> > compensate the pac= ed rate to suit. But that's presently just reduced
> > to an opi= nion, 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.
> ><= br />> > --
> > I tried to build a better future, a few ti= mes:
> > https://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fww= w.icei.org
> >
> > Dave T=C3=A4ht CEO, TekLibre, LLC<= br />> > _______________________________________________
> &g= t; 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.
> >
>
>

=0A
= ------=_20220419164009000000_65381--