draft-ietf-avt-rtcp-guidelines-02.txt   draft-ietf-avt-rtcp-guidelines-03.txt 
AVT Working Group J. Ott AVT Working Group J. Ott
Internet-Draft Helsinki University of Technology Internet-Draft Aalto University
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: July 9, 2010 University of Glasgow Expires: August 25, 2010 University of Glasgow
January 5, 2010 February 21, 2010
Guidelines for Extending the RTP Control Protocol (RTCP) Guidelines for Extending the RTP Control Protocol (RTCP)
draft-ietf-avt-rtcp-guidelines-02.txt draft-ietf-avt-rtcp-guidelines-03.txt
Abstract
The RTP Control Protocol (RTCP) is used along with the Real-time
Transport Protocol (RTP) to provide a control channel between media
senders and receivers. This allows constructing a feedback loop to
enable application adaptation and monitoring, among other uses. The
basic reporting mechanisms offered by RTCP are generic, yet quite
powerful and suffice to cover a range of uses. This document
provides guidelines on extending RTCP if those basic mechanisms prove
insufficient.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 44
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 July 9, 2010. This Internet-Draft will expire on August 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
The RTP Control Protocol (RTCP) is used along with the Real-time This document may contain material from IETF Documents or IETF
Transport Protocol (RTP) to provide a control channel between media Contributions published or made publicly available before November
senders and receivers. This allows constructing a feedback loop to 10, 2008. The person(s) controlling the copyright in some of this
enable application adaptivity and monitoring, among other uses. The material may not have granted the IETF Trust the right to allow
basic reporting mechanisms offered by RTCP are generic, yet quite modifications of such material outside the IETF Standards Process.
powerful and suffice to cover a range of uses. This document Without obtaining an adequate license from the person(s) controlling
provides guidelines on extending RTCP if those basic mechanisms prove the copyright in such materials, this document may not be modified
insufficient. outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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
3.3. Interactions with Network and Transport Layer 3.3. Interactions with Network and Transport Layer
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 8 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 4, line 10 skipping to change at page 4, line 10
future evolution of the protocol at large. We first outline the future evolution of the protocol at large. We first outline the
basic operation of RTCP and constructing feedback loops using the basic operation of RTCP and constructing feedback loops using the
basic RTCP mechanisms. Subsequently, we outline categories of basic RTCP mechanisms. Subsequently, we outline categories of
extensions proposed (and partly already accepted) for RTCP and extensions proposed (and partly already accepted) for RTCP and
discuss issues and alternative ways of thinking by example. Finally, discuss issues and alternative ways of thinking by example. Finally,
we provide some guidelines and highlight a number of questions to ask we provide some guidelines and highlight a number of questions to ask
(and answer!) before writing up an RTCP extension. (and answer!) before writing up an RTCP extension.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant
implementations.
The terminology defined in RTP [RFC3550], the RTP Profile for Audio The terminology defined in RTP [RFC3550], the RTP Profile for Audio
and Video Conferences with Minimal Control [RFC3551], and the and Video Conferences with Minimal Control [RFC3551], and the
Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585]
apply. apply.
3. RTP and RTCP Operation Overview 3. RTP and RTCP Operation Overview
One of the twelve networking truths states: "In protocol design, One of the twelve networking truths states: "In protocol design,
perfection has been reached not when there is nothing left to add, perfection has been reached not when there is nothing left to add,
but when there is nothing left to take away" [RFC1925]. Despite (or but when there is nothing left to take away" [RFC1925]. Despite (or
because of) this being an April, 1st, RFC, this specific truth is because of) this being an April, 1st, RFC, this specific truth is
very valid and it applies to RTCP as well. very valid and it applies to RTCP as well.
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
provides extended reporting mechanisms which are partly generic in [I-D.ietf-avt-rtcpssm]. RTCP XR [RFC3611] provides extended
nature, partly specific to a certain media stream. reporting mechanisms which are partly generic in nature, partly
specific to a certain media stream.
We do not discuss RTP-related documents that are orthogonal to RTCP. We do not discuss RTP-related documents that are orthogonal to RTCP.
The Secure RTP Profile [RFC3711] can be used to secure RTCP in much The Secure RTP Profile [RFC3711] can be used to secure RTCP in much
the same way it secures RTP data, but otherwise does not affect the the same way it secures RTP data, but otherwise does not affect the
behaviour of RTCP. The transport protocol used also has little behaviour of RTCP. The transport protocol used also has little
impact, since RTCP remains a group communication protocol even when impact, since RTCP remains a group communication protocol even when
running over a unicast transport (such as TCP [RFC4571] or DCCP running over a unicast transport (such as TCP [RFC4571] or DCCP
[I-D.ietf-dccp-rtp]), and is little affected by congestion control [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 due to its low rate relative to the media. The description of RTP
topologies [RFC5117] is useful knowledge, but is functionally not topologies [RFC5117] is useful knowledge, but is functionally not
relevant here. The various RTP error correction mechanisms (e.g. relevant here. The various RTP error correction mechanisms (e.g.
[RFC2198], [RFC2733], [RFC4588], [RFC5109]) are useful for protecting [RFC2198], [RFC4588], [RFC5109]) are useful for protecting RTP media
RTP media streams, and may be enabled as a result of RTCP feedback, streams, and may be enabled as a result of RTCP feedback, but do not
but do not directly affect RTCP behaviour. 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
skipping to change at page 6, line 20 skipping to change at page 6, line 17
360 seconds divided by the session bandwidth in kilobits/second 360 seconds divided by the session bandwidth in kilobits/second
(giving an interval smaller than 5 seconds for bandwidths greater (giving an interval smaller than 5 seconds for bandwidths greater
than 72 kb/s) [RFC3550]. than 72 kb/s) [RFC3550].
This lower limit can be eliminated, allowing more frequent feedback, This lower limit can be eliminated, allowing more frequent feedback,
when using the early feedback profile for RTCP [RFC4585]. In this when using the early feedback profile for RTCP [RFC4585]. In this
case, the RTCP frequency is only limited by the available bitrate case, the RTCP frequency is only limited by the available bitrate
(usually 5% of the media stream bit rate is allocated for RTCP). If (usually 5% of the media stream bit rate is allocated for RTCP). If
this fraction is insufficient, the RTCP bitrate may be increased in this fraction is insufficient, the RTCP bitrate may be increased in
the session description to enable more frequent feedback [RFC3556]. the session description to enable more frequent feedback [RFC3556].
Ongoing work [I-D.ietf-avt-rtcp-non-compound] may reduce the mean Ongoing work [RFC5506] may reduce the mean RTCP packet size, further
RTCP packet size, further increasing feedback frequency. increasing feedback frequency.
The mechanisms defined in [RFC4585] even allow -- statistically -- a The mechanisms defined in [RFC4585] even allow -- statistically -- a
receiver to provide close-to-instant feedback to a sender about receiver to provide close-to-instant feedback to a sender about
observed events in the media stream (e.g. picture or slice loss). observed events in the media stream (e.g. picture or slice loss).
RTCP is suitable for unicast and multicast communications. All basic RTCP is suitable for unicast and multicast communications. All basic
functions are designed with group communications in mind. While functions are designed with group communications in mind. While
traditional (any-source) multicast (ASM) is clearly not available in traditional (any-source) multicast (ASM) is clearly not available in
the Internet at large, source-specific multicast (SSM) and overlay the Internet at large, source-specific multicast (SSM) and overlay
multicast are -- and both are commercially relevant. RTCP extensions multicast are -- and both are commercially relevant. RTCP extensions
skipping to change at page 7, line 6 skipping to change at page 7, line 6
(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 - De-jittering
- Packet size - Timing and sync info - Synchronization - Packet size - Timing and sync info - Synchronisation
- 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 - Retroactive 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 is insufficient for TCP-Friendly 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), but can still be used to adapt be in the order of once per RTT), but can still be used to adapt
to the available bandwidth on slower timescales. to the available bandwidth on slower time-scales.
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
skipping to change at page 8, line 25 skipping to change at page 8, line 25
RTT from pairs of RTCP SR and RR packets. This inference makes the RTT from pairs of RTCP SR and RR packets. This inference makes the
implicit assumption that RTP and RTCP are treated equally: they are implicit assumption that RTP and RTCP are treated equally: they are
routed along the same path, mapped to the same (DiffServ) traffic routed along the same path, mapped to the same (DiffServ) traffic
classes, and treated as part of the same fair queuing classification. classes, and treated as part of the same fair queuing classification.
This is true in many cases, however since RTP and RTCP are generally This is true in many cases, however since RTP and RTCP are generally
sent using different ports, any flow classification based upon the sent using different ports, any flow classification based upon the
quintuple (source and destination IP address and port number, quintuple (source and destination IP address and port number,
transport protocol) could lead to a differentiation between RTP and transport protocol) could lead to a differentiation between RTP and
RTCP flows, disrupting the statistics. RTCP flows, disrupting the statistics.
While some networks may wish to intentionally prioritize RTCP over While some networks may wish to intentionally prioritise RTCP over
RTP (to provide quicker feedback) or RTP over RTCP (since the media RTP (to provide quicker feedback) or RTP over RTCP (since the media
is considered more important than control), we recommend that they be is considered more important than control), we recommend that they be
treated identically where possible, to enable this inference of treated identically where possible, to enable this inference of
network performance, and hence support application adaptation. network performance, and hence support application adaptation.
When using reliable transport connections for (RTP and) RTCP When using reliable transport connections for (RTP and) RTCP
[RFC2326] [RFC4571], retransmissions and head-of-line blocking may [RFC2326] [RFC4571], retransmissions and head-of-line blocking may
similarly lead to inaccurate RTT estimates derived by RTCP. (These similarly lead to inaccurate RTT estimates derived by RTCP. (These
may, nevertheless, properly reflect the mean RTT for a media packet may, nevertheless, properly reflect the mean RTT for a media packet
including retransmissions.) including retransmissions.)
The conveyance of information in RTCP is affected by the above only The conveyance of information in RTCP is affected by the above only
as soon as the prioritization leads to RTCP packets being dropped as soon as the prioritisation leads to RTCP packets being dropped
overproportionally. over proportionally.
All of this emphasizes the unreliable nature of RTCP. Multiplexing All of this emphasises the unreliable nature of RTCP. Multiplexing
on the same port number [I-D.ietf-avt-rtp-and-rtcp-mux] or inside the on the same port number [I-D.ietf-avt-rtp-and-rtcp-mux] or inside the
same transport connection might help mitigating some of these same transport connection might help mitigating some of these
effects; but this is limited to speculation at this point and should effects; but this is limited to speculation at this point and should
not be relied upon. not be relied upon.
4. Issues with RTCP Extensions 4. Issues with RTCP Extensions
Issues that have come 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 two-party sessions. RTP is o Defined only or primarily for unicast two-party sessions. RTP is
inherently a group communication protocol, even when operating on inherently a group communication protocol, even when operating on
a unicast connection. Extensions may become useful in the future a unicast connection. Extensions may become useful in the future
well outside their originally intended area of application, and well outside their originally intended area of application, and
should consider this. Stating that something works for unicast should consider this. Stating that something works for unicast
only is not acceptable, particularly since various flavours of only is not acceptable, particularly since various flavours of
multicast have become relevant again, and as middleboxes such as multicast have become relevant again, and as middleboxes such as
repair servers, mixers, and RTCP-supporting MCUs [RFC5117] become repair servers, mixers, and RTCP-supporting MCUs [RFC5117] become
more widely used. more widely used.
o Assuming reliable (instant) state synchronization. RTCP reports o Assuming reliable (instant) state synchronisation. 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 (several seconds) between intending to send a significant time lag (several seconds) between intending to send a
state update to the RTP peer(s) and the packet being received, in state update to the RTP peer(s) and the packet being received, in
some cases, the packet may not be received at all. some cases, the packet may not be received at all.
o Requiring reliable delivery of RTCP reports. While reliability o Requiring reliable delivery of RTCP reports. While reliability
can be implemented on top of RTCP using acknowledgements, this can be implemented on top of RTCP using acknowledgements, this
will come at the cost of significant additional delay, which may will come at the cost of significant additional delay, which may
defeat the purpose of providing the feedback in the first place. defeat the purpose of providing the feedback in the first place.
Moreover, for scalability reasons due to the group-based nature of Moreover, for scalability reasons due to the group-based nature of
skipping to change at page 9, line 40 skipping to change at page 9, line 40
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 (yet, RTCP may also be used to report information share for RTCP (yet, RTCP may also be used to report information
that has fine-grained temporal characteristics, if summarization that has fine-grained temporal characteristics, if summarisation
or data reduction by the endpoint would lose essential or data reduction by the endpoint would lose essential
resolution). The information going into RTCP reports should resolution). The information going into RTCP reports should
primarily target the peer(s) (and thus include information that primarily target the peer(s) (and thus include information that
can be meaningfully reacted upon), nevertheless, such reports may can be meaningfully reacted upon), nevertheless, such reports may
provide useful information to augment other network management provide useful information to augment other network management
tools. Gathering and reporting statistics beyond this is not an tools. Gathering and reporting statistics beyond this is not an
RTCP task and should be addressed by out-of-band protocols. RTCP task and should be addressed 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 10, line 32 skipping to change at page 10, line 32
guidelines on what to consider when thinking about extensions to RTP guidelines on what to consider when thinking about extensions to RTP
and RTCP. and RTCP.
5. Guidelines 5. Guidelines
Designing RTCP extensions requires consideration of a number issues, Designing RTCP extensions requires consideration of a number issues,
as well as in-depth understanding of the operation of RTP mechanisms. as well as in-depth understanding of the operation of RTP mechanisms.
While it is expected that there are many aspects not yet covered by While it is expected that there are many aspects not yet covered by
RTCP reporting and operation, quite a bit of functionality is readily RTCP reporting and operation, quite a bit of functionality is readily
available for use. Other mechanisms should probably never become available for use. Other mechanisms should probably never become
part of the RTP family of specifications, despite the existance of part of the RTP family of specifications, despite the existence of
their equivalents in other environments. In the following, we their equivalents in other environments. In the following, we
provide some guidance to consider when (and before!) developing an provide some guidance to consider when (and before!) developing an
extension to RTCP. extension to RTCP.
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 can be done with the existing mechanisms, exploiting o Check what can be done with the existing mechanisms, exploiting
the information that is already available in RTCP. Is the need the information that is already available in RTCP. Is the need
for an extension only perceived (e.g., due to lazy implementers, for an extension only perceived (e.g., due to lazy implementers,
skipping to change at page 12, line 6 skipping to change at page 12, line 6
o How will this extension work with group communication scenarios, o How will this extension work with group communication scenarios,
such as multicast? Will the extensions degrade gracefully with such as multicast? Will the extensions degrade gracefully with
increasing group sizes? What will be the impact on the RTCP increasing group sizes? What will be the impact on the RTCP
report frequency and bitrate allocation? 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're a mixture of common protocol design guidelines, into account (they're a mixture of common protocol design 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, a mechanism from a different networking environment, don't try to
don't try to directly recreate this mechanism in RTP/RTCP. The directly recreate this mechanism in RTP/RTCP. The Internet
Internet environment is extremely heterogeneous, and will often environment is extremely heterogeneous, and will often have
have drastically different properties and behaviour to other drastically different properties and behaviour to other network
network environments. Instead, ask what the actual semantics and environments. Instead, ask what the actual semantics and the
the result required to be perceived by the application or the user result required to be perceived by the application or the user
are. Then, design a mechanism that achieves this result in a way are. Then, design a mechanism that achieves this result in a way
that is compatible with RTP/RTCP. (And do not forget that every that is compatible with RTP/RTCP. (And do not forget that every
mechanism will break when no packets get through -- the Internet mechanism will break when no packets get through -- the Internet
does not guarantee connectivity or performance.) does not guarantee connectivity or performance.)
o Target re-usability of the specification. That is, think broader o Target re-usability of the specification. That is, think broader
than a specific use case and try to solve the general problem in than a specific use case and try to solve the general problem in
cases where it makes sense to do so. Point solutions need a very cases where it makes sense to do so. Point solutions need a very
good motivation to be dealt with in the IETF in the first place. good motivation to be dealt with in the IETF in the first place.
This essentially suggests developing buildings blocks whenever This essentially suggests developing buildings blocks whenever
possible, allowing them to be combined in different environments possible, allowing them to be combined in different environments
than initially considered. Where possible, avoid mechanisms that than initially considered. Where possible, avoid mechanisms that
are specific to particular payload formats, media types, link or are specific to particular payload formats, media types, link or
network types, etc. network types, etc.
o For everything (packet format, value, procedure, timer, etc.) o For everything (packet format, value, procedure, timer, etc.)
being defined, make sure that it is defined properly, so that being defined, make sure that it is defined properly, so that
independent interoperable implementation can be built. It is not independent interoperable implementation can be built. It is not
sufficient that you can implement the feature: it has to be sufficient that you can implement the feature: it has to be
implementable in several years by someone unfamiliar with the implemented in several years by someone unfamiliar with the
working group discussion and industry context. Remember that working group discussion and industry context. Remember that
fields need to be both generated and reacted upon, that mechanisms 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. Features which are too complex complexity of an implementation. Features which are too complex
won't get implemented (correctly) in the first place. won't get implemented (correctly) in the first place.
o Extensions defining new metrics and parameters should reference o Extensions defining new metrics and parameters should reference
existing standards whenever possible, rather than try to invent existing standards whenever possible, rather than try to invent
something new and/or proprietary. something new and/or proprietary.
o Remember that not every bit or every action must be represented or o Remember that not every bit or every action must be represented or
signalled explicitly. It may be possible to infer the necessary signalled explicitly. It may be possible to infer the necessary
pieces of information from other values or their evolution (a very pieces of information from other values or their evolution (a very
prominent example is TCP congestion control). As a result, it may prominent example is TCP congestion control). As a result, it may
be possible to decouple bits on the wire from local actions and be possible to de-couple bits on the wire from 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., the hint may also be observed from the altered behaviour (e.g., the
reception of a requested intra-frame, or changing the reference reception of a requested intra-frame, or changing the reference
frame for video, changing the codec, etc.). The semantics of frame for video, changing the codec, etc.). The semantics of
messages should be idempotent so that the respective message may messages should be idempotent so that the respective message may
be sent repeatedly. Requiring hard reliability does not scale be sent repeatedly. Requiring hard reliability does not scale
with increasing group sizes, and does not degrade gracefully as with increasing group sizes, and does not degrade gracefully as
skipping to change at page 13, line 50 skipping to change at page 13, line 50
[RFC4585] sections 6.2 and 9). [RFC4585] sections 6.2 and 9).
* New RTCP AVPF payload-specific feedback messages should be used * New RTCP AVPF payload-specific feedback messages should be used
to convey feedback information that is specific to a particular to convey feedback information that is specific to a particular
media codec, RTP payload format, or category of RTP payload media codec, RTP payload format, or category of RTP payload
formats. Examples include video picture loss indication or formats. Examples include video picture loss indication or
reference picture selection, that are useful for many video reference picture selection, that are useful for many video
codecs (see [RFC4585] sections 6.3 and 9). codecs (see [RFC4585] sections 6.3 and 9).
* New RTCP AVPF application layer feedback messages should be * New RTCP AVPF application layer feedback messages should be
used to convery higher-level feedback, from one application to used to convey higher-level feedback, from one application to
another, above the level of codecs or transport (see [RFC4585] another, above the level of codecs or transport (see [RFC4585]
sections 6.4 and 9). sections 6.4 and 9).
* A new RTCP APP packet is appropriate for private use by * A new RTCP APP packet is appropriate for private use by
applications that don't need to interoperate with others, or applications that don't need to interoperate with others, or
for experimentation before registering a new RTCP packet type for experimentation before registering a new RTCP packet type
([RFC3550] section 6.7). It is not appropriate to define a new ([RFC3550] section 6.7). It is not appropriate to define a new
RTCP APP packet in a standards document: use one of the other RTCP APP packet in a standards document: use one of the other
extension points, or define a new RTCP packet type instead. extension points, or define a new RTCP packet type instead.
skipping to change at page 14, line 27 skipping to change at page 14, line 27
The RTP framework was designed following the principle of application The RTP framework was designed following the principle of application
level framing with integrated layer processing, proposed by Clark and level framing with integrated layer processing, proposed by Clark and
Tennenhouse [ALF]. Effective use of RTP requires that extensions and Tennenhouse [ALF]. Effective use of RTP requires that extensions and
implementations be designed and built following the same philosophy. implementations be designed and built following the same philosophy.
That philosophy differs markedly from many previous systems in this That philosophy differs markedly from many previous systems in this
space, and making effective use of RTP requires an understanding of space, and making effective use of RTP requires an understanding of
those differences. those differences.
6. Security Considerations 6. Security Considerations
This memo does not specify any new protocol mechansims or procedures, This memo does not specify any new protocol mechanisms or procedures,
and so raises no explicit security considerations. When designing and so raises no explicit security considerations. When designing
RTCP extensions, it is important to consider the following points: RTCP extensions, it is important to consider the following points:
o Privacy: RTCP extensions, in particular new Source Description o Privacy: RTCP extensions, in particular new Source Description
(SDES) items, can potentially reveal information considered to be (SDES) items, can potentially reveal information considered to be
sensitive by end users. Extensions should carefully consider the sensitive by end users. Extensions should carefully consider the
uses to which information they release could be put, and should be uses to which information they release could be put, and should be
designed to reveal the minimum amount of additional information designed to reveal the minimum amount of additional information
needed for their correct operation. needed for their correct operation.
skipping to change at page 15, line 32 skipping to change at page 15, line 32
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
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997. September 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[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",
skipping to change at page 16, line 40 skipping to change at page 16, line 33
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
9.2. Informative References 9.2. Informative References
[I-D.ietf-avt-rtcpssm] [I-D.ietf-avt-rtcpssm]
Ott, J., "RTCP Extensions for Single-Source Multicast Ott, J. and J. Chesterfield, "RTCP Extensions for Single-
Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17 Source Multicast Sessions with Unicast Feedback",
(work in progress), January 2008. draft-ietf-avt-rtcpssm-19 (work in progress),
November 2009.
[I-D.ietf-avt-rtcp-non-compound]
Johansson, I. and M. Westerlund, "Support for non-compound
RTCP, opportunities and consequences",
draft-ietf-avt-rtcp-non-compound-02 (work in progress),
February 2008.
[I-D.ietf-dccp-rtp] [I-D.ietf-dccp-rtp]
Perkins, C., "RTP and the Datagram Congestion Control Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in
progress), June 2007. progress), June 2007.
[I-D.ietf-avt-rtp-and-rtcp-mux] [I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
skipping to change at page 17, line 28 skipping to change at page 17, line 20
Proceedings of ACM SIGCOMM 1990, September 1990. Proceedings of ACM SIGCOMM 1990, September 1990.
[TimerRecon] [TimerRecon]
Schulzrinne, H. and J. Rosenberg, "Timer Reconsideration Schulzrinne, H. and J. Rosenberg, "Timer Reconsideration
for Enhanced RTP Scalability", Proceedings of IEEE for Enhanced RTP Scalability", Proceedings of IEEE
Infocom 1998, March 1998. Infocom 1998, March 1998.
Authors' Addresses Authors' Addresses
Joerg Ott Joerg Ott
Helsinki University of Technology Aalto University
School of Science and Technology
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 Espoo, FIN 02150
Finland Finland
Email: jo@netlab.hut.fi Email: jo@netlab.tkk.fi
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
Department of Computing Science Department of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
 End of changes. 30 change blocks. 
72 lines changed or deleted 76 lines changed or added

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