From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp97.iad3a.emailsrvr.com (smtp97.iad3a.emailsrvr.com [173.203.187.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2045E21F304 for ; Wed, 21 May 2014 10:55:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C17D01280BD; Wed, 21 May 2014 13:55:07 -0400 (EDT) X-Virus-Scanned: OK Received: from app46.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A4BC71280C0; Wed, 21 May 2014 13:55:07 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by app46.wa-webapps.iad3a (Postfix) with ESMTP id 9017D80052; Wed, 21 May 2014 13:55:07 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Wed, 21 May 2014 13:55:07 -0400 (EDT) Date: Wed, 21 May 2014 13:55:07 -0400 (EDT) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20140521135507000000_72077" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <006001cf7478$804951e0$80dbf5a0$@riepnet.com> <006b01cf74e9$c9edf190$5dc9d4b0$@com> <1400683893.25854395@apps.rackspace.com> <1400688188.27216078@apps.rackspace.com> Message-ID: <1400694907.588216717@apps.rackspace.com> X-Mailer: webmail7.0 Cc: Frits Riep , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration. X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 17:55:09 -0000 ------=_20140521135507000000_72077 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AThe end-to-end argument against putting functionality in the network is = a modularity principle, as you know. The exception is when there is a funct= ion that you want to provide that is not strictly end-to-end.=0A =0ACongest= ion is one of them - there is a fundamental issue with congestion that it h= appens because of collective actions among independent actors.=0A =0ASo if = you want to achieve the goals of the modularity principle, you need to find= either a) the minimal sensing and response you can put in the network that= allows the independent actors to "cooperate", or b) require the independen= t actors to discover and communicate amongst each other individually.=0A = =0AAny solution that tries to satisfy the modularity principle has the prop= erty that it provides sufficient information, in a sufficiently timely mann= er, for the independent actors to respond "cooperatively" to resolve the is= sue (by reducing their transmission volume in some - presumably approximate= ly fair - way).=0A =0ASufficiently timely is bounded by the "draining time"= of a switch's outbound link's queue. For practical applications of the In= ternet today, the "draining time" should never exceed about 30-50 msec., at= the outbound link's rate. However, the optimal normal depth of the queue = should be no larger than the size needed to keep the outbound link continuo= usly busy at its peak rate whatever that is (for a shared WiFi access point= the peak rate is highly variable as you know).=0A =0AThis suggests that th= e minimal function the network must provide to the endpoints is the packet'= s "instantaneous" contribution to the draining time of the most degraded li= nk on the path.=0A =0AGiven this information, a pair of endpoints know what= to do. If it is a receiver-managed windowed protocol like TCP, the window= needs to be adjusted to minimize the contribution to the "draining time" o= f the currently bottlenecked node, to stop pipelined flows from its sender = as quickly as possible.=0A =0AIn that case, cooperative behavior is implici= t. The bottleneck switch needs only to inform all independent flows of the= ir contribution, and with an appropriate control loop on each node, approxi= mate fairness can result.=0A =0AAnd this is the most general approach. Swi= tches have no idea of the "meaning" of the flows, so beyond timely and accu= rate reporting, they can't make useful decisions about fixing congestion.= =0A =0ANote that this all is an argument about architectural principles and= the essence of the congestion problem.=0A =0AI could quibble about whether= fq_codel is the simplest or best choice for the minimal functionality an "= internetwork" could provide. But it's pretty nice and simple. Not clear i= t works for a decentralized protocol like WiFi as a link - but something li= ke it would seem to be the right thing.=0A =0A =0A=0A=0AOn Wednesday, May 2= 1, 2014 12:30pm, "Dave Taht" said:=0A=0A=0A=0A> On We= d, May 21, 2014 at 9:03 AM, wrote:=0A> > In reality we d= on't disagree on this:=0A> >=0A> >=0A> >=0A> > On Wednesday, May 21, 2014 1= 1:19am, "Dave Taht" =0A> said:=0A> >=0A> >>=0A> >=0A> = >> Well, I disagree somewhat. The downstream shaper we use works quite=0A> = >> well, until we run out of cpu at 50mbits. Testing on the ubnt edgerouter= =0A> >> has had the inbound shaper work up a little past 100mbits. So there= is=0A> >> no need (theoretically) to upgrade the big fat head ends if your= cpe is=0A> >> powerful enough to do the job. It would be better if the hea= d ends did=0A> it,=0A> >> of course....=0A> >>=0A> >=0A> >=0A> >=0A> > Ther= e is an advantage for the head-ends doing it, to the extent that each=0A> >= edge device has no clarity about what is happening with all the other cpe= =0A> > that are sharing that head-end. When there is bloat in the head-end = even if=0A> > all cpe's sharing an upward path are shaping themselves to th= e "up to" speed=0A> > the provider sells, they can go into serious congesti= on if the head-end=0A> > queues can grow to 1 second or more of sustained q= ueueing delay. My=0A> > understanding is that head-end queues have more th= an that. They certainly=0A> > do in LTE access networks.=0A> =0A> Compelli= ng argument! I agree it would be best for the devices that have the=0A> mos= t information about the network to manage themselves better.=0A> =0A> It is= deeply ironic to me that I'm arguing for an e2e approach on fixing=0A> the= problem in the field, with you!=0A> =0A> http://en.wikipedia.org/wiki/End-= to-end_principle=0A> =0A> >=0A> >=0A> =0A> =0A> =0A> --=0A> Dave T=C3=A4ht= =0A> =0A> NSFW:=0A> https://w2.eff.org/Censorship/Internet_censorship_bills= /russell_0296_indecent.article=0A> ------=_20140521135507000000_72077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The end-to= -end argument against putting functionality in the network is a modularity = principle, as you know. The exception is when there is a function that you = want to provide that is not strictly end-to-end.

=0A

 

=0A

Congestion is on= e of them - there is a fundamental issue with congestion that it happens be= cause of collective actions among independent actors.

=0A

 

=0A

So if you w= ant to achieve the goals of the modularity principle, you need to find eith= er a) the minimal sensing and response you can put in the network that allo= ws the independent actors to "cooperate", or b) require the independent act= ors to discover and communicate amongst each other individually.

