From tsvwg-admin@ietf.org Mon May 24 12:59:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19133 for ; Mon, 24 May 2004 12:59:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSInS-0005HB-SG for tsvwg-archive@ietf.org; Mon, 24 May 2004 12:59:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSILe-000508-00 for tsvwg-archive@ietf.org; Mon, 24 May 2004 12:30:46 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BSIKp-0004tp-00 for tsvwg-archive@ietf.org; Mon, 24 May 2004 12:29:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BSICt-0004AJ-1f for tsvwg-archive@ietf.org; Mon, 24 May 2004 12:21:43 -0400 Date: Mon, 24 May 2004 12:21:43 -0400 Message-ID: <20040524162143.16012.13654.Mailman@www1.ietf.org> Subject: Welcome to the "tsvwg" mailing list From: tsvwg-request@ietf.org To: tsvwg-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: tsvwg-admin@ietf.org Errors-To: tsvwg-admin@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Transport Area Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Welcome to the tsvwg@ietf.org mailing list! To post to this list, send your email to: tsvwg@ietf.org General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/tsvwg ************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ************************************************************************** If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www1.ietf.org/mailman/options/tsvwg/tsvwg-archive%40ietf.org You can also make such adjustments via email by sending a message to: tsvwg-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: avabaz If you forget your password, don't worry, you will receive a monthly reminder telling you what all your ietf.org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From tsvwg-bounces@ietf.org Tue May 25 00:38:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29675 for ; Tue, 25 May 2004 00:38:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSThu-0003ix-1C for tsvwg-archive@ietf.org; Tue, 25 May 2004 00:38:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSTgx-0003cF-00 for tsvwg-archive@ietf.org; Tue, 25 May 2004 00:37:31 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BSTg8-0003PF-00; Tue, 25 May 2004 00:36:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSTdB-0005fA-V9; Tue, 25 May 2004 00:33:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSTZE-00059J-8v for tsvwg@megatron.ietf.org; Tue, 25 May 2004 00:29:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29265 for ; Tue, 25 May 2004 00:29:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BSTZB-0002PT-Qj for tsvwg@ietf.org; Tue, 25 May 2004 00:29:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSTYG-0002Iz-00 for tsvwg@ietf.org; Tue, 25 May 2004 00:28:33 -0400 Received: from mail1.optus.com.au ([203.13.126.129]) by ietf-mx with esmtp (Exim 4.12) id 1BSTXe-00025k-00 for tsvwg@ietf.org; Tue, 25 May 2004 00:27:54 -0400 Received: from chonte008.optus.com.au ([161.43.32.100]) by mail1.optus.com.au with trend_isnt_name_B; Tue, 25 May 2004 14:27:15 +1000 Received: by cnt5973.optus.com.au with Internet Mail Service (5.5.2657.72) id ; Tue, 25 May 2004 14:27:14 +1000 Message-ID: <9976E136B745D511B82C00508BB23E0909F30A9C@shqnte002.optus.com.au> From: Fil Dickinson To: tsvwg@ietf.org Date: Tue, 25 May 2004 14:27:09 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Tsvwg] draft-baker-diffserv-basic-classes-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg From tsvwg-bounces@ietf.org Wed May 26 19:30:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28540 for ; Wed, 26 May 2004 19:30:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BT7qZ-0007dR-Gr for tsvwg-archive@ietf.org; Wed, 26 May 2004 19:30:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BT7pY-0007Tk-00 for tsvwg-archive@ietf.org; Wed, 26 May 2004 19:29:05 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BT7of-0007B8-00; Wed, 26 May 2004 19:28:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BT7by-00060M-4y; Wed, 26 May 2004 19:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BT7Y7-0004M2-ND for tsvwg@megatron.ietf.org; Wed, 26 May 2004 19:11:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27219 for ; Wed, 26 May 2004 19:10:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BT7Y5-0005cP-1a for tsvwg@ietf.org; Wed, 26 May 2004 19:11:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BT7XO-0005X3-00 for tsvwg@ietf.org; Wed, 26 May 2004 19:10:19 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BT7WG-0005Lc-00; Wed, 26 May 2004 19:09:08 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4QN81J17557; Wed, 26 May 2004 16:08:01 -0700 (PDT) Message-Id: <200405262308.i4QN81J17557@boreas.isi.edu> To: IETF-Announce: ; From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 26 May 2004 16:08:01 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Cc: tsvwg@ietf.org, rfc-editor@rfc-editor.org Subject: [Tsvwg] RFC 3758 on Stream Control Transmission Protocol (SCTP) Partial Reliability Extension X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart 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@cisco.com, mramalho@cisco.com, qxie1@email.mot.com, tuexen@fh-muenster.de, conrad@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 example of a partially reliable service that can be provided to the upper layer via this mechanism. This document is a product of the Transport Area Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040526160623.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3758 --OtherAccess Content-Type: Message/External-body; name="rfc3758.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040526160623.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --NextPart-- From tsvwg-bounces@ietf.org Thu May 27 09:08:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23222 for ; Thu, 27 May 2004 09:08:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTKcw-0002Wq-LU for tsvwg-archive@ietf.org; Thu, 27 May 2004 09:08:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTKbx-0002Iu-00 for tsvwg-archive@ietf.org; Thu, 27 May 2004 09:07:55 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BTKbU-000252-00; Thu, 27 May 2004 09:07:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTKPk-0003XG-FN; Thu, 27 May 2004 08:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTK0J-0000pF-Br for tsvwg@megatron.ietf.org; Thu, 27 May 2004 08:28:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20672 for ; Thu, 27 May 2004 08:28:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTK0I-0000u2-LH for tsvwg@ietf.org; Thu, 27 May 2004 08:28:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTJz9-0000Zf-00 for tsvwg@ietf.org; Thu, 27 May 2004 08:27:49 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BTJxN-0007aw-00 for tsvwg@ietf.org; Thu, 27 May 2004 08:25:57 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4RCPMV06369; Thu, 27 May 2004 08:25:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 May 2004 08:25:22 -0400 Message-ID: From: "Jozef Babiarz" To: Fil Dickinson , tsvwg@ietf.org Subject: RE: [Tsvwg] draft-baker-diffserv-basic-classes-02 Date: Thu, 27 May 2004 08:25:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Cc: Jozef Babiarz X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1084120016==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1084120016== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C443E5.AE85EEA2" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C443E5.AE85EEA2 Content-Type: text/plain; charset="iso-8859-1" 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@optus.com.au] Sent: Tuesday, May 25, 2004 12:27 AM To: tsvwg@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@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg ------_=_NextPart_001_01C443E5.AE85EEA2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Tsvwg] 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@optus.co= m.au]
Sent: Tuesday, May 25, 2004 12:27 AM
To: tsvwg@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@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

