Subject: Re: EF DSCP for Capacity-Admitted Traffic (was: Re: [Tsvwg] TSVWG meeting"hum" confirmations with the list)

From: Lars Eggert <[email-masked]>
Date: Mon, 2 Apr 2007 19:37:22 +0300

On 2007-3-29, at 13:12, ext Romascanu, Dan (Dan) wrote:
>> From: Lars Eggert [mailto:[email-masked]]
>> 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.

As I understand it - and someone needs to really jump in here and  
tell me whether I've understood it - is that jitter gets sufficiently  
bad to really affect voice quality, even under low loss. Remember  
that this is for interactive traffic.

>> 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.

I don't follow, can you clarify? Your first sentence agrees with the  
argument (that we're on a slippery slope towards per-media-type  
DSCPs, which I find worrying), but then you say one shouldn't mix  
traffic types, which seems to argue _for_ per-media-type DSCPs.

>> 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.

I'd be happier if we could draw a boundary between these two kinds of  
traffic that aren't based on media types, because that'd give me some  
reassurance that we're not setting ourselves up for many more future  
registrations.

Idea: can we reclassify "capacity admitted voice" as "capacity  
admitted low-jitter" traffic, and "capacity-admitted video" as  
"capacity admitted high-bandwidth", and argue that the former should  
have precedence over the latter? (Or something like this; my proposal  
may be naive.)

Lars

PS: all hats off

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 3 Apr 2007 18:56:03 -0400

>have precedence over the latter? (Or something like this; my proposal  
I'm OK with classify it for "capacity admitted low-jitter" traffic. I
believe that voice was only an example as it will mostly be the first
use case. Same for "capacity admitted high-bandwidth", MPEG4 video flows
would be an example of traffic that would use this DSCP. My view is that
any flow that fits the defined characteristics and performance
requirements can use this capability and is not limited to voice or
video flows. 

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: April 2, 2007 12:37 PM
To: ext Romascanu, Dan (Dan)
Cc: ext James M. Polk; tsvwg
Subject: Re: EF DSCP for Capacity-Admitted Traffic (was: Re: [Tsvwg]
TSVWG meeting"hum" confirmations with the list)

Lars

PS: all hats off