From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp75.iad3a.emailsrvr.com (smtp75.iad3a.emailsrvr.com [173.203.187.75]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 337AD3B29E for ; Sat, 4 Dec 2021 17:30:00 -0500 (EST) Received: from app28.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp18.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C2188230DC; Sat, 4 Dec 2021 17:29:59 -0500 (EST) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app28.wa-webapps.iad3a (Postfix) with ESMTP id AEC4461BF6; Sat, 4 Dec 2021 17:29:59 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Sat, 4 Dec 2021 17:29:59 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Sat, 4 Dec 2021 17:29:59 -0500 (EST) From: "David P. Reed" To: "Dave Taht" Cc: "Jonathan Morton" , jonathan.kua@deakin.edu.au, "Cake List" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20211204172959000000_95962" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <0A6AB0B7-E010-42E3-BAEE-FCBFA5995117@gmail.com> X-Client-IP: 209.6.168.128 Message-ID: <1638656999.711523536@apps.rackspace.com> X-Mailer: webmail/19.0.13-RC X-Classification-ID: 502c4cb9-68ea-4684-a78a-3ac09cfa9713-1-1 Subject: Re: [Cake] Understanding the Achieved Rate Multiplication Effect in FlowQueue-based AQM Bottleneck X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2021 22:30:00 -0000 ------=_20211204172959000000_95962 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI just watched it. His assumption that "carrier networks can't solve the= problem because they can't control the hosts" is JUST WRONG!=0A =0AThe Int= ernet solution is to require the flows' source hosts to regulate their tran= smission based on dynamic feedback.=0A =0AAnd this ignorance on his part is= clearly his advisors' fault.=0A =0AThe pattern here is:=0A =0AI make assum= ption that rules out better solutions.=0A =0AI then invent some complicated= kludge "inside the network" and claim it solves the problem.=0A =0AThen I = demand that networks put this kludge into the network.=0A =0AIn other words= , he takes an end-to-end problem (regulating source rates to achive low int= ernal queue delay), and instead of implementing a solution at the ends, he = adds much more complexity inside the network.=0A =0AViolating the whole end= -to-end argument.=0A =0AOr, simplifying the point: "we have smarts in the r= outers, that we aren't using, so let's invent something to use them, even t= hough there are better solutions."=0A =0AYuck!=0A =0AThis is how we ended u= p with CISC computers, with operating systems that shove huge amounts of fu= nction into protected mode with heavy use of shared global variables protec= ted by complicated locks.=0A =0AOK, this creates the need for complicated P= hD theses where the coolness is how complicated the code was to get working= .=0A =0A =0A =0AOn Saturday, December 4, 2021 1:44pm, "Dave Taht" said:=0A=0A=0A=0A> It was the conquest tool they referenced th= at really caught my eye=0A> =0A> https://www.youtube.com/watch?v=3DQ3FFzB0S= Ujc=0A> =0A> "ConQuest: Fine-Grained Queue Measurement in the Data Plane"= =0A> =0A> On Fri, Dec 3, 2021 at 4:09 PM Jonathan Morton =0A> wrote:=0A> >=0A> > > On 4 Dec, 2021, at 12:27 am, Dave Taht =0A> wrote:=0A> > >=0A> > >=0A> https://jonathankua.github.= io/preprints/jkua-ieeelcn2021_understanding_ar_preprint-20jul2021.pdf=0A> >= >=0A> > > I would love it if somehow the measured effects of chunklets aga= inst=0A> cake's per-host/per flow fq was examined one day.=0A> >=0A> > I ha= ven't actually measured it, but based on what the above paper says, I can= =0A> make some firm predictions:=0A> >=0A> > 1: When competing against traf= fic to the same local host, the performance=0A> effects they describe will = be present.=0A> >=0A> > 2: When competing against traffic to a different lo= cal-network host, the=0A> performance effects they describe will be attenua= ted or even entirely absent.=0A> >=0A> > 3: They noted one or two cases of = observable effects of hash collisions in=0A> their tests with FQ-Codel. The= se will be greatly reduced in prevalence with Cake,=0A> due to the set-asso= ciative hash function which specifically addresses that=0A> phenomenon.=0A>= >=0A> > - Jonathan Morton=0A> =0A> =0A> =0A> --=0A> I tried to build a bet= ter future, a few times:=0A> https://wayforward.archive.org/?site=3Dhttps%3= A%2F%2Fwww.icei.org=0A> =0A> Dave T=C3=A4ht CEO, TekLibre, LLC=0A> ________= _______________________________________=0A> Cake mailing list=0A> Cake@list= s.bufferbloat.net=0A> https://lists.bufferbloat.net/listinfo/cake=0A> ------=_20211204172959000000_95962 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I just watched it. His= assumption that "carrier networks can't solve the problem because they can= 't control the hosts" is JUST WRONG!

=0A

 

= =0A

The Internet solution is to require the flows' sour= ce hosts to regulate their transmission based on dynamic feedback.

=0A 

=0A

And this ignorance on = his part is clearly his advisors' fault.

=0A

 <= /p>=0A

The pattern here is:

=0A

=  

=0A

I make assumption that rules out better s= olutions.

=0A

 

=0A

I th= en invent some complicated kludge "inside the network" and claim it solves = the problem.

=0A

 

=0A

T= hen I demand that networks put this kludge into the network.

=0A

 

=0A

In other words, he takes an = end-to-end problem (regulating source rates to achive low internal queue de= lay), and instead of implementing a solution at the ends, he adds much more= complexity inside the network.

=0A

 

=0A

Violating the whole end-to-end argument.

=0A

 

=0A

Or, simplifying the point: "= we have smarts in the routers, that we aren't using, so let's invent someth= ing to use them, even though there are better solutions."

=0A

 

=0A

Yuck!

=0A

This is how we ended up with CISC compu= ters, with operating systems that shove huge amounts of function into prote= cted mode with heavy use of shared global variables protected by complicate= d locks.

=0A

 

=0A

OK, t= his creates the need for complicated PhD theses where the coolness is how c= omplicated the code was to get working.

=0A

 =0A

 

=0A

 

=0AOn Saturday, December 4, 2021 1:44pm, "Dave Taht" <da= ve.taht@gmail.com> said:

=0A
=0A

> It was the conquest tool they referenced t= hat really caught my eye
>
> https://www.youtube.com/watch= ?v=3DQ3FFzB0SUjc
>
> "ConQuest: Fine-Grained Queue Measure= ment in the Data Plane"
>
> On Fri, Dec 3, 2021 at 4:09 PM= Jonathan Morton <chromatix99@gmail.com>
> wrote:
> &= gt;
> > > On 4 Dec, 2021, at 12:27 am, Dave Taht <dave.tah= t@gmail.com>
> wrote:
> > >
> > >> https://jonathankua.github.io/preprints/jkua-ieeelcn2021_understand= ing_ar_preprint-20jul2021.pdf
> > >
> > > I wou= ld love it if somehow the measured effects of chunklets against
> c= ake's per-host/per flow fq was examined one day.
> >
> &= gt; I haven't actually measured it, but based on what the above paper says,= I can
> make some firm predictions:
> >
> > = 1: When competing against traffic to the same local host, the performance> effects they describe will be present.
> >
> &g= t; 2: When competing against traffic to a different local-network host, the=
> performance effects they describe will be attenuated or even ent= irely absent.
> >
> > 3: They noted one or two cases = of observable effects of hash collisions in
> their tests with FQ-C= odel. These will be greatly reduced in prevalence with Cake,
> due = to the set-associative hash function which specifically addresses that
> phenomenon.
> >
> > - Jonathan Morton
>=
>
>
> --
> I tried to build a better fu= ture, a few times:
> https://wayforward.archive.org/?site=3Dhttps%3= A%2F%2Fwww.icei.org
>
> Dave T=C3=A4ht CEO, TekLibre, LLC<= br />> _______________________________________________
> Cake ma= iling list
> Cake@lists.bufferbloat.net
> https://lists.buf= ferbloat.net/listinfo/cake
>

=0A
 ------=_20211204172959000000_95962--