Internet DRAFT - draft-ott-avtcore-rtcp-overlay-multicast
draft-ott-avtcore-rtcp-overlay-multicast
AVT Working Group V. Singh
Internet-Draft J. Devadoss
Intended status: Informational J. Ott
Expires: September 9, 2012 Aalto University
I. Curcio
Nokia
March 8, 2012
Real-time Transport Control Protocol (RTCP) in Overlay Multicast
draft-ott-avtcore-rtcp-overlay-multicast-02.txt
Abstract
The Real-time Transport Control Protocol(RTCP) is designed to operate
along with Real-time Transport Protocol(RTP) in unicast, single-
source multicast and any-source multicast environments. With the
availability of overlay multicast and Application Layer
Multicast(ALM), the suitability of RTCP in such environments need to
be analyzed. The applicability of the existing RTCP reporting
architectures in overlay multicast and ALM environments are
investigated and the new features that may be required are discussed
in this document.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Singh, et al. Expires September 9, 2012 [Page 1]
Internet-Draft RTCP in Overlay Multicast March 2012
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overlay Multicast . . . . . . . . . . . . . . . . . . . . . . 4
4. Classifying feedback reporting mechanism . . . . . . . . . . . 5
5. Classifying overlay multicast topologies and
media/overlay operations . . . . . . . . . . . . . . . . . . . 6
6. RTP Entities in an overlay multicast network . . . . . . . . . 6
7. Applicability of RTCP reporting as defined in RFC 3550 . . . . 8
8. Applicability of RTCP with unicast feedback target . . . . . . 9
9. Desirable features of RTCP in overlay multicast . . . . . . . 10
10. An example explaining the issues . . . . . . . . . . . . . . . 10
11. Endpoint Reporting . . . . . . . . . . . . . . . . . . . . . . 11
12. Hop-by-hop RTCP reporting . . . . . . . . . . . . . . . . . . 12
13. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 12
14. Security Considerations . . . . . . . . . . . . . . . . . . . 12
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
16. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Singh, et al. Expires September 9, 2012 [Page 2]
Internet-Draft RTCP in Overlay Multicast March 2012
1. Introduction
RTP [2] provides transport mechanisms suitable for unicast, any-
source multicast and single-source multicast. RTP is used to carry
audio and video streams together with the RTP control protocol to
provide periodic feedback about the media streams received in a
specific duration. The RTCP reporting interval is defined as part of
the RTCP and depends on the number of participants, type of
participants(sender or receiver) and the operating environment of the
session(point to point or multicast).
The RFC3550 [2] specifies the maximum RTCP bandwidth to be 5% of the
media bit rate. In point to point sessions, each participant gets a
equal share of 2.5% of the media bit rate to be used for RTCP. In
multicast (including any-source multicast and source-specific
multicast) sessions, the senders usually share 25% of the allocated
RTCP bandwidth and the receivers share the remaining 75% of the RTCP
bandwidth. The RTCP bandwidth share may be modified using RFC 3556
[4], but will generally be kept small so as to have a smooth media
stream flow.
In a multicast session, the RTCP reports are multicast so that each
participant can receive the RTCP reports from every other participant
and thus obtain a "global" view of the multicast session. This,
however, requires multicast connectivity between all peers and thus
cannot be applied to Source-specific Multicast (SSM) [6]. Specific
RTCP extensions were developed for SSM [7] introducing a mechanism of
RTCP reporting where the RTCP reports are unicast to a feedback
target. This mechanism is specifically applicable in scenarios where
many-to-many group communication is not available or not desired or a
sender-controlled summarized reporting is desired. RTCP reports are
unicast to a feedback target specified during initialization or
inside RTCP reports. The RTCP reporting interval calculation
specified in RTCP Extension for SSM uses the same mechanisms as
specified in RFC3550 [2]; the distribution source may send RTCP RSI
reports to control the rate at which RTCP reports are generated by
the receivers. The aforementioned rules for bandwidth modifications
apply as well.
Recent interest in overlay multicasting and ALM -- to substitute for
the lack of globally available native IP any-source multicast --
motivates also carrying RTP-based media streams in such environments.
In ALM, the participating nodes form a distribution tree to forward
the data. ALM involves the use of different mechanisms to construct
and maintain the distribution tree. In overlay multicast, individual
multicast enabled networks are connected by virtual unicast links.
Overlay multicast involves mechanisms to construct optimal
Singh, et al. Expires September 9, 2012 [Page 3]
Internet-Draft RTCP in Overlay Multicast March 2012
interconnection of virtual links. An ALM can be viewed as a sub
class of overlay multicast, if the individual multicast enabled
networks have only one participating node. So, further in this
document, when we refer to overlay multicast it also includes ALM.
Depending on the abstraction chosen for the overlay multicast, the
RTP/RTCP entities using it may or may not be aware of the hop-by-hop
forwarding of the packets:
If they are not, regular any-source multicast operation of RTP and
RTCP as per RFC 3550 is a workable, yet possibly not optimal
solution.
If RTP entities are aware of the forwarding process, additional RTCP
reporting and aggregation mechanisms may be applied and the existing
RTCP reporting mechanisms need to be investigated for their
applicability in overlay multicast
In either case, in an overlay multicast environment, using RTP to
transport media streams will be straightforward,
In this document, we take a very first stab at reviewing the RTCP
reporting mechanism specified in RFC3550 [2] and the RTCP Extension
for SSM to find its applicability in the overlay multicast
environment. We also discuss on the specific characteristics of the
overlay multicast and the type of reporting that is desired on such
environments. This document also complements the RTP topologies
overview [5].
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 [1]
and indicate requirement levels for compliant implementations.
The terminology defined in RTP [2], the RTP Profile for Audio and
Video Conferences with Minimal Control [3], and the RTCP Extension
for SSM [7], apply.
For the time being, in this document, by overlay multicast we refer
to a multicast overlay offering media distribution from a single
source, analogous to SSM.
3. Overlay Multicast
In overlay multicast, the media streams are multicast over an network
Singh, et al. Expires September 9, 2012 [Page 4]
Internet-Draft RTCP in Overlay Multicast March 2012
of virtual links that is constructed using mechanisms in line with
the requirements of the application using the overlay. The
construction and maintenance of the overlay involves mechanisms for
bootstrapping the new participant to the overlay, routing, pro-
active/reactive repair, improving scalability and recovery from loss
of a forwarding node or a virtual link. In this document, these
mechanisms are further referred to as overlay operation. As the
overlay network is formed by the participating nodes, the loss of a
participating node brings change in the network structure. So, there
is an inherent instability in the overlay multicast which are
addressed by the overlay operation.
In overlay multicast, the participating nodes can use mechanisms for
providing error resilience and congestion control that can
proactively adapt or reactively repair the media streams depending on
the receiver metrics reported by the nodes below its hierarchy. In
this document, the error resilience mechanisms together with
congestion control techniques are further referred to as media
operation.
The media operation depends on the metrics (reported reception
quality) reported by the participants. The overlay operation can
depend on different types of metrics and may also include the media
quality metrics like round trip time, observed packet loss, jitter
etc. As the overlay operation depends on the application using the
overlay, there can be significant overlap with the metrics used by
media operation.
Using RTP in overlay multicast does not require any change to its
specification. Every participating node that receives the RTP packet
replicates the packet and sends down the distribution tree. RTCP SR
follows the same path as RTP, so it does not bring in changes with
its use in overlay multicast. In the case of RTCP RR, it reports the
receiver's perceived media quality and it carries significant data
based on which the algorithms of media and/or overlay operation can
operate.
The multicast overlay maintenance mechanisms may operate entirely
independent of RTCP reporting, they may choose to leverage parts of
the RTCP reporting, or they may rely entirely on RTCP. In this
document, we are concerned about the operation of RTCP reporting in
such an environment and we do not take (at this point) any position
on the way the overlay operates.
4. Classifying feedback reporting mechanism
Any feedback reporting mechanism in a session with n participants can
Singh, et al. Expires September 9, 2012 [Page 5]
Internet-Draft RTCP in Overlay Multicast March 2012
be classified into one of the following categories.
o (i) 1 to 1 reporting
o (ii) 1 to n reporting
o (iii) 1 to m reporting (m < n, every node reports to m nodes)
An example of '1 to 1' reporting is RTCP in SSM with unicast feedback
target (and, of course, in case of point-to-point sessions). An
example of '1 to n' reporting is RTCP in multicast mode as specified
in RFC 3550. In further sections, we shall be referring to these
mechanisms while discussing the applicability of a RTCP reporting
model.
5. Classifying overlay multicast topologies and media/overlay
operations
The effectiveness of a chosen RTCP reporting model, directly depends
on the type of overlay multicast topology, type of the media/overlay
operation and the number of participants in the session. Therefore,
when considering the applicability of a RTCP reporting model, they
need to be evaluated against the every possible combinations of
overlay multicast topology, media and overlay operation.
The overlay multicast topologies can be broadly classified into two
categories.
o (i) Overlay multicast, with no or very minimal overlay
operations(virtual links are statically configured)
o (ii) Overlay multicast, that relies on overlay operations to
dynamically configure distribution tree.
The overlay and media operations can be classified into two
categories.
o (i) Centralized: A single entity decides on the type of media/
overlay operations.
o (ii) Distributed: At any instant more than one entity is
attempting to perform media/overlay operation.
6. RTP Entities in an overlay multicast network
The below figure represents a sample overlay multicast network. In
this section, we see how the RTP entities can be used to describe a
overlay multicast network.
Singh, et al. Expires September 9, 2012 [Page 6]
Internet-Draft RTCP in Overlay Multicast March 2012
o(0) -Media source
/ \
/ \
_________ o(OMN1) o(OMN2) OMN -> Overlay Multicast Node
|I P | \\ /\
|multicast| || / \
|network | || / \
--------- || OMN5 OMN6 ___ OMN7
_____|| \
/ \ \___ OMN8
___o(OMN3) \ (OMN4)____
| IP | \o IP |
|multicast| |multicast|
|network | |network |
--------- ---------
Figure 1: A sample overlay multicast topology
Describing an Overlay Multicast Node (OMN) using RTP entities: Each
OMN can be considered as a combination of a RTP media handler and a
RTP translator. The purpose of the translator is to replicate and
forward the streams to different network destinations and to handle
RTCP reports. The media handler receives RTP streams, processes
received RTCP reports and generates RTCP receiver reports.
Role of RTP Translator in forwarding RTP streams: The RTP translator
in each OMN forwards the received RTP packets(from its parent node)
to all virtual links it is connected with. For example, RTP
translator in OMN1 forwards RTP packets to its RTP media handler,
OMN3, OMN4 and the IP multicast network it is connected with.
Role of RTP Translator in handling RTCP reports: When there is no
change to the media encoding, the RTP translator uses the straight
case of Replicate and Forward mechanism.
Replicate and Forward: The RTP translator replicates and forwards the
RTCP RR received from one virtual link to all other virtual links.
Below, we explain using OMN1 as example. The RTP translator in OMN1
receives RTCP RR from,
o the media handler(which is within the same node)
o the native multicast network
o OMN3
o OMN4
o parent OMN (which is forwarding the RTCP RRs received from the
other virtual links, it is connected with)
To explain the RTCP forwarding rules, we take an sample event where
the translator in OMN1 receives a RTCP RR from IP multicast network.
Singh, et al. Expires September 9, 2012 [Page 7]
Internet-Draft RTCP in Overlay Multicast March 2012
The event response shall be that, it is forwarded to the media
handler(within OMN1), OMN3, OMN4 and to the parent node(in the case
of OMN1, it is media source). In this way, all participating nodes
in the session shall receive RTCP RR from all other participating
nodes.
In the overlay multicast scenario, the RTP translator in an OMN can
be extended to do other operations, such as, filtering and
aggregating RTCP reports, etc. But to realize it, the scope and
definitions of an RTP translator needs to be analyzed. (TBD)
7. Applicability of RTCP reporting as defined in RFC 3550
If this reporting mechanism is to be used in an overlay multicast,
then the RTP translator in each node replicates and forwards the RTCP
reports on all (virtual) links except the incoming (virtual) link.
It is a form of '1 to n' reporting, where all participants get a copy
of the RTCP report sent by every other participant. Now, let us look
at the effectiveness of this reporting model in the overlay multicast
environment.
With the increase in number of receivers, the RTCP reporting interval
increases. The larger the reporting interval, fewer the options
available for media operation. For example, with 'x' number of
participants, it can be possible to do retransmission based on an
RTCP report indicating a lost packet. But with the increasing number
of participants (say n*x), the interval gets bigger by n times
leading to fewer options of error repair mechanisms. In IP
multicast, the error resilience mechanisms like adaptive FEC,
retransmission can be performed only by the source or one designated
participant/observer. But in the case of overlay multicast, there
are more options available to deploy these mechanisms at intermediary
nodes which become an inherent part of the forwarding tree.
Furthermore, the importance of overlay operation increases with
increasing number of participants: the larger the number of nodes,
the greater the importance of overlay operation in maintaining
stability i.e., the importance of the reports that influence the
quality of the overlay operation grows.
The proportional relationship of number of nodes with the RTCP
reporting interval was designed to limit the bandwidth consumed by
the RTCP and provide scalability so as to evolve as a multicast
session with many number of participants. But in the overlay
multicast scenario, with the reducing number of reports per time unit
the quality of the overlay is reduced due to reduced effectiveness of
media and overlay operation.
Singh, et al. Expires September 9, 2012 [Page 8]
Internet-Draft RTCP in Overlay Multicast March 2012
In contrast to any-source multicast, however, the RTCP reports sent
by a particular node are not automatically received by all other
nodes. Instead, the RTCP reports travel along the virtual links
formed between participating nodes. This may be used to limit their
spread and may allow for mechanisms improving overall efficiency of
RTCP reporting.
Thus, while the total number of participants in an RTP session limits
the RTCP bandwidth consumption within 5% of the media session, this
limit may not need to be applied the total consumption across the
entire overlay multicast, but be maintained in local regions only.
8. Applicability of RTCP with unicast feedback target
If RTCP/SSM reporting mechanism is to be used in an overlay
multicast, then the RTCP RR reports are unicast to a designated node
that is either within or outside the overlay multicast. It is a form
of '1 to 1' reporting and here we discuss on its applicability in the
overlay multicast.
RTCP/SSM defines the use of a single distribution source in
conjunction with one or more feedback targets. If multiple feedback
targets are to be used, their respective setup and coordination is
outside the scope of the RTCP/SSM specification. Conceptually,
however, the RTCP/SSM mechanisms support the idea of hierarchical
report aggregation and forwarding, even though the RTP media as well
as the RTCP sender reporting distribution paths are supposed to use
SSM multicasting at the IP layer. This notion of RTCP aggregation
would need to become more explicit, but could provide a first basis
for realizing overlay multicast.
Overlay multicast also provides explicit support for using
intermediary (participating nodes in the distribution tree) media
error resilience mechanisms. Stepwise RTCP aggregation would also
make the necessary feedback information available to the individual
intermediate nodes and could thus provide the hook for invoking
repair mechanisms.
The (kind of) centralized reporting and centralized decision making
in RTCP/SSM would need to be expanded to allow for more flexible
media and/or overlay operation and, in particular, would need to
cover the assignment and maintenance of feedback targets as regular
part of the overlay operation.
An interesting issue is whether this source-specific type of
operation could be expanded later towards multi-source operation in
order to support any-source multicast overlays as well. While RTCP/
Singh, et al. Expires September 9, 2012 [Page 9]
Internet-Draft RTCP in Overlay Multicast March 2012
SSM seems to be a promising starting point, this latter step is left
for further study.
9. Desirable features of RTCP in overlay multicast
The following list is an initial set of desirable functions for
media/overlay operation:
o Need for a mechanism of RTCP reporting, where the reporting
interval is decoupled from the number of participants in the media
session. But still the original reason behind this linkage
(limiting the RTCP bandwidth consumption) can be maintained
through other suitable mechanisms. In essence, fine-granular RTCP
reporting could be confined to subgroups while the global
bandwidth limitation is still maintained.
o Overlay multicast brings in the option to use media operation at
intermediate nodes. With more frequent reporting, their
effectiveness increases. So, to increase the reporting frequency
and at the same time limit the bandwidth consumption, a RTCP RR
reporting mechanism that provides the feature of '1 to m'(n > m, n
- number of participants in the session) reporting is needed. By
choosing a small m, the RTCP RR reporting frequency can be
increased as it is directed only to a small subset of
participating nodes. Such subset reporting could be carried out
at a single hierarchy level inside an overlay multicast or across
multiple such levels.
o Media operation should be able to leverage the additionally
available reporting information to optimize performance (for error
control, possibly congestion control, etc.)
o Overlay operation can be either centralized or distributed. For
example, the decisions related to overlay operations can be made
only by a single node for the whole network or can be distributed
to many groups, with each groups making the decisions depending on
the collected metrics. In the later form of overlay operation,
the availability of '1 to m' reporting provides timely and more
precise information for the algorithms used in the overlay
operation. As each group can act independent from the other
groups, there may not be a need for reporting across the groups
but there may be a need for a higher reporting frequency within
the group.
10. An example explaining the issues
We take the below example for explaining the desired form of RTCP
reporting in overlay multicast.
Singh, et al. Expires September 9, 2012 [Page 10]
Internet-Draft RTCP in Overlay Multicast March 2012
o(0) -Media source
/ \
/ \
/ \
o(1) o(2)
/|\ /|\
/ | \ / | \
o o o o o o
(3)(5)(7) (4)(6)(8)
Figure 2: A sample overlay multicast topology
In the above figure, the nodes {1, 3, 5 and 7} and {2, 4, 6 and 8}
are considered as a group with node 1 and 2 acting as their
respective group leaders. The overlay operation involves changing
the group leader based on the metrics reported by the participating
nodes.
In the above example, the nodes {1, 3, 5 and 7} are more interested
in RTCP reports from the nodes within their group rather than in the
RTCP reports from {2 or 4 or 6 or 8}. If the RTCP reporting interval
is supposed to be proportional to the number of participants in the
session, then the individual groups see reduced reporting due to the
increase in the number of participants. This reduces the
effectiveness of both media and overlay operation.
The paper "Construction of an Efficient Overlay Multicast
Infrastructure for Real-time Applications" is an overlay multicast
solution, that dynamically re-arranges the distribution tree based on
the metrics reported(or measured with) 'm' other nodes.
(http://www.ieee-infocom.org/2003/papers/37_03.PDF)
11. Endpoint Reporting
For a Distribution Source (DS), RFC5760 [7] defines a feedback
reflection mechanism and a feedback summary mechanism (RSI). In the
case of overlay networks, each node forwards RTP packets and
therefore, also generates and receives RTCP packets. Therefore, each
node SHOULD also perform feedback reflection or summarization.
However, unlike the RFC5760 [7], where the DS transmits the resulting
feedback over the multicast RTCP channel, the intermediate node in an
overlay networks needs to transmit the feedback packets both upstream
and downstream. In the section, feedback information refers to
Receiver Reports or RSI, as the case may be. In a given setup the
feedback information between intermediate nodes and distribution
source MUST be consistent and the leaf nodes MUST always send RRs.
Singh, et al. Expires September 9, 2012 [Page 11]
Internet-Draft RTCP in Overlay Multicast March 2012
In this section, we describe the behavior of an intermediate node.
o Local Information: is the node's receiver report. Typically, this
information will be used to create summary reports (RSI) or
compounded with other reports (in case of feedback reflection).
The local information is always sent upstream to its parent node.
o Source Information: Feedback information received from an upstream
node is sent downstream. The node MUST add or summarize its local
information before transmitting it downstream.
o Sub-tree Information: Feedback information received from the child
nodes is summarized or reflected in both upstream and downstream
directions. The node need not add or summarize its local
information before transmitting the sub-tree information.
12. Hop-by-hop RTCP reporting
In an overlay network, the Sender Reports (SR) originate from the
source and percolate through the distribution tree to the leaf nodes.
Sinnce the intermediate nodes just forward RTP packets, they do not
generate SRs. Furthermore, they may either send RRs or RSIs
downstream, this information is insufficient to measure the
performance (of the links) between two consecutive intermediate
nodes. To assist with better performance measurements, each
intermediate node MUST generate an Intermediate Forwarder Report
(IFR) and send it to its parent and child nodes -- the IFR carries
loss and discard metrics, and NTP Timestamps for making RTT
measurements.
13. Packet Formats
TBD.
14. Security Considerations
TBD.
15. IANA Considerations
TBD
16. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Singh, et al. Expires September 9, 2012 [Page 12]
Internet-Draft RTCP in Overlay Multicast March 2012
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[3] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[4] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[5] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[6] Bhattacharyya, S., "An Overview of Source-Specific Multicast
(SSM)", RFC 3569, July 2003.
[7] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Sessions
with Unicast Feedback", RFC 5760, February 2010.
Authors' Addresses
Varun Singh
Aalto University
School of Electrical Engineering
Otakaari 5 A
Espoo, FIN 02150
Finland
Email: varun@comnet.tkk.fi
Jegadish Devadoss
Aalto University
School of Electrical Engineering
Otakaari 5 A
Espoo, FIN 02150
Finland
Email: jegadish@netlab.tkk.fi
Singh, et al. Expires September 9, 2012 [Page 13]
Internet-Draft RTCP in Overlay Multicast March 2012
Joerg Ott
Aalto University
School of Electrical Engineering
Otakaari 5 A
Espoo, FIN 02150
Finland
Email: jo@comnet.tkk.fi
Igor D.D. Curcio
Nokia
P.O. Box 88 (Tieteenkatu 1)
Tampere, FIN 33721
Finland
Email: igor.curcio@nokia.com
Singh, et al. Expires September 9, 2012 [Page 14]
