draft-ott-avt-rtcp-guidelines-00.txt   draft-ott-avt-rtcp-guidelines-01.txt 
AVT Working Group J. Ott AVT Working Group J. Ott
Internet-Draft Helsinki University of Technology Internet-Draft Helsinki University of Technology
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: August 21, 2008 University of Glasgow Expires: December 14, 2008 University of Glasgow
February 18, 2008 June 12, 2008
Guidelines for Extending the RTP Control Protocol (RTCP) Guidelines for Extending the RTP Control Protocol (RTCP)
draft-ott-avt-rtcp-guidelines-00.txt draft-ott-avt-rtcp-guidelines-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2008. This Internet-Draft will expire on December 14, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The RTP Control Protocol (RTCP) is used along with the Real-time The RTP Control Protocol (RTCP) is used along with the Real-time
Transport Protocol (RTP) to provide a control channel between media Transport Protocol (RTP) to provide a control channel between media
senders and receivers. This allows constructing a feedback loop to senders and receivers. This allows constructing a feedback loop to
skipping to change at page 2, line 13 skipping to change at page 2, line 13
provides guidelines on extending RTCP if those basic mechanisms prove provides guidelines on extending RTCP if those basic mechanisms prove
insufficient. insufficient.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RTP and RTCP Operation Overview . . . . . . . . . . . . . . . 4 3. RTP and RTCP Operation Overview . . . . . . . . . . . . . . . 4
3.1. RTCP Capabilities . . . . . . . . . . . . . . . . . . . . 5 3.1. RTCP Capabilities . . . . . . . . . . . . . . . . . . . . 5
3.2. RTCP Limitations . . . . . . . . . . . . . . . . . . . . . 7 3.2. RTCP Limitations . . . . . . . . . . . . . . . . . . . . . 7
4. Issues with RTCP Extensions . . . . . . . . . . . . . . . . . 7 4. Issues with RTCP Extensions . . . . . . . . . . . . . . . . . 8
5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] is used to carry The Real-time Transport Protocol (RTP) [RFC3550] is used to carry
time-dependent (often continuous) media such as audio or video across time-dependent (often continuous) media such as audio or video across
a packet network in an RTP session. RTP usually runs on top of an a packet network in an RTP session. RTP usually runs on top of an
unreliable transport such as UDP, DTLS, or DCCP, so that RTP packets unreliable transport such as UDP, DTLS, or DCCP, so that RTP packets
are susceptible to loss, re-ordering, or duplication. Associated are susceptible to loss, re-ordering, or duplication. Associated
with RTP is the RTP Control Protocol (RTCP) which provides a control with RTP is the RTP Control Protocol (RTCP) which provides a control
channel for each session: media senders provide information about channel for each session: media senders provide information about
skipping to change at page 4, line 39 skipping to change at page 4, line 39
In this section, we will briefly review what is available from the In this section, we will briefly review what is available from the
basic RTP/RTCP specifications. As specifications, we include those basic RTP/RTCP specifications. As specifications, we include those
which are generic, i.e., do not have dependencies on particular media which are generic, i.e., do not have dependencies on particular media
types. This includes the RTP base specification [RFC3550] and types. This includes the RTP base specification [RFC3550] and
profile [RFC3551], the RTCP bandwidth modifiers for session profile [RFC3551], the RTCP bandwidth modifiers for session
descriptions [RFC3556], the timely feedback extensions (RFC 4585), descriptions [RFC3556], the timely feedback extensions (RFC 4585),
and the extensions to run RTCP over SSM networks. RTCP XR [RFC3611] and the extensions to run RTCP over SSM networks. RTCP XR [RFC3611]
provides extended reporting mechanisms which are partly generic in provides extended reporting mechanisms which are partly generic in
nature, partly specific to a certain media stream. nature, partly specific to a certain media stream.
We do not cover other RTP-related documents: SRTP [RFC3711] is We do not discuss RTP-related documents that are orthogonal to RTCP.
orthogonal as is the mapping of RTP/RTCP to other transports (such as The Secure RTP Profile [RFC3711] can be used to secure RTCP in much
RFC 4571). The description of RTP topologies is useful knowledge the same way it secures RTP data, but otherwise does not affect the
(RFC 5117) but functionally not relevant here. Various RTP error behaviour of RTCP. The transport protocol used also has little
control mechanisms (such as RFC 2198, RFC 2733, RFC 4588, and RFC impact, since RTCP remains a group communication protocol even when
5109) are useful mechanisms for RTP packets, some of which may be running over a unicast transport (such as TCP [RFC4571] or DCCP
worthwhile for RTCP if appropriate. [I-D.ietf-dccp-rtp]), and is little affected by congestion control
due to its low rate relative to the media. The description of RTP
topologies [RFC5117] is useful knowledge, but is functionally not
relevant here. The various RTP error correction mechanisms (e.g.
[RFC2198], [RFC2733], [RFC4588], [RFC5109]) are useful for protecting
RTP media streams, and may be enabled as a result of RTCP feedback,
but do not directly affect RTCP behaviour.
3.1. RTCP Capabilities 3.1. RTCP Capabilities
The RTP/RTCP specifications quoted above provide feedback mechanisms The RTP/RTCP specifications quoted above provide feedback mechanisms
with the following properties, which can be considered as "building with the following properties, which can be considered as "building
blocks" for adaptive real-time applications for IP networks. blocks" for adaptive real-time applications for IP networks.
o Sender Reports (SR) indicate to the receivers the total number of o Sender Reports (SR) indicate to the receivers the total number of
packets and octets have been sent (since the beginning of the packets and octets have been sent (since the beginning of the
session or the last change of the sender's SSRC). These values session or the last change of the sender's SSRC). These values
allow deducing the mean data rate and mean packet size for both allow deducing the mean data rate and mean packet size for both
the entire session and, if continuously monitored, for every the entire session and, if continuously monitored, for every
transmission interval. transmission interval. They also allow a receiver to distinguish
between breaks in reception caused by network problems, and those
due to pauses in transmission.
o Receiver Reports (RR) and SRs indicate reception statistics from o Receiver Reports (RR) and SRs indicate reception statistics from
each receiver for every sender. These statistics include: each receiver for every sender. These statistics include:
* The packet loss rate since the last SR or RR was sent. * The packet loss rate since the last SR or RR was sent.
* The total number of packets lost since the beginning of the * The total number of packets lost since the beginning of the
session which may again be broken down to each reporting session which may again be broken down to each reporting
period. period.
* The highest sequence number received so far -- which allows a * The highest sequence number received so far -- which allows a
sender to roughly estimate how much data is in flight when used sender to roughly estimate how much data is in flight when used
together with the SR and RR timestamps (and also allows together with the SR and RR timestamps (and also allows
observing whether the path still works and at which rate observing whether the path still works and at which rate
packets are delivered to the receiver). packets are delivered to the receiver).
* The moving average of the inter-arrival jitter of media * The moving average of the inter-arrival jitter of media
packets. packets. This gives the sender an indirect view of the size of
o These values are sampled in "regular" interval 0.5 ... 1.5 times any adaptive playout buffer used at the receiver ([RFC3611]
the deterministic calculated interval T. For sessions with a gives precise figures for VoIP sessions).
constant number of RTP entities, T will remain stable and timer o Sender Reports also contain NTP and RTP format timestamps. These
reconsideration will not have any effect. T is determined by the allow receivers to synchronise multiple RTP streams, and (when
media bit rate, the mean RTCP packet size, whether the sampling used in conjunction with Receiver Reports) allow the sender to
node is a sender or a receiver, and its respective bitrate budget. calculate the current RTT to each receiver. This value can be
T has a lower limit of 5s per [RFC3550] (although this may be monitored over time and thus may be used to infer trends at coarse
scaled to 360 seconds divided by the session bandwidth in granularity. A similar mechanism is provided by [RFC3611] to
kilobits/second in some circumstances, giving an interval smaller allow receivers to calculate the RTT to senders.
than 5 seconds for bandwidths greater than 72 kb/s).
o The lower limit can be eliminated and more frequent feedback can
be provided when using the early feedback profile for RTCP (RFC
4585). In this case, the RTCP frequency is only limited by the
available bitrate (usually 5% of the media stream bit rate is
allocated for RTCP). If this is insufficient, the RTCP bitrate
may be increased in the session description to enable more
frequent feedback (RFC 3556). (Work in progress suggests to
reduce the mean RTCP packet size [I-D.ietf-avt-rtcp-non-compound]
which may help increasing the feedback frequency further.)
o RFC 4585 even allows -- statistically -- to provide close-to-
instant feedback from a receiver to a sender about any observed
event in the media stream.
o Sender Reports also contain timestamps which allow (in conjunction RTCP sender reports and receiver reports are sent, and the statistics
with Receiver Reports) the sender to calculate the current RTT. are sampled, at random intervals chosen uniformly in the range 0.5
This value can be monitored over time and thus may be used to ... 1.5 times the deterministic calculated interval, T. The interval
infer trends at coarse granularity. RFC 3611 provides a similar T is calculated based on the media bit rate, the mean RTCP packet
RTT mechanism for the receivers. size, whether the sampling node is a sender or a receiver, and the
o RTCP is suitable for unicast and multicast communications and all number of participants in the session, and will remain constant while
basic functions are designed with group communications in mind. the number of participants in the session remains constant. The
While traditional (any-source) multicast (ASM) is clearly not lower bound on the base inter-report interval, T, is five seconds, or
available in the Internet at large, source-specific multicast 360 seconds divided by the session bandwidth in kilobits/second
(SSM) and overlay multicast are -- and both are commercially (giving an interval smaller than 5 seconds for bandwidths greater
relevant. RTCP extensions have been defined to operate over SSM, than 72 kb/s) [RFC3550].
and complex topologies may be created by interconnecting RTP
mixers and translators. This lower limit can be eliminated, allowing more frequent feedback,
when using the early feedback profile for RTCP [RFC4585]. In this
case, the RTCP frequency is only limited by the available bitrate
(usually 5% of the media stream bit rate is allocated for RTCP). If
this fraction is insufficient, the RTCP bitrate may be increased in
the session description to enable more frequent feedback [RFC3556].
Ongoing work [I-D.ietf-avt-rtcp-non-compound] may reduce the mean
RTCP packet size, further increasing feedback frequency.
The mechanisms defined in [RFC4585] even allow -- statistically -- a
receiver to provide close-to-instant feedback to a sender about
observed events in the media stream (e.g. picture or slice loss).
RTCP is suitable for unicast and multicast communications. All basic
functions are designed with group communications in mind. While
traditional (any-source) multicast (ASM) is clearly not available in
the Internet at large, source-specific multicast (SSM) and overlay
multicast are -- and both are commercially relevant. RTCP extensions
have been defined to operate over SSM, and complex topologies may be
created by interconnecting RTP mixers and translators. The group
communication nature of RTP and RTCP is also essential for the
operation of Multipoint Conference Units.
These mechanisms can used to implement a quite flexible feedback loop These mechanisms can used to implement a quite flexible feedback loop
and enable short-term reaction to observed events as well as long and enable short-term reaction to observed events as well as long
term adaptation to changes in the networking environment. Adaptation term adaptation to changes in the networking environment. Adaptation
mechanisms available on the sender side include (but are not limited mechanisms available on the sender side include (but are not limited
to) choosing different codecs, different parameters for codecs to) choosing different codecs, different parameters for codecs
(spatial or temporal resolution for video, audible quality for audio (spatial or temporal resolution for video, audible quality for audio
and voice), and different packet sizes to adjust the bit rate. and voice), and different packet sizes to adjust the bit rate.
Furthermore, various forward error correction mechanisms and, if RTTs Furthermore, various forward error correction mechanisms and, if RTTs
are short and the application permits extra delays, even reactive are short and the application permits extra delays, even reactive
error control such as retransmissions. Long-term feedback can be error control such as retransmissions. Long-term feedback can be
provided in regular RTCP reports at configurable intervals, whereas provided in regular RTCP reports at configurable intervals, whereas
(close-to-)instant feedback is available by means of the early (close-to-)instant feedback is available by means of the early
feedback profile. Figure 1 below outlines this idea graphically: feedback profile. Figure 1 below outlines this idea graphically.
Long-term adaptation: RTCP Sender Reports Media processing: Long-term adaptation: RTCP Sender Reports Media processing:
- Codec+parameter choice - Data rate, pkt count - Dejittering - Codec+parameter choice - Data rate, pkt count - Dejittering
- Packet size - Timing and sync info - Synchronization - Packet size - Timing and sync info - Synchronization
- FEC, interleaving - Traffic characteristics - Error concealment - FEC, interleaving - Traffic characteristics - Error concealment
--------------------------------> - Playout --------------------------------> - Playout
+---------------+/ \+---------------+ +---------------+/ \+---------------+
| | RTP media stream (codec, repair) | | | | RTP media stream (codec, repair) | |
| Media Sender |=================================>| Media receiver | | Media Sender |=================================>| Media receiver |
| | | | | | | |
+---------------+\ RTCP Receiver Reports /+---------------+ +---------------+\ RTCP Receiver Reports /+---------------+
<-------------------------------- <--------------------------------
Short-term reaction: - long-term statistics Control functions: Short-term reaction: - long-term statistics Control functions:
- Retransmissions - event information - RTP monitoring - Retransmissions - event information - RTP monitoring
- Retro-active FEC - media-specific info and reporting - Retro-active FEC - media-specific info and reporting
- Adaptive source coding - "congestion info"(*) - Instant event - Adaptive source coding - "congestion info"(*) - Instant event
- Congestion control(*) notifications - Congestion control(*) notifications
(*) RTCP feedback has been seen as insufficient for congestion control (*) RTCP feedback is insufficient for TCP-Friendly congestion control
purposes due to the infrequent nature of reporting (which should purposes due to the infrequent nature of reporting (which should
be in the order of once per RTT). be in the order of once per RTT), but can still be used to adapt
to the available bandwidth on slower timescales.
Figure 1: Outline of an RTCP Feedback Loop Figure 1: Outline of an RTCP Feedback Loop
It is important to note that not all information needs to be It is important to note that not all information needs to be
signalled explicitly -- ever or upon every RTCP packet -- but can be signalled explicitly -- ever or upon every RTCP packet -- but can be
derived locally from other pieces of information and from the derived locally from other pieces of information and from the
evolution of the information over time. evolution of the information over time.
3.2. RTCP Limitations 3.2. RTCP Limitations
The design of RTP limits what can meaningfully be done (and hence The design of RTP limits what can meaningfully be done (and hence
should be done) with RTCP. In particular, the design favours should be done) with RTCP. In particular, the design favours
scalability and loose coupling over tightly controlled feedback scalability and loose coupling over tightly controlled feedback
loops. Some of these limitations are listed below (they need to be loops. Some of these limitations are listed below (they need to be
taken into account when designing extensions): taken into account when designing extensions):
o One response per media packet. RTCP is designed to provide o RTCP is designed to provide occasional feedback which is unlike,
occasional feedback which is unlike, e.g., TCP ACKs which can be e.g., TCP ACKs which can be sent in response to every (other)
sent in response to every (other) packet. packet. It does not offer per-packet feedback (even when using
[RFC4585] with increased RTCP bandwidth fraction, the feedback
guarantees are only statistical in nature).
o RTCP is not capable of providing truly instant feedback. o RTCP is not capable of providing truly instant feedback.
o RTCP is inherently unreliable. o RTCP is inherently unreliable, and does not guarantee any
consistency between the observed state at multiple members of a
group.
It is important to note that these features of RTCP are intentional
design choices, and are essential for it to scale to large groups.
4. Issues with RTCP Extensions 4. Issues with RTCP Extensions
Issues that came up in the past with extensions to RTP and RTCP Issues that have come up in the past with extensions to RTP and RTCP
include (but are probably not limited to) the following: include (but are probably not limited to) the following:
o Defined only or primarily for unicast. RTCP has been defined for o Defined only or primarily for unicast two-party sessions. RTP is
multicast. Extensions may become useful in the future well inherently a group communication protocol, even when operating on
outside their originally intended area of application and should a unicast connection. Extensions may become useful in the future
consider this. Stating that something works for unicast only is well outside their originally intended area of application, and
not an option in many cases, particularly as various flavours of should consider this. Stating that something works for unicast
multicast have become relevant again. only is not acceptable, particularly since various flavours of
multicast have become relevant again, and as middleboxes such as
repair servers, mixers, and RTCP-supporting MCUs [RFC5117] become
more widely used.
o Assuming reliable (instant) state synchronization. RTCP reports o Assuming reliable (instant) state synchronization. RTCP reports
are sent irregularly and may be lost. Hence, there may be a are sent irregularly and may be lost. Hence, there may be a
significant time lag between intending to send a state update to significant time lag (several seconds) between intending to send a
the RTP peer(s) and the packet being received, in some cases, the state update to the RTP peer(s) and the packet being received, in
packet may not be received at all. some cases, the packet may not be received at all.
o Reliable RTCP. Where needed, reliability is implemented on top of o Requiring reliable delivery of RTCP reports. While reliability
RTCP using acknowledgements. While acknowledgements and can be implemented on top of RTCP using acknowledgements, this
retransmission suggest to overcome the above reliability issue will come at the cost of significant additional delay, which may
(and, in fact, they probably can), this is likely to come at the defeat the purpose of providing the feedback in the first place.
cost of significant additional delay which may defeat the purpose Moreover, for scalability reasons due to the group-based nature of
of providing the feedback in the first place. Moreover, for RTCP, these ACKs need to be adaptively rate limited or targeted to
scalability reasons, if multicasting is used, these ACKs need to a subgroup or individual entity to avoid implosion as group sizes
be targeted to a subgroup or an individual entity to avoid increase. RTCP is not intended or suitable for use as a reliable
implosion. The result are typically specific mechanisms with control channel.
limited re-usability. o Commands are issued, rather than hints given. RTCP is about
o Commands are issued rather than hints given. RTCP is about
reporting observations -- in a best-effort manner -- between RTP reporting observations -- in a best-effort manner -- between RTP
entities. Causing actions on the remote side requires some form entities. Causing actions on the remote side requires some form
of reliability (see above) and adherence cannot be verified. of reliability (see above), and adherence cannot be verified.
o RTCP reporting is expanded to become a network management tool. o RTCP reporting is expanded to become a network management tool.
RTCP is sensitive to the size of RTCP reports as the latter RTCP is sensitive to the size of RTCP reports as the latter
determines the mean reporting interval given a certain bit rate determines the mean reporting interval given a certain bit rate
share for RTCP. The amount of information going into RTCP reports share for RTCP. The amount of information going into RTCP reports
should primarily target the peer (and thus include information should primarily target the peer (and thus include information
that can be meaningfully reacted upon). Gathering and reporting that can be meaningfully reacted upon). Gathering and reporting
statistics beyond this is not an RTCP task and should be addressed statistics beyond this is not an RTCP task and should be addressed
by out-of-band protocols. by out-of-band protocols.
o Serious complexity is created. Related to the previous item, RTCP o Serious complexity is created. Related to the previous item, RTCP
reports that convey all kinds of data first need to gather and reports that convey all kinds of data first need to gather and
skipping to change at page 9, line 8 skipping to change at page 9, line 18
o Architectural issues. Extensions are written without considering o Architectural issues. Extensions are written without considering
the architectural concepts of RTP. For example, point-to-point the architectural concepts of RTP. For example, point-to-point
communication is assumed, yet third party monitors are expected to communication is assumed, yet third party monitors are expected to
listen in. Besides being a bad idea to rely on eavesdropping listen in. Besides being a bad idea to rely on eavesdropping
entities on the path, this is obviously not possible if SRTP is entities on the path, this is obviously not possible if SRTP is
being used with encrypted SRTCP packets. being used with encrypted SRTCP packets.
This list is surely not exhaustive. Also, the authors do not claim This list is surely not exhaustive. Also, the authors do not claim
that the suggested extensions (even if using acknowledgements) would that the suggested extensions (even if using acknowledgements) would
not serve a legitimate purpose. We rather want to draw attention to not serve a legitimate purpose. We rather want to draw attention to
the fact that the same results may be achievable in an the fact that the same results may be achievable in a way which is
architecturally cleaner and conceptually RTP/RTCP-compliant way. The architecturally cleaner and conceptually more RTP/RTCP-compliant.
following section contains a first attempt to provide some guidelines The following section contains a first attempt to provide some
on what to consider when thinking about extensions to RTP and RTCP. guidelines on what to consider when thinking about extensions to RTP
and RTCP.
5. Guidelines 5. Guidelines
Designing RTCP extensions requires consideration of a number aspects Designing RTCP extensions requires consideration of a number issues,
as well as in-depth understanding of the operation of RTP and its as well as in-depth understanding of the operation of RTP mechanisms.
basic mechanisms. While it is expected that there are many aspects While it is expected that there are many aspects not yet covered by
not yet covered by RTCP reporting and operation, quite a bit of RTCP reporting and operation, quite a bit of functionality is readily
functionality is readily available for use. Quite a few further available for use. Other mechanisms should probably never become
mechanisms should probably never become part of the RTP family of part of the RTP family of specifications, despite the existance of
specifications. In the following, we provide a bit of guidance (in their equivalents in other environments. In the following, we
its first iteration) what to consider when (and before!) developing provide some guidance to consider when (and before!) developing an
an extension to RTCP. extension to RTCP.
Note: In this first revision of this draft, this section is still
very rough.
We begin with a short check list concerning the applicability of RTCP We begin with a short check list concerning the applicability of RTCP
in the first place: in the first place:
o Check what you can do with the existing mechanisms and exploit the o Check what can be done with the existing mechanisms, exploiting
information readily available. Is the need for an extension only the information that is already available in RTCP. Is the need
perceived (e.g., because of lazy implementers, artificial for an extension only perceived (e.g., due to lazy implementers,
constraints in endpoints) or is the function or information really or artificial constraints in endpoints), or is the function or
not available. It is worthwhile remembering that any piece of data really not available (or derivable from existing reports)?
redundant information supplied by a protocol runs the risk of It is worthwhile remembering that redundant information supplied
being inconsistent at some point and different implementation may by a protocol runs the risk of being inconsistent at some point,
choose to handle such situations differently (e.g., give and various implementation may handle such situations differently
precedence to different values). Similarly, every function should (e.g., give precedence to different values). Similarly, there
only be doable in exactly one (well-specified) way. should be exactly one (well-specified) way of performing every
o Is the extension really applicable to RTP entities running function and operation of the protocol.
anywhere in the Internet or is this a link-specific extension? In
the latter case, link-specific extensions (e.g., using header o Is the extension applicable to RTP entities running anywhere in
compression) may be preferable. RTCP should also not be used to the Internet, or is it a link- or environment-specific extension?
In the latter cases, local extensions (e.g. header compression, or
non-RTP protocols) may be preferable. RTCP should not be used to
carry information specific to a particular (access) link. carry information specific to a particular (access) link.
o Is the extension applicable in a group communication environment,
or is it specific to point-to-point communications? RTP and RTCP
are inherently group communication protocols, and extensions must
scale gracefully with increasing group sizes.
From a conceptual viewpoint, every RTCP extension should ask and From a conceptual viewpoint, the designer of every RTCP extension
answer(!) at least the following questions: should ask -- and answer(!) -- at least the following questions:
o How will this new building block complement and work with the o How will this new building block complement and work with the
others? Are all interactions specified? other components of RTCP? Are all interactions fully specified?
o Will this work with all different profiles? (Security?) Are any o Will this extension work with all different profiles (e.g. the
feature interactions expected? Secure RTP Profile [RFC3711], and the Extended RTP Profile for
o Should this extension be kept in-line with baseline RTP and the RTCP-based Feedback [RFC4585])? Are any feature interactions
existing RTP profiles? Or does the extension deviate so much from expected?
the basic operation (and the answer to the previous question is o Should this extension be kept in-line with baseline RTP and its
"no") so that a new profile should be defined which is allowed to existing profiles, or does it deviate so much from the base RTP
be incompatible with others? If so, how do nodes using different operation that an incompatible new profile must be defined? Use
profiles fail safely? and definition of incompatible profiles is strongly discouraged,
o How does this extension interoperate with other nodes if the but if they prove necessary, how do nodes using the different
profiles interact? What are the failure modes, and how is it
ensured that the system fails in a safe manner?
o How does this extension interoperate with other nodes when the
extension is not understood by the peer(s)? extension is not understood by the peer(s)?
o How will the extension deal with different networking conditions o How will the extension deal with different networking conditions
(e.g., degrade with increase in losses or latency, possibly across (e.g., how does performance degrade with increases in losses and
orders of magnitude)? latency, possibly across orders of magnitude)?
o How will this extension work with multicast? Will this degrade o How will this extension work with group communication scenarios,
gracefully with increasing group sizes? What will be the impact such as multicast? Will the extensions degrade gracefully with
on the RTCP report frequency and bitrate allocation? increasing group sizes? What will be the impact on the RTCP
report frequency and bitrate allocation?
For the specific design, the following considerations should be taken For the specific design, the following considerations should be taken
into account (they form a mixture of common protocol design into account (they're a mixture of common protocol design guidelines,
guidelines and specifics for RTCP): and specifics for RTCP):
o First of all, if there is (and for RTCP this applies quite often) o First of all, if there is (and for RTCP this applies quite often)
an old-style mechanisms from a different networking environment, an old-style mechanisms from a different networking environment,
don't try to recreate this in RTCP. The networking environment is don't try to directly recreate this mechanism in RTP/RTCP. The
heterogeneous and will often be drastically different. Instead, Internet environment is extremely heterogeneous, and will often
ask what the actual semantics and the result perceived by the have drastically different properties and behaviour to other
application or the user are. Then, design a mechanism that network environments. Instead, ask what the actual semantics and
achieves this result compatible with RTP/RTCP. (And do not forget the result required to be perceived by the application or the user
that every mechanism will break if no packets get through.) are. Then, design a mechanism that achieves this result in a way
o Target re-usability for the specification, i.e., think broader that is compatible with RTP/RTCP. (And do not forget that every
than a specific use case. (Well, there is a balance to be struck: mechanism will break when no packets get through -- the Internet
in order to get anything done, there needs to be sufficient does not guarantee connectivity or performance.)
focus.) Point solutions need a really good motivation to be dealt o Target re-usability of the specification. That is, think broader
with in the IETF in the first place. This essentially suggests to than a specific use case and try to solve the general problem in
develop buildings blocks whenever possible. cases where it makes sense to do so. Point solutions need a very
o For everything (value, procedure, timer, etc.) being defined, make good motivation to be dealt with in the IETF in the first place.
sure that it is defined properly, so that independent This essentially suggests developing buildings blocks whenever
interoperable implementation can be done. possible, allowing them to be combined in different environments
o When defining field, mechanisms, etc., remember that all field than initially considered. Where possible, avoid mechanisms that
values need to be both generated and reacted upon, that mechanisms are specific to particular payload formats, media types, link or
network types, etc.
o For everything (packet format, value, procedure, timer, etc.)
being defined, make sure that it is defined properly, so that
independent interoperable implementation can be built. It is not
sufficient that you can implement the feature: it has to be
implementable in several years by someone unfamiliar with the
working group discussion and industry context. Remember that
fields need to be both generated and reacted upon, that mechanisms
need to be implemented, etc., and that all of this increases the need to be implemented, etc., and that all of this increases the
complexity of an implementation. Things which are too complex complexity of an implementation. Features which are too complex
won't get implemented in the first place. Extensions defining new won't get implemented (correctly) in the first place.
metrics and parameters should reference existing standards where o Extensions defining new metrics and parameters should reference
possible, rather than invent something new and/or proprietary. existing standards whenever possible, rather than try to invent
something new and/or proprietary.
o Remember that not every bit or every action needs to be o Remember that not every bit or every action must be represented or
represented or signalled explicitly. It may be possible to infer signalled explicitly. It may be possible to infer the necessary
the necessary pieces of information from other values or their pieces of information from other values or their evolution (a very
evolution (a very prominent example is TCP congestion control). prominent example is TCP congestion control). As a result, it may
As a result, it may be possible to decouple bits on the wire from be possible to decouple bits on the wire from local actions and
local actions and reduce the overhead. reduce the overhead.
o Particularly with media streams, reliability can often be "soft". o Particularly with media streams, reliability can often be "soft".
Rather than implementing explicit acknowledgements, receipt of a Rather than implementing explicit acknowledgements, receipt of a
hint may also be observed from the altered behaviour (e.g., hint may also be observed from the altered behaviour (e.g., the
sending the requested intra-frame or changing the reference frame reception of a requested intra-frame, or changing the reference
for video, changing the codec, etc.). The semantics of messages frame for video, changing the codec, etc.). The semantics of
should be idempotent so that the respective message may be sent messages should be idempotent so that the respective message may
repeatedly. be sent repeatedly. Requiring hard reliability does not scale
with increasing group sizes, and does not degrade gracefully as
network performance reduces.
o Choose the appropriate extension point. Depending on the type of
RTCP extension being developed, new data items can be transported
in several different ways:
* A new RTCP SDES item is appropriate for transporting data that
describes the source, or the user represented by the source,
rather than the ongoing media transmission. New SDES items may
be registered to transport source description information of
general interest, or the PRIV item may be used for proprietary
extensions.
* A new RTCP XR block type is appropriate for transporting new
metrics regarding transmission or reception quality.
* New RTP profiles may define a profile-specific extension to
RTCP SR and/or RR packets, to give additional feedback. Such
extension is not recommended, since the resulting packets are
not backwards compatible. It's generally more appropriate to
define a new RTCP XR block or a new RTCP packet type instead.
* New RTCP AVPF transport layer feedback messages should be used
to transmit general purpose feedback information, to be
generated and processed by the RTP transport. Examples include
(negative) acknowledgements for particular packets, or requests
to limit the transmission rate. This information is intended
to be independent of the codec or application in use.
* New RTCP AVPF payload-specific feedback messages should be used
to convey feedback information that is specific to a particular
media codec, RTP payload format, or category of RTP payload
formats. Examples include video picture loss indication or
reference picture selection, that are useful for many video
codecs.
* New RTCP AVPF application layer feedback messages should be
used to convery higher-level feedback, from one application to
another, above the level of codecs or transport.
* A new RTCP APP packet is appropriate for private use by
applications that don't need to interoperate with others, or
for experimentation before registering a new RTCP packet type.
It is not appropriate to register an RTCP APP packet in a
standards document.
Finally, new RTCP packet types may be registered if none of the
other extension points are appropriate.
TBD: discuss and cite the ALF paper (Clark and Tennenhouse, SIGCOMM The RTP framework was designed following the principle of application
1990) level framing with integrated layer processing, proposed by Clark and
Tennenhouse [ALF]. Effective use of RTP requires that extensions and
implementations be designed and built following the same philosophy.
That philosophy differs markedly from many previous systems in this
space, and making effective use of RTP requires an understanding of
those differences.
6. Security Considerations 6. Security Considerations
TBD. This memo does not specify any new protocol mechansims or procedures,
and so raises no explicit security considerations. When designing
RTCP extensions, it is important to consider the following points:
Congestion control and denial of service issues are likely key points o Privacy: RTCP extensions, in particular new Source Description
to raise here. (SDES) items, can potentially reveal information considered to be
sensitive by end users. Extensions should carefully consider the
uses to which information the release could be put, and should be
designed to reveal the minimum amount of additional information
needed for their correct operation.
o Congestion control: RTCP transmission timers have been carefully
designed such that the total amount of traffic generated by RTCP
is a small fraction of the media data rate. One consequence of
this is that the individual RTCP reporting interval scales with
both the media data rate and the group size. The RTCP timing
algorithms have been shown to scale from two-party unicast
sessions to group with tens of thousands of participants, and to
gracefully handle flash crowds and sudden departures [TimerRecon].
Proposals that modify the RTCP timer algorithms must be careful to
avoid congestion, potentially leading to denial of service, across
the full range of environments where RTCP is used.
o Denial of service: RTCP extensions that change the location where
feedback is sent must be carefully designed to prevent denial of
service attacks against third party nodes. When such extensions
are signalled, for example in SDP, this typically requires some
form of authentication of the signalling messages (e.g. see the
security considerations of [I-D.ietf-avt-rtcpssm]).
At the time of this writing there are several proposals for in-band
signalling of secure RTP sessions, where the signalling information
is conveyed on the media path. These proposals were discussed in the
Audio/Video Transport working group session at the 67th IETF meeting,
with the consensus being that such signalling is not to be conveyed
within RTP data packets, but should instead be sent within some form
of control packet, and that it is acceptable to multiplex control and
data packets on the same port, provided the packet types can be
clearly distinguished. There was no consensus in the working group
on the question of whether keying information should be conveyed in
RTCP packets multiplexed on the RTP port, or in some other protocol
multiplexed on the RTP port. The opinion of the working group chairs
and area director was, however, that both approaches are workable,
and fit within the RTP architecture, but that it may be cleaner to
use a separate keying protocol (modelled after STUN), than to try to
fit keying within RTCP
The security considerations of the RTP specification [RFC3550] apply,
along with any applicable profile (e.g. [RFC3551]).
7. IANA Considerations 7. IANA Considerations
There are no specific IANA action necessary for this document. No IANA actions are necessary.
8. Acknowledgements 8. Acknowledgements
This draft has been motivated by many discussions in the AVT WG. The This draft has been motivated by many discussions in the AVT WG. The
authors would like to acknowledge the active members in the group for authors would like to acknowledge the active members in the group for
providing the inspiration. providing the inspiration.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1996. April 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997.
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format
for Generic Forward Error Correction", RFC 2733,
December 1999.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", Modifiers for RTP Control Protocol (RTCP) Bandwidth",
RFC 3556, July 2003. RFC 3556, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003. November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
9.2. Informative References 9.2. Informative References
[I-D.ietf-avt-rtcpssm]
Ott, J., "RTCP Extensions for Single-Source Multicast
Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17
(work in progress), January 2008.
[I-D.ietf-avt-rtcp-non-compound] [I-D.ietf-avt-rtcp-non-compound]
Johansson, I. and M. Westerlund, "Support for non-compound Johansson, I. and M. Westerlund, "Support for non-compound
RTCP, opportunities and consequences", RTCP, opportunities and consequences",
draft-ietf-avt-rtcp-non-compound-02 (work in progress), draft-ietf-avt-rtcp-non-compound-02 (work in progress),
February 2008. February 2008.
[I-D.ietf-dccp-rtp]
Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in
progress), June 2007.
[ALF] Clark, D. and D. Tennenhouse, "Architectural
Considerations for a New Generation of Protocols",
Proceedings of ACM SIGCOMM 1990, September 1990.
[TimerRecon]
Schulzrinne, H. and J. Rosenberg, "Timer Reconsideration
for Enhanced RTP Scalability", Proceedings of IEEE
Infocom 1998, March 1998.
Authors' Addresses Authors' Addresses
Joerg Ott Joerg Ott
Helsinki University of Technology Helsinki University of Technology
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 Espoo, FIN 02150
Finland Finland
Email: jo@netlab.hut.fi Email: jo@netlab.hut.fi
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
Department of Computing Science Department of Computing Science
Sir Alwyn Williams Building
Lilybank Gardens Lilybank Gardens
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
 End of changes. 40 change blocks. 
175 lines changed or deleted 347 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/