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

From: Damon Lanphear <[email-masked]>
Date: Fri, 14 Jun 2002 08:13:46 -0700

A potential issue for the adoption of DCCP for RTP applications is the
redundant use of data in the two protocol layers.  Both DCCP and RTP place
a sequence number in the data packet header, and both DCCP and RTP employ a
receiver report mechanism.  The receiver report mechanism, in the RTP case,
can be extended to transmit the same data as would be placed in a
DCCP-style feedback packet. 
	It is important to be clear about how the "redundant" data is actually
used by both DCCP and RTP.  Both DCCP and RTP use sequence numbers to
detect packet loss.  For RTP applications, sequence numbers may be used to
establish frame ordering, to perform ARQ in a time sensitive way, and to
compute loss metrics that have relevance to the overlying application.  RTP
must therefore make the sequence number known to the overlying application
in order to support such features, whereas DCCP does not.  Simply stated,
the problem domains of DCCP and RTP are sufficiently different that the
redundancy of the sequence number datum may be justifiable.
	The same principle is applicable to the issue of redundant information in
receiver reports.  In both DCCP and RTP the form of receiver reports is
reasonably flexible.  There is a clear separation between RTP and DCCP of
the application's concerns and the concerns of a congestion control
mechanism, respectively.  This seperation assists in maintaining the
respective protocols appropriateness for a variety of applications.
	 What are the group's thoughts on these issues?  Are they seemingly moot
as my current line of thinking implies, or ought we work to reconcille such
redundancies?  

damon   

_______________________________________________
dcp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dcp

---

From: "Andrei Gurtov" <[email-masked]>
Date: Tue, 18 Jun 2002 10:59:35 +0300

I agree that issues of running RTP over DCCP need to be resolved. If DCCP is
to gain wide acceptance it should allow applications to utilize numerious
payload profiles built around RTP. Additionally, there are nice RTP
extensions like SR-RTP providing messaging (application data unit)
transport, selective reliability and timeliness. I think integration of DCCP
with RTP should be included explicitly into the requirements draft.

Andrei

----- Original Message -----
From: "Damon Lanphear" <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 14, 2002 6:13 PM
Subject: [dcp] Issues with adoption of DCCP for RTP applications

_______________________________________________
dcp mailing list: [email-masked]
archives: https://www1.ietf.org/mailman/listinfo/dcp
project: http://www.icir.org/kohler/dcp/

---

From: Eddie Kohler <[email-masked]>
Date: Tue, 18 Jun 2002 09:03:28 -0700

Hi Damon,

> 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