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

From: [email-masked]
Date: Thu, 27 May 2004 22:44:11 EDT

In a message dated 5/27/2004 9:07:27 AM Eastern Standard Time, 
[email-masked] writes:

> In the next revision (03) of the draft (should be put on the mailing list 
> shortly) we state that peer-to-peer signaling such as SIP and H.323 be 
> forwarded out of a different service class than telephony payload. I will analyze 
> the impact on speech and ring clipping at beginning of call when interfacing to 
> a TDM telephony switch if all telephony signaling would be forwarded using a 
> different queue (higher latency) than the voice bearer. My motivation for 
> mapping telephony signaling in to the same queue as voice bearer was to 
> eliminate the delta delay between audio and signaling, therefore reducing the chance 
> of ring and speech clipping at beginning of call. Other suggestions to 
> address this problem are welcome.
> In the draft we recommend that for Telephony service, per DSCP traffic 
> 

I believe this remains as one of the major open questions for the application 
of SIP or H.323 in a large, managed network. Some comments:

I've heard of speech clipping (on answer), but I don't know what 
"ring-clipping" is. I presume you are referring to call setup delay (or delay to ring). 
The issue is signaling delay in general (call setup and release), but speech 
clipping has always been the most serious impact of delay.

It seems to me that this issue is really not related to "interfacing to a TDM 
telephony switch", but occurs equally within a fully IP environment.

No matter what service class is used for signaling (above, below, or same as 
speech bearer) there must be guaranteed bandwidth for the expected signaling 
traffic to provide sufficient low latency and almost zero discard rate 
independent from the amount of speech bearer traffic. In effect, if signaling is in a 
separate class and is guaranteed, say 5% of the bandwidth on an outgoing link 
and speech bearer (EF) is guaranteeed 50%, then it isn't really necessary to 
think of one being above or below or the same as the other. The forwarding 
algorithm guarantees a minimum bandwidth to both in what is effectively 
"time-division multiplexing", but we don't call it that since it is not based on strict 
timing. The result is that the signaling does not experience "higher latency", 
but probably has "higher delay variation", mostly due to the varying packet 
sizes.

The problem with putting signaling in the same class (queue) as speech bearer 
seems to be that the proper management of the speech queue depends partly on 
all of the packets in the queue being roughly the same size. While packets 
from codecs are something like 20-40 bytes, signaling messages, especially SIP, 
can get very long and would require segmentation. If they are in the same queue 
as speech, it doesn't seem that they can be segmented to allow speech packets 
to be transmitted between the segments.

In addition, there must be different discard policies applied to signaling 
packets than for speech packets. While discard of speech packets is normal and 
expected under overload (queue overflow), signaling packets must not be 
discarded.

Mike Pierce

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

---

From: Kwok Ho Chan <[email-masked]>
Date: Fri, 28 May 2004 08:15:08 -0400

The co-authors have considered the variable packet sizes of the signaling 
packets as
compared to the more fixed size of the speech packets.  Especially wrt SIP 
and its
variable payload.
Hence in 
http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-02.txt
Section 4.1.1 on page 23 where CS5 marking recommendation for telephony 
service class
excludes SIP.
And have SIP be in Low Latency Data Service Class described in Section 
4.2.2 on page 30.
One of the reason for this is because of increasing use of SIP as a 
transport for many things
(some encripted).
IMHO, I think some of the concerns of this E-Mail thread are alone the same 
line.
Do you think the current text in those sections are sufficient to resolve 
the issue?
Thank you very much for all the comments.
-- Kwok Ho Chan --

At 10:44 PM 5/27/2004, [email-masked] wrote:
>>forwarded out of a different service class than telephony payload. I will 
>>analyze the impact on speech and ring clipping at beginning of call when 
>>interfacing to a TDM telephony switch if all telephony signaling would be 
>>forwarded using a different queue (higher latency) than the voice bearer. 
>>My motivation for mapping telephony signaling in to the same queue as 
>>voice bearer was to eliminate the delta delay between audio and 
>>signaling, therefore reducing the chance of ring and speech clipping at 
>>beginning of call. Other suggestions to address this problem are welcome.
>I believe this remains as one of the major open questions for the 
>application of SIP or H.323 in a large, managed network. Some comments:
>
>"ring-clipping" is. I presume you are referring to call setup delay (or 
>delay to ring). The issue is signaling delay in general (call setup and 
>release), but speech clipping has always been the most serious impact of 
>delay.
>
>It seems to me that this issue is really not related to "interfacing to a 
>TDM telephony switch", but occurs equally within a fully IP environment.
>
>No matter what service class is used for signaling (above, below, or same 
>as speech bearer) there must be guaranteed bandwidth for the expected 
>signaling traffic to provide sufficient low latency and almost zero 
>discard rate independent from the amount of speech bearer traffic. In 
>effect, if signaling is in a separate class and is guaranteed, say 5% of 
>the bandwidth on an outgoing link and speech bearer (EF) is guaranteeed 
>50%, then it isn't really necessary to think of one being above or below 
>or the same as the other. The forwarding algorithm guarantees a minimum 
>bandwidth to both in what is effectively "time-division multiplexing", but 
>we don't call it that since it is not based on strict timing. The result 
>is that the signaling does not experience "higher latency", but probably 
>has "higher delay variation", mostly due to the varying packet sizes.
>
>The problem with putting signaling in the same class (queue) as speech 
>bearer seems to be that the proper management of the speech queue depends 
>partly on all of the packets in the queue being roughly the same size. 
>While packets from codecs are something like 20-40 bytes, signaling 
>messages, especially SIP, can get very long and would require 
>segmentation. If they are in the same queue as speech, it doesn't seem 
>that they can be segmented to allow speech packets to be transmitted 
>between the segments.
>
>packets than for speech packets. While discard of speech packets is normal 
>and expected under overload (queue overflow), signaling packets must not 
>be discarded.
>
>Mike Pierce