Re: [dcp] Issues with adoption of DCCP for RTP applications

Damon Lanphear <damonlan@real.com> Tue, 18 June 2002 19:13 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01198 for <dcp-archive@odin.ietf.org>; Tue, 18 Jun 2002 15:13:10 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08026 for dcp-archive@odin.ietf.org; Tue, 18 Jun 2002 15:13:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07965; Tue, 18 Jun 2002 15:12:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07940 for <dcp@optimus.ietf.org>; Tue, 18 Jun 2002 15:12:23 -0400 (EDT)
Received: from wullbinkle.real.com (wullbinkle.real.com [207.188.22.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01145 for <dcp@ietf.org>; Tue, 18 Jun 2002 15:11:44 -0400 (EDT)
Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id g5IJAMKR030158; Tue, 18 Jun 2002 12:10:22 -0700
Received: from turnip ([172.23.103.232]) by real.com (8.12.2/8.12.2) with SMTP id g5IJAUMB006198; Tue, 18 Jun 2002 12:10:31 -0700
Message-Id: <3.0.32.20020618121042.00dbbbd8@mail.real.com>
X-Sender: damonlan@mail.real.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 18 Jun 2002 12:10:43 -0700
To: Eddie Kohler <kohler@icir.org>
From: Damon Lanphear <damonlan@real.com>
Subject: Re: [dcp] Issues with adoption of DCCP for RTP applications
Cc: dcp@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: dcp-admin@ietf.org
Errors-To: dcp-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Datagram Control Protocol <dcp.ietf.org>
X-BeenThere: dcp@ietf.org

Eddie,

At 09:03 AM 6/18/2002 -0700, Eddie Kohler wrote:
>Will you be in Yokohama?

	I will be in Yokohama.

>Summary: I think you're right -- the apparent redundancies are justifiable
>-- yet we might want to reconcile redundancies between DCCP and RTP anyway.
...
>All of these seem like second-level concerns. Assuming TFRC-like congestion
>control, the "extra" overhead of RTP-over-DCCP compared to RTP-over-UDP can
>be as low as 4 bytes per data packet. It might be useful to work together
>on an optimized header combination for RTP-over-DCCP, if other people are
>excited. But I'd like to support the unoptimized header combination too,
>for simplicity's sake.

	An umoptimized header combination will yeild a more elegant design. It
would be nice not to have us end up with an API that requires an extra
system call per packet on both the sender or receiver to optionally
discover the packet's sequence number, or forces a special DCCP framing of
data passed to/from userspace.  
	I am curious to see what the RTP crowd thinks about trading a 4 byte
overhead for a simplified API to DCCP.  I'll see what kind of discussion I
can drum up on the RTP/AVT list. 

>Likewise, receiver reports in RTP might piggyback on DCCP's when possible.
>In the TFRC case, RTP would turn on RTP-level receiver reports, while RTP
>might use DCCP's acks for TCP-like congestion control, which has complete
>ack information. The particular mechanism chosen for receiver reports might
>be hidden from the application. (I'm not sure you could hide the sequence
>number differences.)

	My personal thoughts on this issue are such that the sampling and
interpretation of data in RTCP RR's is highly specialized to a particular
problem domain. This means that RTCP RR's would have to be extended to
support something like TFRC, incurring more overhead by virtue of the
increased frequency and size of RTCP RR's.  It would be optimal to let TFRC
under DCCP handle the receiver reporting required of TFRC, and let RTCP
stay constrained to its problem space of real-time metric reporting.


_______________________________________________
dcp mailing list: dcp@ietf.org
archives: https://www1.ietf.org/mailman/listinfo/dcp
project: http://www.icir.org/kohler/dcp/