Subject: [Tsvwg] TSVWG meeting "hum" confirmations with the list

From: "James M. Polk" <[email-masked]>
Date: Wed, 28 Mar 2007 14:12:06 -0500

TSVWG

[Responses to this message are necessary by April 6th]

At last week's TSVWG meeting, the WG did couple of "hums" or actual 
counting of hands to show support for IDs becoming WG items or of 
support for an ID going in a particular direction. This is the report on that:

#1 - To adopt
         draft-swallow-rsvp-user-error-spec-01
as a WG item.

20 hands raised for
0 hands raised against

#2 - counting hands that want Fred's "An EF DSCP for 
Capacity-Admitted Traffic" ID to have a separate DSCP for video:

15 hands raised for
0 hands raised against

If anyone in the WG does not approve of any of these directions or 
approvals made during the TSVWG meetings last please send a note to 
the list (or simply reply to this message) stating so - with what you 
disagree about technically.

Others in TSVWG can respond with their approval of the WG actions 
from the meetings last week as well.

Additionally, the TSVWG chairs believe the 2 MIB IDs presented need 
to become WG items because it is the right thing to do for the 
community, knowing few in the WG have read them, mostly because they 
are not necessarily sexy/attractive subjects to everyone.

Does any disapprove of making either

         draft-renker-tsvwg-udplite-mib-01
or
         draft-persson-v6ops-mib-issue-01.txt

TSVWG WG items?

Please let the list know why you do not believe these should be WG items.

cheers,

James
Lars
Magnus
         IETF TSVWG co-chairs

---

From: Lars Eggert <[email-masked]>
Date: Thu, 29 Mar 2007 09:25:43 +0300

On 2007-3-28, at 22:12, ext James M. Polk wrote:
> community, knowing few in the WG have read them, mostly because  
> they are not necessarily sexy/attractive subjects to everyone.

I don't think adoption at this time is quite what we'd like to see  
happen.

First, a group with energy needs to work out what the correct fix for  
our existing MIBs (UDP, TCP, TCP-ESTATS) is. One proposal is draft- 
persson-v6ops-mib-issue-01.txt; someone else suggested in a private  
conversation to use IP address, protocol number and port number as an  
index into the process/thread table to find the correct computational  
entity for a connection.

Once we know what the fix should be, we make _something_ a work item  
that applies it to our three existing MIBs, and draft-renker-tsvwg- 
udplite-mib-01 incorporates a similar change before moving on.

I'm interested to hear (1) whether this approach sounds good and (2)  
who would be interested in being part of the "group with energy".

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 29 Mar 2007 09:44:31 +0300

On 2007-3-28, at 22:12, ext James M. Polk wrote:
> #2 - counting hands that want Fred's "An EF DSCP for Capacity- 
> Admitted Traffic" ID to have a separate DSCP for video:
>
> 15 hands raised for
> 0 hands raised against

<chair hat off>

I thought about this some, and starting to allocate per-application  
or at lease per-media-type codepoints makes me nervous. I'm not a  
DiffServ expert, so let me run down my thinking, so the experts can  
point out whether I'm misunderstanding something.

First off, I can understand the rationale that capacity-admitted  
traffic can be considered more important that plain EF traffic, and  
should get its own queue.

Now, the issue seems to be that if you throw flows of different media  
types into that traffic class - even if their aggregate bandwidth use  
is within capacity - this can result in unacceptable media quality in  
some (many?) scenarios. Hence the desire to create multiple, per- 
media-type queues, i.e., DSCPs.

What worries me is that I see no indication that two DSCPs is all  
that will be needed. The current deployment interest seems to be in  
mixing CAC voice and video, but will we need to allocate additional  
DSCPs when deployments want to capacity-admit additional types of  
traffic? How many?

DiffServ wasn't meant to eliminate the need for some degree of over- 
provisioning, and it seems that if the admission controller would  
keep utilization of the capacity for capacity-admitted traffic below  
some threshold, media quality would remain acceptable, and only a  
single DSCP would be needed. Is that not sufficient?

As I said, I'm not a DiffServ expert. Comments/clarifications/ 
corrections welcome.

Lars

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 29 Mar 2007 07:58:26 +0100 (BST)

The authors plans' for the UDP-Lite MIB are to make a revision along the 
lines suggested in tsvwg, to correct the UDP-Lite parts of the MIB (by end 
of April) and will issue a new draft.

We then have an agreement from a couple of people to review this and look 
at the process table issue. We'll forward comments to their and our comments to 
the list. If more people can help figure the way for the process-matching 
to take place,, we'd be delighted.

Best wishes,

Gorry & Gerrit

On Thu, 29 Mar 2007, Lars Eggert wrote:

>> Additionally, the TSVWG chairs believe the 2 MIB IDs presented need to 
>> become WG items because it is the right thing to do for the community, 
>> knowing few in the WG have read them, mostly because they are not 
>> necessarily sexy/attractive subjects to everyone.
>
> I don't think adoption at this time is quite what we'd like to see happen.
>
> First, a group with energy needs to work out what the correct fix for our 
> existing MIBs (UDP, TCP, TCP-ESTATS) is. One proposal is draft- 
> conversation to use IP address, protocol number and port number as an index 
> into the process/thread table to find the correct computational entity for a 
> connection.
>
> Once we know what the fix should be, we make _something_ a work item that 
> applies it to our three existing MIBs, and draft-renker-tsvwg-udplite-mib-01 
> incorporates a similar change before moving on.
>
> I'm interested to hear (1) whether this approach sounds good and (2) who 
> would be interested in being part of the "group with energy".
>

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 29 Mar 2007 12:12:51 +0200

