Fred Baker <fred <at> cisco.com>
2004-03-01 08:25:20 GMT
At 04:43 PM 03/01/04, Ken Carlberg wrote:
>in taking the devil's advocate position, I'm curious as to the response of
>the authors to those that would object to the draft because it seems to be
>counter to the original diff-serv architecture tenet that code-points
>should not be "tied" to applications.
I thought that was the wrong position at the time, and I think so now.
Consider, if you will, the question of how one handles (this from the slide
Kwok showed, which is from a service provider customer, or the DISA class
proposal. Bottom line, there are very few uses of diff-serv technology that
work well as a service in a sense divorced from the application.
For example, I am asked by any number of edge networks and ISPs how to
identify peer-2-peer traffic, whether to shut it down, manage it, or turn
it into a service. There are various possible ways; none of them are "look
for the user to be asking for a service which is 'move lots of stuff from
here to there'". What they wind up looking for is a long-lived session that
generates a lot of traffic. They often do this by positioning a policer
that accepts traffic at a high rate for a short interval, but starts
marking traffic differently if the rate continues. This traffic may be
treated as more-drop-eligible, may be dropped entirely at an upstream
provider's point, may be charged for in a different manner, or etc.
Increasingly, the ISPs are telling me that they want to host the p2p server
as a service and as a result be in control of it. But bottom line, they are
worried about a class of applications that do something specific to their
network - usually in a manner that costs them money and needs to have
either a way to reduce it or to charge for it. This traffic differs
immensely from HTTP, SMTP, and such, even though they share the fundamental
characteristic of being elastic. So simply saying "well, it goes in the AF
service" isn't adequate. It needs to go into a specified instance of the AF