Section 17. Relations to Other Specifications

17.1.  RTP
   The Real-Time Transport Protocol, RTP [RFC3550], is currently used
   over UDP by many of DCCP's target applications (for instance,
   streaming media).  Therefore, it is important to examine the
   relationship between DCCP and RTP and, in particular, the question of
   whether any changes in RTP are necessary or desirable when it is
   layered over DCCP instead of UDP.
   There are two potential sources of overhead in the RTP-over-DCCP
   combination: duplicated acknowledgement information and duplicated
   sequence numbers.  Together, these sources of overhead add slightly
   more than 4 bytes per packet relative to RTP-over-UDP, and
   eliminating the redundancy would not reduce the overhead.
   First, consider acknowledgements.  Both RTP and DCCP report feedback
   about loss rates to data senders, via RTP Control Protocol Sender and
   Receiver Reports (RTCP SR/RR packets) and via DCCP acknowledgement
   options.  These feedback mechanisms are potentially redundant.
   However, RTCP SR/RR packets contain information not present in DCCP
   acknowledgements, such as "interarrival jitter", and DCCP's
   acknowledgements contain information not transmitted by RTCP, such as
   the ECN Nonce Echo.  Neither feedback mechanism makes the other
   redundant.
   Sending both types of feedback need not be particularly costly
   either.  RTCP reports may be sent relatively infrequently: once every
   5 seconds on average, for low-bandwidth flows.  In DCCP, some
   feedback mechanisms are expensive -- Ack Vector, for example, is
   frequent and verbose -- but others are relatively cheap: CCID 3
   (TFRC) acknowledgements take between 16 and 32 bytes of options sent
   once per round-trip time.  (Reporting less frequently than once per
   RTT would make congestion control less responsive to loss.)  We
   therefore conclude that acknowledgement overhead in RTP-over-DCCP
   need not be significantly higher than for RTP-over-UDP, at least for
   CCID 3.
   One clear redundancy can be addressed at the application level.  The
   verbose packet-by-packet loss reports sent in RTCP Extended Reports
   Loss RLE Blocks [RFC3611] can be derived from DCCP's Ack Vector
   options.  (The converse is not true, since Loss RLE Blocks contain no
   ECN information.)  Since DCCP implementations should provide an API
   for application access to Ack Vector information, RTP-over-DCCP
   applications might request either DCCP Ack Vectors or RTCP Extended
   Report Loss RLE Blocks, but not both.
   Now consider sequence number redundancy on data packets.  The
   embedded RTP header contains a 16-bit RTP sequence number.  Most data
   packets will use the DCCP-Data type; DCCP-DataAck and DCCP-Ack
   packets need not usually be sent.  The DCCP-Data header is 12 bytes
   long without options, including a 24-bit sequence number.  This is 4
   bytes more than a UDP header.  Any options required on data packets
   would add further overhead, although many CCIDs (for instance, CCID
   3, TFRC) don't require options on most data packets.
   The DCCP sequence number cannot be inferred from the RTP sequence
   number since it increments on non-data packets as well as data
   packets.  The RTP sequence number cannot be inferred from the DCCP
   sequence number either [RFC3550].  Furthermore, removing RTP's
   sequence number would not save any header space because of alignment
   issues.  We therefore recommend that RTP transmitted over DCCP use
   the same headers currently defined.  The 4 byte header cost is a
   reasonable tradeoff for DCCP's congestion control features and access
   to ECN.  Truly bandwidth-starved endpoints should use some header
   compression scheme.
17.2.  Congestion Manager and Multiplexing
   Since DCCP doesn't provide reliable, ordered delivery, multiple
   application sub-flows may be multiplexed over a single DCCP
   connection with no inherent performance penalty.  Thus, there is no
   need for DCCP to provide built-in support for multiple sub-flows.
   This differs from SCTP [RFC2960].
   Some applications might want to share congestion control state among
   multiple DCCP flows that share the same source and destination
   addresses.  This functionality could be provided by the Congestion
   Manager [RFC3124], a generic multiplexing facility.  However, the CM
   would not fully support DCCP without change; it does not gracefully
   handle multiple congestion control mechanisms, for example.