IETF Logo Mail Archive

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

Eddie Kohler <kohler@icir.org> Tue, 18 June 2002 16:05 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 MAA24501 for <dcp-archive@odin.ietf.org>; Tue, 18 Jun 2002 12:05:22 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26510 for dcp-archive@odin.ietf.org; Tue, 18 Jun 2002 12:06:00 -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 MAA26420; Tue, 18 Jun 2002 12:04:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26375 for <dcp@optimus.ietf.org>; Tue, 18 Jun 2002 12:04:25 -0400 (EDT)
Received: from coyote.icir.org (coyote.icir.org [192.150.187.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24405 for <dcp@ietf.org>; Tue, 18 Jun 2002 12:03:46 -0400 (EDT)
Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.11.6/8.11.3) with ESMTP id g5IG3S601787; Tue, 18 Jun 2002 09:03:29 -0700 (PDT) (envelope-from kohler@coyote.icir.org)
Message-Id: <200206181603.g5IG3S601787@coyote.icir.org>
To: Damon Lanphear <damonlan@real.com>
cc: dcp@ietf.org
Subject: Re: [dcp] Issues with adoption of DCCP for RTP applications
In-Reply-To: Message from Damon Lanphear <damonlan@real.com> of "Fri, 14 Jun 2002 08:13:46 PDT." <3.0.32.20020614081346.00e1d9f0@mail.real.com>
Date: Tue, 18 Jun 2002 09:03:28 -0700
From: Eddie Kohler <kohler@icir.org>
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

Hi Damon,

> 	A potential issue for the adoption of DCCP for RTP applications is the
> redundant use of data in the two protocol layers.  ...

We've discussed that issue a little bit, and it is worth discussing more.
Will you 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.

We originally thought about a modified RTP header for the RTP-over-DCCP
combination. This new header might lose the sequence number, piggybacking
on DCCP's sequence numbers. We expect any DCCP API to, for example:

  1. Let the sender discover the sequence number used for a sent datagram.
  2. Let the receiver discover the sequence number attached to a received
datagram.
  3. Let the sender determine whether or not a specific sequence number was
acknowledged. (This gets complicated, of course, for CCIDs like TFRC, where
precise ack information is not available.)

This information might let you detect reordering, detect loss, and so
forth. (I don't know enough about RTP to say for sure.)

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.)

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.

Eddie

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

v2.23.0 | Report a Bug | By Email