------_=_NextPart_001_01C443E5.AE85EEA2-- --===============1084120016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1084120016==-- From tsvwg-bounces@ietf.org Thu May 27 23:16:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14567 for ; Thu, 27 May 2004 23:16:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTXr0-0001pi-N7 for tsvwg-archive@ietf.org; Thu, 27 May 2004 23:16:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTXpr-0001F1-00 for tsvwg-archive@ietf.org; Thu, 27 May 2004 23:15:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BTXof-0000iQ-00; Thu, 27 May 2004 23:13:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTXgb-0004rt-Td; Thu, 27 May 2004 23:05:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTXOH-0001e7-Qg for tsvwg@megatron.ietf.org; Thu, 27 May 2004 22:46:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13607 for ; Thu, 27 May 2004 22:46:35 -0400 (EDT) From: Mpierce1@aol.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTXOF-0001RD-VG for tsvwg@ietf.org; Thu, 27 May 2004 22:46:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTXNH-00015v-00 for tsvwg@ietf.org; Thu, 27 May 2004 22:45:36 -0400 Received: from imo-d05.mx.aol.com ([205.188.157.37]) by ietf-mx with esmtp (Exim 4.12) id 1BTXMZ-0000kH-00 for tsvwg@ietf.org; Thu, 27 May 2004 22:44:51 -0400 Received: from Mpierce1@aol.com by imo-d05.mx.aol.com (mail_out_v37_r1.3.) id d.194.293a358c (4214); Thu, 27 May 2004 22:44:12 -0400 (EDT) Message-ID: <194.293a358c.2de8017b@aol.com> Date: Thu, 27 May 2004 22:44:11 EDT Subject: Re: [Tsvwg] draft-baker-diffserv-basic-classes-02 To: babiarz@nortelnetworks.com, Fil.Dickinson@optus.com.au, tsvwg@ietf.org MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 51 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1472179714==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 --===============1472179714== Content-Type: multipart/alternative; boundary="part1_194.293a358c.2de8017b_boundary" --part1_194.293a358c.2de8017b_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/27/2004 9:07:27 AM Eastern Standard Time, babiarz@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 --part1_194.293a358c.2de8017b_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 5/27/2004 9:07:27 AM Eastern Standard Time, babiarz@nortelnetworks.com= writes:


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



