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" <[email protected]>
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, [email protected] 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
>
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
