Subject: Re: [Tsvwg] Accepting draft-baker-tsvwg-admitted-voice-dscp as WG item

From: [email-masked]
Date: Wed, 29 Nov 2006 13:12:40 +1100 (EST)

I support this becoming a WG document and think that we should consider up
to 4 EF codepoints for capacity-admitted traffic.

Question: Do we need to consider different codepoints for the
signalling/CAC traffic itself and if so would this only require changes to
rfc's such as rfc4594?
I ask because I do not know the likleyhood of an emergency service call
(or similar natured traffic) not being serviced appropriately because the
addmission control itself was inhibited by existing VoIP services that
perform only very coarse capacity admission.
>
> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, 22 November 2006 11:34 PM
> To: tsvwg
> Subject: [Tsvwg] Accepting draft-baker-tsvwg-admitted-voice-dscp as WG
> item
>
> This is a call for input on accepting An EF DSCP for Capacity-Admitted
> Traffic (draft-baker-tsvwg-admitted-voice-dscp) as WG item. Please
> provide any input both positive and negative at the latest on Wednesday
> the 6th of December.
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 30 Nov 2006 14:12:32 -0800

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.

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