I believe this remains as one of the major open questions for the applic= ation 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-c= lipping" is. I presume you are referring to call setup delay (or delay to ri= ng). The issue is signaling delay in general (call setup and release), but s= peech clipping has always been the most serious impact of delay.

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

No matter what service class is used for signaling (above, below, or sam= e as speech bearer) there must be guaranteed bandwidth for the expected sign= aling traffic to provide sufficient low latency and almost zero discard rate= independent from the amount of speech bearer traffic. In effect, if signali= ng is in a separate class and is guaranteed, say 5% of the bandwidth on an o= utgoing 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. Th= e forwarding algorithm guarantees a minimum bandwidth to both in what is eff= ectively "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 exper= ience "higher latency", but probably has "higher delay variation", mostly du= e to the varying packet sizes.

The problem with putting signaling in the same class (queue) as speech b= earer seems to be that the proper management of the speech queue depends par= tly on all of the packets in the queue being roughly the same size. While pa= ckets from codecs are something like 20-40 bytes, signaling messages, especi= ally SIP, can get very long and would require segmentation. If they are in t= he 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 signali= ng packets than for speech packets. While discard of speech packets is norma= l and expected under overload (queue overflow), signaling packets must not b= e discarded.

Mike Pierce
--part1_194.293a358c.2de8017b_boundary-- --===============1472179714== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============1472179714==-- From tsvwg-bounces@ietf.org Fri May 28 09:24:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29413 for ; Fri, 28 May 2004 09:24:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BThLx-0006Y3-2C for tsvwg-archive@ietf.org; Fri, 28 May 2004 09:24:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BThKp-00065b-00 for tsvwg-archive@ietf.org; Fri, 28 May 2004 09:23:45 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BThJj-0005J5-00; Fri, 28 May 2004 09:22:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTgud-0005NE-Qs; Fri, 28 May 2004 08:56:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTgJF-0004Pq-V3 for tsvwg@megatron.ietf.org; Fri, 28 May 2004 08:18:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24169 for ; Fri, 28 May 2004 08:17:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BTgJF-0002e8-Aw for tsvwg@ietf.org; Fri, 28 May 2004 08:18:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTgID-0002Cf-00 for tsvwg@ietf.org; Fri, 28 May 2004 08:16:58 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BTgH7-0001NU-00 for tsvwg@ietf.org; Fri, 28 May 2004 08:15:49 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4SCFCD16896; Fri, 28 May 2004 08:15:12 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KJ4M3YC6; Fri, 28 May 2004 08:15:11 -0400 Received: from KCHAN-2K3.nortelnetworks.com (kchan-2k3.us.nortel.com [47.16.72.116]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCN0JDKS; Fri, 28 May 2004 08:15:09 -0400 Message-Id: <6.0.3.0.0.20040528075803.04e3bb70@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 28 May 2004 08:15:08 -0400 To: Mpierce1@aol.com From: Kwok Ho Chan Subject: Re: [Tsvwg] draft-baker-diffserv-basic-classes-02 In-Reply-To: <194.293a358c.2de8017b@aol.com> References: <194.293a358c.2de8017b@aol.com> Mime-Version: 1.0 Cc: Jozef Babiarz , khchan@nortelnetworks.com, tsvwg@ietf.org, Fil.Dickinson@optus.com.au X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0098079602==" Sender: tsvwg-bounces@ietf.org Errors-To: tsvwg-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --===============0098079602== Content-Type: multipart/alternative; boundary="=====================_2545199==.ALT" --=====================_2545199==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 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@aol.com wrote: >In a message dated 5/27/2004 9:07:27 AM Eastern Standard Time, >babiarz@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@ietf.org >https://www1.ietf.org/mailman/listinfo/tsvwg --=====================_2545199==.ALT Content-Type: text/html; charset="us-ascii" 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@aol.com wrote:
In a message dated 5/27/2004 9:07:27 AM Eastern Standard Time, babiarz@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@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg
--=====================_2545199==.ALT-- --===============0098079602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg --===============0098079602==--