Subject: Re: [Tsvwg] draft-baker-diffserv-basic-classes-02.txt

From: Joe Touch <[email-masked]>
Date: Mon, 01 Mar 2004 03:44:41 -0800

Ken Carlberg wrote:

> the draft was just presented and it was agreed that it become a working 
> group item (i think pending review by "volunteers" having done work with 
> diff-serv?).

AFAIK, from talking with Allison afterwards, what was agreed was only 
that a group of people would look at it further.

The hum was mild, to say the least. And repeated goading was required to 
elicit 2 of the 3 requested volunteers to review the document, out of a 
standing-room only room.

Given the fact that the IETF rarely sees an ID that won't be adopted by 
-some- WG, the lack of enthusiasm was, IMO, deafening. I took it as a 
resounding "NO".

While I appreciate that the IETF may have a 'vested interest' in playing 
in this arena, the community (in the room at least) wasn't very 
enthusiastic at all.

Joe

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Fred Baker <[email-masked]>
Date: Mon, 01 Mar 2004 17:25:20 +0900

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 
service - one of the AF classes - that is set aside to manage that traffic.

Voice and Video streams are also similar in the sense that they call for 
admission and generate predictable data streams, but have significantly 
different service requirements. I have any number of customers that come to 
me looking for help in managing these.

And we could discuss the ieprep problem. Bottom line, they are not looking 
for a "keep the government running" service. They are looking for an IM 
service that gets emergency workers a high probability of delivery, a voice 
service that gives them improved call quality or enhanced probability of 
being able to make the call, and so on. This is not about some academic 
concept of a kind of service, like EF or AF, but of a service to an 
identified community using a class of applications that have specific 
requirements. If we don't meet the needs of the applications in question, 
we have had an interesting discussion, but we haven't helped anyone in any 
measurable way.

I would rather fix the fundamental ivory-tower-error that said "DSCPs 
identify services" and apply them to classes of traffic that my customers 
find themselves trying to control, and make real recommendations about how 
to control them.

>also, at that same meeting, Fred and another co-author worked on a draft
>that discussed the potential for an ingress code-point triggering a
>specific egress code-point -- a kind of asymetric phb marking (I'm not
>sure I articulated this well).  does the diffserv-basic-classes draft
>cause problems with this asymetric marking approach

You are talking about Rei Atarashi's reflexive marking draft. No, that 
actually takes the same model an interesting step. If we have folks who 
come to, say, a web site using DSCPs indicating that they have different 
service specifications, you want the replying traffic to use the same 
service classes.

Understand that in this draft we are not proposing to eliminate private 
service classes. We are proposing to use common code points and common 
service definitions for a few common classes.

---

From: Ken Carlberg <[email-masked]>
Date: Mon, 1 Mar 2004 07:43:33 +0000

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.  Does this represent a
shift in that thinking?  And perhaps more importantly, will the IESG reject
the effort on this basis?   this latter item would be nice to know so that
the group and authors don't hit a road block down the road.  I recall 
strong discussions on this subject at the Tokyo-IETF, but I never heard
a final consensus on the matter.

-ken

ps, my apologies for not speaking up at the meeting...its the usual 
lame excuse of massive jet lag