Re: [Cerowrt-devel] [Bloat] fq_codel is two years old

[dpreed@reed.com]

[-- Attachment #1: Type: text/plain, Size: 4741 bytes --]


diffserv is not evil.  However, there has never been a practical mechanism for defining the meaning of the different "levels of service" across vendors and Autonomous Systems.
 
The problem is that diffserv is framed as if there were a global "controller" of the Internet who could impose a precise standard.
 
Andrew 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 metro pricing", which involves two things: making "first class" cost more than "second class", and providing a meaningful advantage for first class packet senders, while at the same time ensuring that "second class" was 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 people don't use it, and b) that the payments for first class packets go to the points of maximum congestion in the form of funds for upgrades, and not to the points of non-congestion.
 
And then create a means to globally purchase some number of "first class upgrades" that could be either attached to packets one sends, or get from the endpoint you are sending to as a "credit".
 
The routers would do some sort of prioritization of "first class" packets over "second class" packets along the way, and count how many first class packets were processed compared to second class packets.
 
The "upgrades" would expire frequently (daily?) and the cost of purchasing them would be changed daily so that there is a meaningful difference in observed latency on an end-to-end basis.
 
Etc.
 
You can see that even a single distinguished class of service needs some deep economic thinking so that it works on an end-to-end basis across autonomous systems.  (15 classes of service 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).
 
And in the end 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 particular time.  You can't fix congestion locally - you have to slow down the sources across all of the edge of the Internet, quickly.
 
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 instability - "market speculators".
 
If we can't make a "two 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.
 
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 good engineering solution to the real problem of a highly diverse, rapidly evolving system whose use is unpredictable from week to week and minute to minute.
 
So diffserv has always been more or less a "science project" with no clear application, IMHO.


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



> 
> 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 perhaps 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.com 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.
> 
> >
> >
> > Fixing buffer bloat allows the edge- and enterprise- networks to be more
> > efficient, whereas 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 exactly what Van told me when he was trying to get me to
> "paint the fence" of working on aqm again. (That volunteer effort again:
> his 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.
> 
> 	Kathie
>

[-- Attachment #2: Type: text/html, Size: 6255 bytes --]