From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp124.iad3a.emailsrvr.com (smtp124.iad3a.emailsrvr.com [173.203.187.124]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0E27B3CB43 for ; Thu, 8 Jul 2021 16:14:00 -0400 (EDT) Received: from app44.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 85CB35726; Thu, 8 Jul 2021 16:14:00 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app44.wa-webapps.iad3a (Postfix) with ESMTP id 7336561D0C; Thu, 8 Jul 2021 16:14:00 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 8 Jul 2021 16:14:00 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Thu, 8 Jul 2021 16:14:00 -0400 (EDT) From: "David P. Reed" To: "Jonathan Morton" Cc: "Matt Mathis" , "=?utf-8?Q?Bless=2C_Roland_=28TM=29?=" , "cerowrt-devel@lists.bufferbloat.net" , "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20210708161400000000_32737" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <7175CC77-9B2B-4431-BF47-21F68CA29D26@gmail.com> References: <55fdf513-9c54-bea9-1f53-fe2c5229d7ba@eggo.org> <871t4as1h9.fsf@toke.dk> <3D32F19B-5DEA-48AD-97E7-D043C4EAEC51@gmail.com> <1465267957.902610235@apps.rackspace.com> <20210702095924.0427b579@hermes.local> <1bab95a0-7904-2807-02fe-62674c19948f@kit.edu> <393e9ca6-f9f3-1826-9fbc-6d36871223d8@kit.edu> <7175CC77-9B2B-4431-BF47-21F68CA29D26@gmail.com> X-Client-IP: 209.6.168.128 Message-ID: <1625775240.46936087@apps.rackspace.com> X-Mailer: webmail/19.0.7-RC X-Classification-ID: 770cd4ae-9c2a-4e4d-91b8-c6d4912627e5-1-1 Subject: Re: [Bloat] =?utf-8?q?=5BCerowrt-devel=5D__Abandoning_Window-based_CC?= =?utf-8?q?_Considered_Harmful_=28was_Re=3A_Bechtolschiem=29?= X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 20:14:01 -0000 ------=_20210708161400000000_32737 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AKeep It Simple, Stupid.=0A =0AThat's a classic architectural principle t= hat still applies. Unfortunately folks who only think hardware want to add = features to hardware, but don't study the actual real world version of the = problem.=0A =0AIMO, and it's based on 50 years of experience in network and= operating systems performance, latency (response time) is almost always th= e primary measure users care about. They never care about maximizing "utili= zation" of resources. After all, in a city, you get maximum utilization of = roads when you create a traffic jam. That's not the normal state. In commun= ications, the network should always be at about 10% utilization, because yo= u never want a traffic jam across the whole system to accumulate. Even the = old Bell System was engineered to not saturate the links on the worst minut= e of the worst hour of the worst day of the year (which was often Mother's = Day, but could be when a power blackout occurs).=0A =0AYet, academics becom= e obsessed with achieving constant very high utilization. And sometimes low= leve communications folks adopt that value system, until their customers s= tart complaining.=0A =0AWhy doesn't this penetrate the Net-Shaped Heads of = switch designers and others?=0A =0AWhat's excellent about what we used to c= all "best efforts" packet delivery (drop early and often to signal congesti= on) is that it is robust and puts the onus on the senders of traffic to sor= t out congestion as quickly as possible. The senders ALL observe congested = links quite early if their receivers are paying attention, and they can col= laborate *without even knowing who the others congesting the link are*. And= by picking the heaviest congestors with higher probability to drop, fq_cod= el pushes back in a "fair" way when congestion actually crops up. (probabil= istically).=0A =0AIt isn't the responsibility of routers to get packets thr= ough at any cost. It's their responsibility to signal congestion early enou= gh that it doesn't persist very long at all due to source based rate adapta= tion.=0AIn other words, a router's job is to route packets and do useful te= lemetry for the end points using it at the instant.=0A =0APlease stop focus= ing on what is an irrelevant metric (maximum throughput with maximum utiliz= ation in a special situation only).=0A =0AFocus on what routers can do well= because they actually observe it (instantaneous congestion events) and kee= p them simple.=0A.=0AOn Thursday, July 8, 2021 10:40am, "Jonathan Morton" <= chromatix99@gmail.com> said:=0A=0A=0A=0A> > On 8 Jul, 2021, at 4:29 pm, Mat= t Mathis via Bloat=0A> wrote:=0A> >=0A> > Tha= t said, it is also true that multi-stream BBR behavior is quite=0A> complic= ated and needs more queue space than single stream. This complicates the=0A= > story around the traditional workaround of using multiple streams to comp= ensate=0A> for Reno & CUBIC lameness at larger scales (ordinary scales toda= y). =0A> Multi-stream does not help BBR throughput and raises the queue occ= upancy, to the=0A> detriment of other users.=0A> =0A> I happen to think tha= t using multiple streams for the sake of maximising=0A> throughput is the w= rong approach - it is a workaround employed pragmatically by=0A> some appli= cations, nothing more. If BBR can do just as well using a single flow,=0A> = so much the better.=0A> =0A> Another approach to improving the throughput o= f a single flow is high-fidelity=0A> congestion control. The L4S approach t= o this, derived rather directly from DCTCP,=0A> is fundamentally flawed in = that, not being fully backwards compatible with ECN, it=0A> cannot safely b= e deployed on the existing Internet.=0A> =0A> An alternative HFCC design us= ing non-ambiguous signalling would be incrementally=0A> deployable (thus ap= plicable to Internet scale) and naturally overlaid on existing=0A> window-b= ased congestion control. It's possible to imagine such a flow reaching=0A> = optimal cwnd by way of slow-start alone, then "cruising" there in a true=0A= > equilibrium with congestion signals applied by the network. In fact, we'v= e=0A> already shown this occurring under lab conditions; in other cases it = still takes=0A> one CUBIC cycle to get there. BBR's periodic probing phases= would not be required=0A> here.=0A> =0A> > IMHO, two approaches seem to be= useful:=0A> > a) congestion-window-based operation with paced sending=0A> = > b) rate-based/paced sending with limiting the amount of inflight data=0A>= =0A> So this corresponds to approach a) in Roland's taxonomy.=0A> =0A> - J= onathan Morton=0A> _______________________________________________=0A> Cero= wrt-devel mailing list=0A> Cerowrt-devel@lists.bufferbloat.net=0A> https://= lists.bufferbloat.net/listinfo/cerowrt-devel=0A> ------=_20210708161400000000_32737 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Keep It Simple, Stupid= .

