Fil Dickinson | 25 May 06:27 2004
Picon

draft-baker-diffserv-basic-classes-02

My understanding of this draft is that it proposes the Voice signalling and
Voice Bearer are transported in the same class with the exception being
"signaling flows between high capacity telephony call servers or soft
switches". 
I am concerned with this. During testing of our multi-vendor converged
network I have seen that oversubscribed voice bearer traffic can disrupt the
voice signalling traffic which results in abnormal operation of all voice
calls [re-registration (outage) of IP Phones]. I would like to see this
addressed by a draft that mandates All Voice Signalling and Voice Bearer
traffic operate in distinct classes. Ie, a Telephony Signalling Service
Class and a Telephony Bearer Service Class.
rfc-editor | 27 May 01:08 2004

RFC 3758 on Stream Control Transmission Protocol (SCTP) Partial Reliability Extension


A new Request for Comments is now available in online RFC libraries.

        RFC 3758

        Title:      Stream Control Transmission Protocol (SCTP)
                    Partial Reliability Extension
        Author(s):  R. Stewart, M. Ramalho, Q. Xie, M. Tuexen,
                    P. Conrad
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    rrs <at> cisco.com, mramalho <at> cisco.com,
                    qxie1 <at> email.mot.com, tuexen <at> fh-muenster.de,
                    conrad <at> acm.org
        Pages:      22
        Characters: 50999
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-tsvwg-prsctp-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3758.txt

This memo describes an extension to the Stream Control Transmission
Protocol (SCTP) that allows an SCTP endpoint to signal to
its peer that it should move the cumulative ack point forward.  When
both sides of an SCTP association support this extension, it can be
used by an SCTP implementation to provide partially reliable data
transmission service to an upper layer protocol.  This memo describes
the protocol extensions, which consist of a new parameter for
INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one
(Continue reading)

Jozef Babiarz | 27 May 14:25 2004

RE: draft-baker-diffserv-basic-classes-02

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 conditioning, policing of EF and CS5 market packets interpedently be performed, as well flow admission control needs to be performed so that oversubscription within the Telephony services does not occur.

 
Regards, Joe.
-----Original Message-----
From: Fil Dickinson [mailto:Fil.Dickinson <at> optus.com.au]
Sent: Tuesday, May 25, 2004 12:27 AM
To: tsvwg <at> ietf.org
Subject: [Tsvwg] draft-baker-diffserv-basic-classes-02

My understanding of this draft is that it proposes the Voice signalling and
Voice Bearer are transported in the same class with the exception being
"signaling flows between high capacity telephony call servers or soft
switches".
I am concerned with this. During testing of our multi-vendor converged
network I have seen that oversubscribed voice bearer traffic can disrupt the
voice signalling traffic which results in abnormal operation of all voice
calls [re-registration (outage) of IP Phones]. I would like to see this
addressed by a draft that mandates All Voice Signalling and Voice Bearer
traffic operate in distinct classes. Ie, a Telephony Signalling Service
Class and a Telephony Bearer Service Class.

_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
Mpierce1 | 28 May 04:44 2004
Picon

Re: draft-baker-diffserv-basic-classes-02

In a message dated 5/27/2004 9:07:27 AM Eastern Standard Time, babiarz <at> nortelnetworks.com 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
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
Kwok Ho Chan | 28 May 14:15 2004

Re: draft-baker-diffserv-basic-classes-02

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, Mpierce1 <at> aol.com wrote:
In a message dated 5/27/2004 9:07:27 AM Eastern Standard Time, babiarz <at> nortelnetworks.com 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
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
_______________________________________________
tsvwg mailing list
tsvwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

Gmane