See in-line. All my hats are off. 

Dan

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Thursday, March 29, 2007 8:45 AM
> To: ext James M. Polk
> Cc: tsvwg
> Subject: EF DSCP for Capacity-Admitted Traffic (was: Re: 
> [Tsvwg] TSVWG meeting"hum" confirmations with the list)
> 
> I thought about this some, and starting to allocate 
> per-application or at lease per-media-type codepoints makes 
> me nervous. I'm not a DiffServ expert, so let me run down my 
> thinking, so the experts can point out whether I'm 
> misunderstanding something.
> 
> First off, I can understand the rationale that 
> capacity-admitted traffic can be considered more important 
> that plain EF traffic, and should get its own queue.
> 
> Now, the issue seems to be that if you throw flows of 
> different media types into that traffic class - even if their 
> aggregate bandwidth use is within capacity - this can result 
> in unacceptable media quality in some (many?) scenarios. 

Why that? Assuming that the capacity threshold according to which the
admission happens is computed correctly, why should unacceptable media
result for traffic admitted within limits. 

> Hence the desire to create multiple, per- media-type queues, 
> i.e., DSCPs.
> 
> What worries me is that I see no indication that two DSCPs is 
> all that will be needed. The current deployment interest 
> seems to be in mixing CAC voice and video, but will we need 
> to allocate additional DSCPs when deployments want to 
> capacity-admit additional types of traffic? How many?

This argument seems to me valid. Actually I doubt that mixing CAC voice
and video is a good thing in many real scenarios as bandwidth, traffic
profile and QoS metrics largely differ for voice-only and
voice-and-video applications. 

> 
> DiffServ wasn't meant to eliminate the need for some degree 
> of over- provisioning, and it seems that if the admission 
> controller would keep utilization of the capacity for 
> capacity-admitted traffic below some threshold, media quality 
> would remain acceptable, and only a single DSCP would be 
> needed. Is that not sufficient?

IMHO the proposal brings a relative optimization that would help in many
scenarios. Yes, it does not scale infinitely in what concerns the number
of media types / traffic classes, yet if aggregation is used so that
balance is kept between the number of classes and the types of media and
applications that are supported such an optimization seems to help. 
 
> 
> As I said, I'm not a DiffServ expert. 
> Comments/clarifications/ corrections welcome.
> 
> Lars
>

---

From: Dave McDysan <[email-masked]>
Date: Thu, 29 Mar 2007 14:47:44 -0400

I suggest that we need to more precisely define what is meant by "video" to
address Dan's point regarding scaling. There are a limited number of DSCPs,
and not every service class (as defined in RFC 4594) has a need for
distinction between admission controlled and non-admission controlled
traffic. 

What I had in mind from RFC 4594 was CS4 for real-time interactve (Video
conferencing and Interactive gaming), broadcast TV (CS3) for use in a video
on demand context, and possibly AF4 Multimedia conferencing (video
conferencing). These applications have one or more potential congestion
points between the video distribution/conferencing bridge or gaming server
and the user(s), and reserving capacity for them is important to application
performance. All of these applications have low tolerance to jitter (aka
delay variation) and loss, as summarized in Figure 2, and most (except for
multimedia conferencing) have inelastic flow behavior from Figure 1 of RFC
4594. I believe that inelastic flow behavior and low jitter/loss tolerance
are the service characteristics that define the need for admission control
behavior.

The above proposal would constrain admission-controlled video to two (or
three) additional DSCPs, addressing Dan's point on scaling.

Also, I recommend that the document emphasize that in order for any of these
admission controlled approaches to work, packets that have not been
subjected to the "tighter" admission control need to be remarked to some
other code point (e.g., the "looser" admission control DSCP) at all UNI and
NNI points. This embellishment could be placed in the security
considerations section with the "script kiddies" as an example of a source
of compromise if the above remarking is not done. It should also be stated
in the discussion related to Figure 1.

Dave

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Thursday, March 29, 2007 6:13 AM
> To: Lars Eggert; ext James M. Polk
> Cc: tsvwg
> Subject: RE: EF DSCP for Capacity-Admitted Traffic (was: Re: 
> per-application or 
> > at lease per-media-type codepoints makes me nervous. I'm not a 
> different media 
> > some (many?) scenarios.
> Why that? Assuming that the capacity threshold according to 
> which the admission happens is computed correctly, why should 
> unacceptable media result for traffic admitted within limits. 
> 
> > Hence the desire to create multiple, per- media-type queues, i.e., 
> > DSCPs.
> > 
> > What worries me is that I see no indication that two DSCPs 
> is all that 
> > will be needed. The current deployment interest seems to be 
> in mixing 
> > CAC voice and video, but will we need to allocate additional DSCPs 
> > when deployments want to capacity-admit additional types of 
> traffic? 
> > How many?
> 
> This argument seems to me valid. Actually I doubt that mixing 
> CAC voice and video is a good thing in many real scenarios as 
> bandwidth, traffic profile and QoS metrics largely differ for 
> voice-only and voice-and-video applications. 
> 
> > 
> of over- 
> > provisioning, and it seems that if the admission controller 
> would keep 
> > utilization of the capacity for capacity-admitted traffic 
> below some 
> > threshold, media quality would remain acceptable, and only a single 
> > DSCP would be needed. Is that not sufficient?
> 
> IMHO the proposal brings a relative optimization that would 
> help in many scenarios. Yes, it does not scale infinitely in 
> what concerns the number of media types / traffic classes, 
> yet if aggregation is used so that balance is kept between 
> the number of classes and the types of media and applications 
> that are supported such an optimization seems to help. 
>  
> >