From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.85]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 098323B29D for ; Thu, 14 Apr 2022 16:49:41 -0400 (EDT) Received: from app50.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp35.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 73A224332; Thu, 14 Apr 2022 16:49:41 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app50.wa-webapps.iad3a (Postfix) with ESMTP id 5D67D600BD; Thu, 14 Apr 2022 16:49:41 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 14 Apr 2022 16:49:41 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Thu, 14 Apr 2022 16:49:41 -0400 (EDT) From: "David P. Reed" To: "Dave Taht" Cc: "Michael Welzl" , "ECN-Sane" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20220414164941000000_94357" 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: <1649969381.379610323@apps.rackspace.com> X-Mailer: webmail/19.0.13-RC X-Classification-ID: 6b3b4bf0-d8ef-4fc0-abf6-676af6b98815-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: Thu, 14 Apr 2022 20:49:42 -0000 ------=_20220414164941000000_94357 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AWhat does this have to do with QUIC and "spin bits"?=0AJust asking becau= se Michael triggered me to read the QUIC document he cited and that got me = to go and read RFC 9002 which supposedly (but not really) suggests that QUI= C has a "solution" to congestion in it.=0AI'm awfully skeptical that QUIC's= solution is a solution and not a new dramatic problem.=0A =0ATo me, the ke= y metric of solution is that it can be deployed in less than a year across = the entire current Internet - and it works. Otherwise, it's just handwaving= but-if-only-we-did-it-this-other-way everything would be great. That is wh= at ECN has been all along, along with diffserv.=0A =0AI think ECN has a sho= t at being helpful, but the core problem is that it was premised on the ide= a that in order to mark, you first need to create a bloated buffer in some = bottleneck link, and that all endpoints will treat ECN as they treat a drop= ped packet. But the endpoints stack designers are still measuring throughpu= t only, so they have no incentive to decrease windows, because that would m= ake throughput low. This isn't a problem with ECN, really, you could mark a= packet that goes through a node that is not already overloaded, but it tak= es courage to do that when all the industry is saying "you just lowered thr= oughput from 99.9% to 98%".=0A =0AOn Thursday, April 14, 2022 1:16pm, "Dave= Taht" said:=0A=0A=0A=0A> Actually, in looking back a= t what I wrote, I was=0A> =0A> A) comparing a recent rtt-fairness result I'= d got without ECN with=0A> multiple flows at 20ms to 260ms RTT that I was i= nsanely pleased with.=0A> =0A> B) while trying to understand and asking abo= ut what sort of=0A> RTT-fairness results were being achieved with early ECN= marking in the=0A> dctcp world. which until recently was mostly shooting f= or fairness in=0A> the sub-us to 2ms range. I was laboriously starting over= from=0A> scratch, reading the original papers, tracking the breadcrumbs fr= om=0A> 2009 until today, so I'd stumbled on some thoughts in the next paper= =0A> after the dctcp paper that I was too lazy to try and correlate to=0A> = present day "prague" and BBRv2 thinking.=0A> ------=_20220414164941000000_94357 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

What does this have to= do with QUIC and "spin bits"?

=0A

Just asking becau= se Michael triggered me to read the QUIC document he cited and that got me = to go and read RFC 9002 which supposedly (but not really) suggests that QUI= C has a "solution" to congestion in it.

=0A

I'm awfu= lly skeptical that QUIC's solution is a solution and not a new dramatic pro= blem.

=0A

 

=0A

To me, t= he key metric of solution is that it can be deployed in less than a year ac= ross the entire current Internet - and it works. Otherwise, it's just handw= aving but-if-only-we-did-it-this-other-way everything would be great. That = is what ECN has been all along, along with diffserv.

=0A

 

=0A

I think ECN has a shot at being help= ful, but the core problem is that it was premised on the idea that in order= to mark, you first need to create a bloated buffer in some bottleneck link= , and that all endpoints will treat ECN as they treat a dropped packet. But= the endpoints stack designers are still measuring throughput only, so they= have no incentive to decrease windows, because that would make throughput = low. This isn't a problem with ECN, really, you could mark a packet that go= es through a node that is not already overloaded, but it takes courage to d= o that when all the industry is saying "you just lowered throughput from 99= .9% to 98%".

=0A

 

=0A

O= n Thursday, April 14, 2022 1:16pm, "Dave Taht" <dave.taht@gmail.com> = said:

=0A
=0A

> Actually, in looking back at what I wrote, I was
>
> A) comparing a recent rtt-fairness result I'd got without ECN with> multiple flows at 20ms to 260ms RTT that I was insanely pleased wit= h.
>
> B) while trying to understand and asking about what= sort of
> RTT-fairness results were being achieved with early ECN = marking in the
> dctcp world. which until recently was mostly shoot= ing for fairness in
> the sub-us to 2ms range. I was laboriously st= arting over from
> scratch, reading the original papers, tracking t= he breadcrumbs from
> 2009 until today, so I'd stumbled on some tho= ughts in the next paper
> after the dctcp paper that I was too lazy= to try and correlate to
> present day "prague" and BBRv2 thinking.=
>

=0A
 ------=_20220414164941000000_94357--