=0A

 

=0A

= Any solution that tries to satisfy the modularity principle has the propert= y that it provides sufficient information, in a sufficiently timely manner,= for the independent actors to respond "cooperatively" to resolve the issue= (by reducing their transmission volume in some - presumably approximately = fair - way).

=0A

 

=0A

Sufficiently timely is bounded by the "draining ti= me" of a switch's outbound link's queue.  For practical applications o= f the Internet today, the "draining time" should never exceed about 30-50 m= sec., at the outbound link's rate.  However, the optimal normal depth = of the queue should be no larger than the size needed to keep the outbound = link continuously busy at its peak rate whatever that is (for a shared WiFi= access point the peak rate is highly variable as you know).

=0A

 

=0A

This= suggests that the minimal function the network must provide to the endpoin= ts is the packet's "instantaneous" contribution to the draining time of the= most degraded link on the path.

=0A

&nb= sp;

=0A

Given this information, a pair o= f endpoints know what to do.  If it is a receiver-managed windowed pro= tocol like TCP, the window needs to be adjusted to minimize the contributio= n to the "draining time" of the currently bottlenecked node, to stop pipeli= ned flows from its sender as quickly as possible.

=0A

 

=0A

In that case, c= ooperative behavior is implicit.  The bottleneck switch needs only to = inform all independent flows of their contribution, and with an appropriate= control loop on each node, approximate fairness can result.

=0A

 

=0A

And = this is the most general approach.  Switches have no idea of the "mean= ing" of the flows, so beyond timely and accurate reporting, they can't make= useful decisions about fixing congestion.

=0A

 

=0A

Note that this all is = an argument about architectural principles and the essence of the congestio= n problem.

=0A

 

=0A

I could quibble about whether fq_codel is the simplest= or best choice for the minimal functionality an "internetwork" could provi= de.  But it's pretty nice and simple.  Not clear it works for a d= ecentralized protocol like WiFi as a link - but something like it would see= m to be the right thing.

=0A

 

= =0A

 

=0A





On Wednesday, May 21, 2014 12:30pm, "Dave Taht"= <dave.taht@gmail.com> said:

=0A
=0A

> On Wed, May 21, 2014 at= 9:03 AM, <dpreed@reed.com> wrote:
> > In reality we don'= t disagree on this:
> >
> >
> >
> = > On Wednesday, May 21, 2014 11:19am, "Dave Taht" <dave.taht@gmail.co= m>
> said:
> >
> >>
> >
> >> Well, I disagree somewhat. The downstream shaper we use work= s quite
> >> well, until we run out of cpu at 50mbits. Testin= g on the ubnt edgerouter
> >> has had the inbound shaper work= up a little past 100mbits. So there is
> >> no need (theoret= ically) to upgrade the big fat head ends if your cpe is
> >> = powerful enough to do the job. It would be better if the head ends did
> it,
> >> of course....
> >>
> >= ;
> >
> >
> > There is an advantage for th= e head-ends doing it, to the extent that each
> > edge device ha= s no clarity about what is happening with all the other cpe
> > = that are sharing that head-end. When there is bloat in the head-end even if=
> > all cpe's sharing an upward path are shaping themselves to = the "up to" speed
> > the provider sells, they can go into serio= us congestion if the head-end
> > queues can grow to 1 second or= more of sustained queueing delay. My
> > understanding is that= head-end queues have more than that. They certainly
> > do in = LTE access networks.
>
> Compelling argument! I agree it w= ould be best for the devices that have the
> most information about= the network to manage themselves better.
>
> It is deeply= ironic to me that I'm arguing for an e2e approach on fixing
> the = problem in the field, with you!
>
> http://en.wikipedia.or= g/wiki/End-to-end_principle
>
> >
> >
&= gt;
>
>
> --
> Dave T=C3=A4ht
> =
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorshi= p_bills/russell_0296_indecent.article
>

=0A
 ------=_20140521135507000000_72077--