draft-ietf-avt-rtcp-guidelines-01.txt   draft-ietf-avt-rtcp-guidelines-02.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: September 10, 2009 University of Glasgow Expires: July 9, 2010 University of Glasgow
March 9, 2009 January 5, 2010
Guidelines for Extending the RTP Control Protocol (RTCP) Guidelines for Extending the RTP Control Protocol (RTCP)
draft-ietf-avt-rtcp-guidelines-01.txt draft-ietf-avt-rtcp-guidelines-02.txt
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 33
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 September 10, 2009. This Internet-Draft will expire on July 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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
4. Issues with RTCP Extensions . . . . . . . . . . . . . . . . . 8 4. Issues with RTCP Extensions . . . . . . . . . . . . . . . . . 8
5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 9, line 14 skipping to change at page 9, line 14
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 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 (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
RTCP, these ACKs need to be adaptively rate limited or targeted to RTCP, these ACKs need to be adaptively rate limited or targeted to
a subgroup or individual entity to avoid implosion as group sizes a subgroup or individual entity to avoid implosion as group sizes
increase. RTCP is not intended or suitable for use as a reliable increase. RTCP is not intended or suitable for use as a reliable
control channel. control channel.
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 (yet, RTCP may also be used to report information
should primarily target the peer (and thus include information that has fine-grained temporal characteristics, if summarization
that can be meaningfully reacted upon). Gathering and reporting or data reduction by the endpoint would lose essential
statistics beyond this is not an RTCP task and should be addressed resolution). The information going into RTCP reports should
by out-of-band protocols. primarily target the peer(s) (and thus include information that
can be meaningfully reacted upon), nevertheless, such reports may
provide useful information to augment other network management
tools. Gathering and reporting statistics beyond this is not an
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
calculate/infer this information to begin with (which requires calculate/infer this information to begin with (which requires
very precise specifications). Given that it already seems to be very precise specifications). Given that it already seems to be
difficult to even implement baseline RTCP, any added complexity difficult to even implement baseline RTCP, any added complexity
can only discourage implementers, may lead to buggy can only discourage implementers, may lead to buggy
implementations (in which case the reports do not serve the implementations (in which case the reports do not serve the
purpose they were intended to), and hinder interoperability. purpose they were intended to), and hinder interoperability.
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
skipping to change at page 14, line 17 skipping to change at page 15, line 4
designed such that the total amount of traffic generated by RTCP designed such that the total amount of traffic generated by RTCP
is a small fraction of the media data rate. One consequence of is a small fraction of the media data rate. One consequence of
this is that the individual RTCP reporting interval scales with this is that the individual RTCP reporting interval scales with
both the media data rate and the group size. The RTCP timing both the media data rate and the group size. The RTCP timing
algorithms have been shown to scale from two-party unicast algorithms have been shown to scale from two-party unicast
sessions to group with tens of thousands of participants, and to sessions to group with tens of thousands of participants, and to
gracefully handle flash crowds and sudden departures [TimerRecon]. gracefully handle flash crowds and sudden departures [TimerRecon].
Proposals that modify the RTCP timer algorithms must be careful to Proposals that modify the RTCP timer algorithms must be careful to
avoid congestion, potentially leading to denial of service, across avoid congestion, potentially leading to denial of service, across
the full range of environments where RTCP is used. the full range of environments where RTCP is used.
o Denial of service: RTCP extensions that change the location where o Denial of service: RTCP extensions that change the location where
feedback is sent must be carefully designed to prevent denial of feedback is sent must be carefully designed to prevent denial of
service attacks against third party nodes. When such extensions service attacks against third party nodes. When such extensions
are signalled, for example in SDP, this typically requires some are signalled, for example in SDP, this typically requires some
form of authentication of the signalling messages (e.g. see the form of authentication of the signalling messages (e.g. see the
security considerations of [I-D.ietf-avt-rtcpssm]). 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, The security considerations of the RTP specification [RFC3550] apply,
along with any applicable profile (e.g. [RFC3551]). along with any applicable profile (e.g. [RFC3551]).
7. IANA Considerations 7. IANA Considerations
No IANA actions are necessary. 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
skipping to change at page 17, line 21 skipping to change at page 17, line 38
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
Lilybank Gardens
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
 End of changes. 14 change blocks. 
30 lines changed or deleted 23 lines changed or added

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