From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (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 4EC5D21F331 for ; Thu, 15 May 2014 13:32:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2F51FE0115; Thu, 15 May 2014 16:32:56 -0400 (EDT) X-Virus-Scanned: OK Received: from app4.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 08CA2E00C2; Thu, 15 May 2014 16:32:56 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by app4.wa-webapps.iad3a (Postfix) with ESMTP id E8FBD28005B; Thu, 15 May 2014 16:32:55 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Thu, 15 May 2014 16:32:55 -0400 (EDT) Date: Thu, 15 May 2014 16:32:55 -0400 (EDT) From: dpreed@reed.com To: "Kathleen Nichols" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20140515163255000000_45856" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <5374EC39.7040902@pollere.com> References: <3583FA43-EF5B-42D7-A79C-54C87AA514D5@gmail.com> <5373EEFF.5030407@pollere.com> <1400161663.82913275@apps.rackspace.com> <5374EC39.7040902@pollere.com> Message-ID: <1400185975.95298344@apps.rackspace.com> X-Mailer: webmail7.0 Cc: cerowrt-devel , bloat Subject: Re: [Cerowrt-devel] =?utf-8?q?=5BBloat=5D_fq=5Fcodel_is_two_years_old?= 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: Thu, 15 May 2014 20:32:57 -0000 ------=_20140515163255000000_45856 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0Adiffserv is not evil. However, there has never been a practical mechani= sm for defining the meaning of the different "levels of service" across ven= dors and Autonomous Systems.=0A =0AThe problem is that diffserv is framed a= s if there were a global "controller" of the Internet who could impose a pr= ecise standard.=0A =0AAndrew Odlyzko once proposed that the Internet try a = very simple experiment - invent "first class" and "second class" packets. = (just one bit of differentiation). Then try to emulate so-called "paris me= tro pricing", which involves two things: making "first class" cost more tha= n "second class", and providing a meaningful advantage for first class pack= et senders, while at the same time ensuring that "second class" was very go= od. And they adjust the pricing daily or hourly to achieve a global goal: = a) that the price of first class is high enough that most people don't use = it, and b) that the payments for first class packets go to the points of ma= ximum congestion in the form of funds for upgrades, and not to the points o= f non-congestion.=0A =0AAnd then create a means to globally purchase some n= umber of "first class upgrades" that could be either attached to packets on= e sends, or get from the endpoint you are sending to as a "credit".=0A =0AT= he routers would do some sort of prioritization of "first class" packets ov= er "second class" packets along the way, and count how many first class pac= kets were processed compared to second class packets.=0A =0AThe "upgrades" = would expire frequently (daily?) and the cost of purchasing them would be c= hanged daily so that there is a meaningful difference in observed latency o= n an end-to-end basis.=0A =0AEtc.=0A =0AYou can see that even a single dist= inguished class of service needs some deep economic thinking so that it wor= ks on an end-to-end basis across autonomous systems. (15 classes of servic= e might be definable, but deploying them across the world Internet in a way= that the mean the "same" everywhere, and in a way that the differentiated = payments actually have a *real* effect on observed service across a many-AS= path is an exercise likely to create a market failure).=0A =0AAnd in the e= nd of the day, the problem is congestion, which is very non-linear. There = is almost no congestion at almost all places in the Internet at any particu= lar time. You can't fix congestion locally - you have to slow down the sou= rces across all of the edge of the Internet, quickly.=0A =0ANon-linear cost= functions do not reach Pareto optimality in a bursty and unpredictable mar= ket. So the folks who would win are those who benefit from extreme non-lin= earity and instability - "market speculators".=0A =0AIf we can't make a "tw= o class" worldwide diffserv work, my sense is that there's no possible way = the current diffserv could be made to work in a business and economic sense= .=0A =0AThis is the fundamental engineering problem. Not the writing down = of standards and debating them in the IETF, which is silly if it's not a go= od engineering solution to the real problem of a highly diverse, rapidly ev= olving system whose use is unpredictable from week to week and minute to mi= nute.=0A =0ASo diffserv has always been more or less a "science project" wi= th no clear application, IMHO.=0A=0A=0AOn Thursday, May 15, 2014 12:32pm, "= Kathleen Nichols" said:=0A=0A=0A=0A> =0A> Gosh, that'= s high praise. And what's really neat is that this was such a=0A> team effo= rt=0A> where we don't even necessarily know each other! What's perhaps bad = is that=0A> this was a "volunteer" effort, though that also is a strength. = I'm not=0A> sure the=0A> answer is for everyone to work for Google.=0A> =0A= > On 5/15/14 6:47 AM, dpreed@reed.com wrote:=0A> ...=0A> >=0A> > The soluti= on du jour is to leave bufferbloat in place, while using the=0A> > real fad= s: prioritization (diffserv once we have the "fast lanes" fully=0A> > legal= ) and "software defined networking" appliances that use DPI for=0A> > packe= t routing and traffic management.=0A> >=0A> =0A> I think diffserv could be = used for good instead of evil.=0A> =0A> >=0A> >=0A> > Fixing buffer bloat a= llows the edge- and enterprise- networks to be more=0A> > efficient, wherea= s not fixing it lets the edge networks move users up to=0A> > more and more= expensive "plans" due to frustration and to sell much more=0A> > gear into= Enterprises because they are easy marks for complex gadgets.=0A> >=0A> >= =0A> =0A> The above is exactly what Van told me when he was trying to get m= e to=0A> "paint the fence" of working on aqm again. (That volunteer effort = again:=0A> his employer at that time was not paying him to do this sort of = thing, so=0A> he had to interest someone to work with him.) I hope you peop= le with big=0A> platforms will continue to try to educate folks.=0A> =0A> = =09Kathie=0A> ------=_20140515163255000000_45856 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

diffserv i= s not evil.  However, there has never been a practical mechanism for d= efining the meaning of the different "levels of service" across vendors and= Autonomous Systems.

=0A

 

=0AThe problem is that diffserv is framed as if= there were a global "controller" of the Internet who could impose a precis= e standard.

=0A

 

=0A

Andrew Odlyzko once proposed that the Internet try a = very simple experiment - invent "first class" and "second class" packets. &= nbsp;(just one bit of differentiation).  Then try to emulate so-called= "paris metro pricing", which involves two things: making "first class" cos= t more than "second class", and providing a meaningful advantage for first = class packet senders, while at the same time ensuring that "second class" w= as very good.  And they adjust the pricing daily or hourly to achieve = a global goal: a) that the price of first class is high enough that most pe= ople don't use it, and b) that the payments for first class packets go to t= he points of maximum congestion in the form of funds for upgrades, and not = to the points of non-congestion.

