Re: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt

a a <yourf@yahoo.com> Tue, 10 February 2004 18:17 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00921 for <avt-archive@odin.ietf.org>; Tue, 10 Feb 2004 13:17:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcRY-0005GF-2L for avt-archive@odin.ietf.org; Tue, 10 Feb 2004 13:17:08 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AIH83b020204 for avt-archive@odin.ietf.org; Tue, 10 Feb 2004 13:17:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcRR-0005Ey-Be; Tue, 10 Feb 2004 13:17:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcQY-0005Dv-OL for avt@optimus.ietf.org; Tue, 10 Feb 2004 13:16:06 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00858 for <avt@ietf.org>; Tue, 10 Feb 2004 13:16:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqcQW-0005YK-00 for avt@ietf.org; Tue, 10 Feb 2004 13:16:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqcPb-0005Sf-00 for avt@ietf.org; Tue, 10 Feb 2004 13:15:08 -0500
Received: from web41415.mail.yahoo.com ([66.218.93.81]) by ietf-mx with smtp (Exim 4.12) id 1AqcP7-0005MC-00 for avt@ietf.org; Tue, 10 Feb 2004 13:14:37 -0500
Message-ID: <20040210181406.10680.qmail@web41415.mail.yahoo.com>
Received: from [209.246.224.110] by web41415.mail.yahoo.com via HTTP; Tue, 10 Feb 2004 10:14:06 PST
Date: Tue, 10 Feb 2004 10:14:06 -0800
From: a a <yourf@yahoo.com>
Subject: Re: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
To: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>, avt@ietf.org
Cc: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>

Hi,

It looks pretty good. I have a question rather than a
comment:

In this draft we are trying to add some new objects to
the base RSVP-TE. RSVP or RSVP-TE so far have been
kept immune from the applications that could make use
of it. So, why are we planning to add something like
"VoIP-CallIds" instead of some generic name or
identifier that could be used by different
applications in different contexts? The L3PID anyway
would define the kind of the payload being carried and
applications would be free to interpret that "generic
identifier" in the fashion they want. (Pls. excuse me
if I'm not privy to some information or earlier
discussions).

Today we have SIP (in VoIP networks) and that's why
usage of VoIP-CallIds may be justified in some sense
but tomorrow there could be some other protocol (that
may use some other identifier instead of callId) and
hence we may have to accomodate that as well.

The other minor comments that I have are:
* Though the draft states that packet type field would
be prepended to the "packet formats" defined in ECRTP
(RFC3545), a pictoral representation would be useful.

* Most of the SIP RFCs and SIP drafts have associated
example "Call Flows" with DETAILED message contents -
either in separate drafts/RFCs or in Appendix sections
to the main RFC/drafts. Can we do something similar
for this draft as well? (It has some message seuqence
shown but it's not that detailed). It would be useful
to see the data plane encodings as well (with label
stacks, packet types and compressed payloads etc.).

Thanks.




--- "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
wrote:
> All,
> 
> Please review and comment on 'Protocol Extensions
> for ECRTP over MPLS'
>
http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-00.txt.
>  The protocol extensions enable the use of MPLS to
> route enhanced compressed RTP (ECRTP) compressed
> packets over an MPLS LSP without
> compression/decompression cycles at each router.
> 
> The proposed extensions are based on the
> requirements documented in 'Requirements for ECRTP
> over MPLS'
>
http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-reqs-01.txt.
> 
> Thanks,
> Jerry
> 
> -----Original Message-----
> From: Internet-Drafts@ietf.org
> [mailto:Internet-Drafts@ietf.org]
> Sent: Thursday, February 05, 2004 3:43 PM
> Subject: I-D
> ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
> 
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> 
> 
> 	Title		: Protocol Extensions for ECRTP over MPLS
> 	Author(s)	: J. Ash
> 	Filename	:
> draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
> 	Pages		: 0
> 	Date		: 2004-2-5
> 	
> VoIP typically uses the encapsulation
> voice/RTP/UDP/IP. When MPLS labels 
> are added, this becomes
> voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, 
> the packet header is at least 48 bytes, while the
> voice payload is often 
> no more than 30 bytes, for example. VoIP header
> compression can 
> significantly reduce the VoIP overhead through
> various compression 
> mechanisms, such as enhanced compressed RTP (ECRTP).
> We consider using 
> MPLS to route ECRTP compressed packets over an MPLS
> LSP without 
> compression/decompression cycles at each router.
> Such an ECRTP over MPLS 
> capability can increase the bandwidth efficiency as
> well as processing 
> scalability of the maximum number of simultaneous
> VoIP flows that use 
> header compression at each router.  In this draft we
> propose to use 
> RSVP-TE extensions to signal the header compression
> context and other 
> control messages between the ingress and egress LSR.
>  We re-use the 
> methods in ECRTP to determine the context.
> 
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-00.txt.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt


__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt