[dcp] Issues with adoption of DCCP for RTP applications

	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
dcp@ietf.org
https://www1.ietf.org/mailman/listinfo/dcp