=0A

&nb= sp;

=0A

And then create a means to globa= lly purchase some number of "first class upgrades" that could be either att= ached to packets one sends, or get from the endpoint you are sending to as = a "credit".

=0A

 

=0A

The routers would do some sort of prioritization of "= first class" packets over "second class" packets along the way, and count h= ow many first class packets were processed compared to second class packets= .

=0A

 

=0A

The "upgrades" would expire frequently (daily?) and the cost of= purchasing them would be changed daily so that there is a meaningful diffe= rence in observed latency on an end-to-end basis.

=0A

 

=0A

Etc.

=0A

 

=0A

= You can see that even a single distinguished class of service needs some de= ep economic thinking so that it works on an end-to-end basis across autonom= ous systems.  (15 classes of service might be definable, but deploying= them across the world Internet in a way that the mean the "same" everywher= e, and in a way that the differentiated payments actually have a *real* eff= ect on observed service across a many-AS path is an exercise likely to crea= te a market failure).

=0A

 

=0A<= p style=3D"margin:0;padding:0;">And in the end of the day, the problem is c= ongestion, which is very non-linear.  There is almost no congestion at= almost all places in the Internet at any particular time.  You can't = fix congestion locally - you have to slow down the sources across all of th= e edge of the Internet, quickly.

=0A

&nb= sp;

=0A

Non-linear cost functions do not= reach Pareto optimality in a bursty and unpredictable market.  So the= folks who would win are those who benefit from extreme non-linearity and i= nstability - "market speculators".

=0A

&= nbsp;

=0A

If we can't make a "two class"= worldwide diffserv work, my sense is that there's no possible way the curr= ent diffserv could be made to work in a business and economic sense.

=0A=

 

=0A

This is the fundamental engineering problem.  Not the writing down= of standards and debating them in the IETF, which is silly if it's not a g= ood engineering solution to the real problem of a highly diverse, rapidly e= volving system whose use is unpredictable from week to week and minute to m= inute.

=0A

 

=0A

So diffserv has always been more or less a "science projec= t" with no clear application, IMHO.

=0A

=



On Thursday, May 15, 2014 12:32pm, "Kathleen Nichols" = <nichols@pollere.com> said:

=0A
=0A

>
> Gosh, that's = high praise. And what's really neat is that this was such a
> team = effort
> where we don't even necessarily know each other! What's pe= rhaps bad is that
> this was a "volunteer" effort, though that also= is a strength. I'm not
> sure the
> answer is for everyone= to work for Google.
>
> On 5/15/14 6:47 AM, dpreed@reed.c= om wrote:
> ...
> >
> > The solution du jour = is to leave bufferbloat in place, while using the
> > real fads:= prioritization (diffserv once we have the "fast lanes" fully
> >= ; legal) and "software defined networking" appliances that use DPI for
> > packet routing and traffic management.
> >
> =
> I think diffserv could be used for good instead of evil.
&g= t;
> >
> >
> > Fixing buffer bloat allows= the edge- and enterprise- networks to be more
> > efficient, wh= ereas not fixing it lets the edge networks move users up to
> > = more and more expensive "plans" due to frustration and to sell much more> > gear into Enterprises because they are easy marks for complex = gadgets.
> >
> >
>
> The above is ex= actly what Van told me when he was trying to get me to
> "paint the= fence" of working on aqm again. (That volunteer effort again:
> hi= s employer at that time was not paying him to do this sort of thing, so
> he had to interest someone to work with him.) I hope you people with= big
> platforms will continue to try to educate folks.
> <= br />> =09Kathie
>

=0A
 ------=_20140515163255000000_45856--