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

[Damon Lanphear <damonlan@real.com>]

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/