Subject: Re: [Tsvwg] Accepting draft-baker-tsvwg-admitted-voice-dscp asWGitem

From: fil <[email-masked]>
Date: Fri, 1 Dec 2006 12:27:07 +1000

Hi Fred, you wrote on 12/1/2006 8:12:32 AM:

>On Nov 28, 2006, at 6:12 PM, [email-masked] wrote:
>> I support this becoming a WG document
>
>Thanks
>
>> and think that we should consider up to 4 EF codepoints for  
>> capacity-admitted traffic.
>
>I hesitate here. I think I understand where you are going, and agree  
>with Dave McDysan that having enough latitude in the draft to handle  
>common video uses make sense. That said, at least at this point we  
>don't have any appreciable use of video for emergency use - ieprep  
>has really only looked at voice, some in the relevant communities  
>have wondered whether video should be considered, and have made  
>specific requests regarding certain elastic applications. I'm not  
>sure that the need is well demonstrated at this point.
>
>If the discussion is coming around to using the four additional code  
>points for a service that classifies five different priority levels,  
>with current EF as "routine", you'll pardon me if I stomp around a  
>bit. That is a block we have been around many times, and it STILL  
>belongs in the control plane, not the data plane, and STILL should be  
>handled by dropping or scheduling individual calls, not by screwing  
>up entire classes of calls.
>
>I need to know what problem you think you're solving. I think the  
>working group needs sufficient grounds before attempting to solve  
>unspecified problems.
>

Please save your feet and stop the stomping.:-)
Yes, I was only seeking latitude in the draft to handle video. I agree with 
your comment that the need for video as an emergency service is yet 
to be demonstrated and think that what you have proposed in your draft looks to 
address the problem at hand with voice.

>> Question: Do we need to consider different codepoints for the  
>> signaling/CAC traffic itself and if so would this only require  
>> changes to rfc's such as rfc4594?
>
>Personally, I don't see the value of doing so. As a percentage of  
>traffic, SIP signaling is very nominal. The reason it has a separate  
>class in RFC 4594 is because a certain ITU specification sets certain  
>expectations on signaling traffic end to end, and pulling it into a  
>separate queue protects it from ddos and other issues in the more  
>prosaic traffic classes. I'm hard pressed to understand why an  
>allocation that prevents the loss of signaling traffic on Mother's  
>Day while a ddos is happening in another traffic class isn't  
>sufficient. In any event, I think the problem needs to be  
>demonstrated. The issues in voice and video are trivial to  
>demonstrate; they are not as obviously so for elastic traffic classes.
>
Thanks. I was seeking opinion rather than alluding to a proposal and you 
have answered my question well. I look forward to seeing this draft develop.
Cheers.