RE: [AVT] I-D ACTION:draft-ietf-avt-tcrtp-08.txt

"Dan Wing" <dwing@cisco.com> Tue, 21 September 2004 22:21 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08115 for <avt-archive@ietf.org>; Tue, 21 Sep 2004 18:21:43 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9t7P-0008UD-K2 for avt-archive@ietf.org; Tue, 21 Sep 2004 18:28:26 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9suJ-0002sU-4U; Tue, 21 Sep 2004 18:14:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9skO-0004jz-6V for avt@megatron.ietf.org; Tue, 21 Sep 2004 18:04:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04853 for <avt@ietf.org>; Tue, 21 Sep 2004 18:04:25 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9sqp-0007nr-1j for avt@ietf.org; Tue, 21 Sep 2004 18:11:08 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 21 Sep 2004 15:09:00 -0700
X-BrightmailFiltered: true
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8LM2xbs002064; Tue, 21 Sep 2004 15:03:53 -0700 (PDT)
Received: from DWINGW2K4 (sjc-vpn5-263.cisco.com [10.21.89.7]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA21902; Tue, 21 Sep 2004 15:02:57 -0700 (PDT)
From: Dan Wing <dwing@cisco.com>
To: Yaakov Stein <yaakov_s@rad.com>, avt@ietf.org
Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-tcrtp-08.txt
Date: Tue, 21 Sep 2004 15:02:57 -0700
Message-ID: <LIECKHBKICJFBLOMPHNMIEKNNAAA.dwing@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5203063C17@exrad2.ad.rad.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: Bruce Thompson <brucet@cisco.com>, Tmima Koren <tmima@cisco.com>
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
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>
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit

> While I completely agree with the motivation behind this draft,
> I have problems with the proposed technique.
>
> In section 1.1 we find:
>
>    While some voice-over-packet technologies such as Voice over
>    ATM (VoAAL2, [I.363.2]) and Voice over MPLS provide bandwidth
>    efficiencies because both technologies lack IP, UDP, and RTP
>    headers, neither VoATM nor VoMPLS provide direct access to voice-
>    over-packet services available to Voice over IP.
>
> The savings of VoATM and VoMPLS (and now ITU Y.1414) are mainly
> due to multiplexing multiple channels into a packet with a single
> header, and not merely to not having the RTP/UDP/IP headers.

ATM's multiplexing only helps significantly if you can take
advantage of it, which requires chosing a codec and packetization
interval the fit into the user payload, and requires multiple streams
terminating on the same VPI/VCI.

> Indeed, the significance of the overhead diminishes with the number
> of multiplexed channels.
>
> So to solve the efficiency problem we need a simple method to multiplex
> multiple
> channels into a single packet, such as the mechanisms specified in
> Y.1414.
>
> The TCRTP draft indeed uses standard mechanisms to multiplexing
> channels,
> but, its mechanisms are needlessly complex
> (compression techniques to reduce the overhead, then PPP muxing to
> combine them,
> then placing the resulting stream into an L2TP tunnel, and then
> performing a further
> header compression on the L2TP/IP headers).
>
> Why should we go to such lengths when much simpler mechanisms can be
> used?

We needed a compression technique that saved bandwidth even in the absence
of multiplexing -- such as a branch office doing VoIP with a single user.

-d

> Y(J)S
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt


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