=0A

 

=0A

That's a cla= ssic architectural principle that still applies. Unfortunately folks who on= ly think hardware want to add features to hardware, but don't study the act= ual real world version of the problem.

=0A

 =0A

IMO, and it's based on 50 years of experience in n= etwork and operating systems performance, latency (response time) is almost= always the primary measure users care about. They never care about maximiz= ing "utilization" of resources. After all, in a city, you get maximum utili= zation of roads when you create a traffic jam. That's not the normal state.= In communications, the network should always be at about 10% utilization, = because you never want a traffic jam across the whole system to accumulate.= Even the old Bell System was engineered to not saturate the links on the w= orst minute of the worst hour of the worst day of the year (which was often= Mother's Day, but could be when a power blackout occurs).

=0A

 

=0A

Yet, academics become obsess= ed with achieving constant very high utilization. And sometimes low leve co= mmunications folks adopt that value system, until their customers start com= plaining.

=0A

 

=0A

Why = doesn't this penetrate the Net-Shaped Heads of switch designers and others?=

=0A

 

=0A

What's excell= ent about what we used to call "best efforts" packet delivery (drop early a= nd often to signal congestion) is that it is robust and puts the onus on th= e senders of traffic to sort out congestion as quickly as possible. The sen= ders ALL observe congested links quite early if their receivers are paying = attention, and they can collaborate *without even knowing who the others co= ngesting the link are*. And by picking the heaviest congestors with higher = probability to drop, fq_codel pushes back in a "fair" way when congestion a= ctually crops up. (probabilistically).

=0A

 =0A

It isn't the responsibility of routers to get pack= ets through at any cost. It's their responsibility to signal congestion ear= ly enough that it doesn't persist very long at all due to source based rate= adaptation.

=0A

In other words, a router's job is t= o route packets and do useful telemetry for the end points using it at the = instant.

=0A

 

=0A

Pleas= e stop focusing on what is an irrelevant metric (maximum throughput with ma= ximum utilization in a special situation only).

=0A

=  

=0A

Focus on what routers can do well because= they actually observe it (instantaneous congestion events) and keep them s= imple.

=0A

.

=0A

On Thursday,= July 8, 2021 10:40am, "Jonathan Morton" <chromatix99@gmail.com> said= :

=0A
=0A

> equilibrium with con= gestion signals applied by the network. In fact, we've
> already sh= own this occurring under lab conditions; in other cases it still takes
> one CUBIC cycle to get there. BBR's periodic probing phases would not= be required
> here.
>
> > IMHO, two approaches= seem to be useful:
> > a) congestion-window-based operation wit= h paced sending
> > b) rate-based/paced sending with limiting th= e amount of inflight data
>
> So this corresponds to appro= ach a) in Roland's taxonomy.
>
> - Jonathan Morton
&g= t; _______________________________________________
> Cerowrt-devel = mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https:= //lists.bufferbloat.net/listinfo/cerowrt-devel
>

=0A
------=_20210708161400000000_32737--