AVT Working Group                                            J. Devadoss
Internet-Draft                                                    J. Ott
Intended status: Informational         Helsinki University of Technology
Expires: April 30, 2009                                        I. Curcio
                                                                   Nokia
                                                        October 27, 2008


    Real-time Transport Control Protocol (RTCP) in Overlay Multicast
              draft-ott-avt-rtcp-overlay-multicast-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 30, 2009.

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, the suitability of RTCP in such an
   environment need to be analyzed.  The applicability of the existing
   RTCP reporting architectures in an overlay multicast environment is
   investigated and the new features that may be required are discussed
   in this document.





Devadoss, et al.         Expires April 30, 2009                 [Page 1]

Internet-Draft          RTCP in Overlay Multicast           October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overlay Multicast  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Classifying feedback reporting mechanism . . . . . . . . . . .  5
   5.  Applicability of RTCP reporting as defined in RFC 3550 . . . .  6
   6.  Applicability of RTCP with unicast feedback target . . . . . .  7
   7.  Desirable features of RTCP in overlay  . . . . . . . . . . . .  7
   8.  An example explaining the issues . . . . . . . . . . . . . . .  8
   9.  Some Questions . . . . . . . . . . . . . . . . . . . . . . . .  9
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 12



































Devadoss, et al.         Expires April 30, 2009                 [Page 2]

Internet-Draft          RTCP in Overlay Multicast           October 2008


1.  Introduction

   RTP [RFC3550] 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 porotocl
   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 [RFC3550] 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
   [RFC3556], but will generally be kep small to avoid impact the media
   streams.

   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) [RFC3569].
   Specific RTCP extensions were developed for SSM
   [I-D.ietf-avt-rtcpssm] 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
   [RFC3550]; the distribution source may RTCP RSI reports to control
   the rate at which RTCP reports are generated by the received.  The
   aforementioned rules for bandwidth modifications apply as well.

   Recent interest in overlay multicasting---to substitute for the lack
   of native IP any-source multicast---motivates also carrying RTP-based
   media streams in such environments.  In overlay multicast, the
   participants create virtual unicast links over which media streams
   are relplicated and forwarded, thus creating the illusion of IP
   multicast.  Depending on the abstraction chosen for such an overlay,
   the RTP/RTCP entities using it may or may not be aware of the hop-by-
   hop forwarding of the packets:




Devadoss, et al.         Expires April 30, 2009                 [Page 3]

Internet-Draft          RTCP in Overlay Multicast           October 2008


   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 mulicast 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 [RFC3550] 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.  The next revision of this document will also take the
   roles of RTP mixers and translators into consideration.  This
   document complements the RTP topologies overview [RFC5117].


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
   and Video Conferences with Minimal Control [RFC3551], and the RTCP
   Extension for SSM(add in reference), apply.

   For the time being, in this document, by overlay multicast we refer
   to a multicast overlay offering media distribution from a single
   source, analoguous to SSM.


3.  Overlay Multicast

   In overlay multicast, the media streams are multicast over an network
   of virtual links that is constructued 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



Devadoss, et al.         Expires April 30, 2009                 [Page 4]

Internet-Draft          RTCP in Overlay Multicast           October 2008


   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 congection 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
   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



Devadoss, et al.         Expires April 30, 2009                 [Page 5]

Internet-Draft          RTCP in Overlay Multicast           October 2008


   example of '1 to n' reporting is RTCP in multicast mode as specifed
   in RFC 3550.  In further secitons, we shall look into an example of
   each of the type and their applicability to the overlay multicast.


5.  Applicability of RTCP reporting as defined in RFC 3550

   If this reporting mechanism is to be used in an overlay multicast,
   then the RTCP reports are replicated and forwarded 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, the 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.  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.  In contrast to
   any-source multicast, however, the RTCP reports sent by a particular
   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.




Devadoss, et al.         Expires April 30, 2009                 [Page 6]

Internet-Draft          RTCP in Overlay Multicast           October 2008


   The precise mapping to RTP mixers and translators is yet to be
   defined.


6.  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 RTSP/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/
   SSM seems to be a promising starting point, this latter step is left
   for further study.


7.  Desirable features of RTCP in overlay

   The following list is an initial set of desirable functions for
   overlay operation:




Devadoss, et al.         Expires April 30, 2009                 [Page 7]

Internet-Draft          RTCP in Overlay Multicast           October 2008


   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.


8.  An example explaining the issues

   We take the below example for explaining the desired form of RTCP
   reporting in overlay multicast.













Devadoss, et al.         Expires April 30, 2009                 [Page 8]

Internet-Draft          RTCP in Overlay Multicast           October 2008


                          o(0) -Media source
                        /   \
                       /     \
                      /       \
                     o(1)      o(2)
                    /|\       /|\
                   / | \     / | \
                  o  o  o   o  o  o
                 (3)(4)(5) (6)(7)(8)

               Figure 1: A sample overlay multicast topology

   In the above figure, the nodes {1, 3, 4 and 5} and {2, 6, 7 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 this form overlay network, the media operation can also be
   performed by nodes other than source(for example nodes 1 and 2).

   In the above example, the nodes {1, 3, 4 and 5} are more interested
   in RTCP reports from the nodes within their group rather than in the
   RTCP reports from {6 or 7 or 8}.  So, if RTCP reporting interval is
   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.


9.  Some Questions

   o  Do the existing RTP entities suffice or need new ones be
      introduced?  For example, should an RTP Forwarder be defined as an
      entity performing functions of intermediate nodes?
   o  How are the individual regions (if any) for fine-grained reporting
      to be modeled?  Should they form separate RTP sessions or be just
      a part of the (single) regular session?
   o  Should RTCP flow only along the established multicast distribution
      tree (it may have to for NAT traversal reasons) or should more
      complex forms of reporting be supported?
   o  How will distribution along multiple trees be addressed?
   o  So far, we only worry about making RTP and RTCP work.  Should the
      overlay operation be considered at all?  As a minimum, the overlay
      operation could tap into information provided by RTCP anyway; as
      an intermediate step, RTCP could be expanded modestly to support
      certain types of overlay operation; at the other end of the
      spectrum, the overlay operation could rely on RTCP alone.





Devadoss, et al.         Expires April 30, 2009                 [Page 9]

Internet-Draft          RTCP in Overlay Multicast           October 2008


10.  Security Considerations

   TBD.


11.  IANA Considerations

   There are no specific IANA action necessary for this document.


12.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              July 2003.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
              July 2006.

   [RFC3556]  Casner, S., "Session Description Protocol (SDP) Bandwidth
              Modifiers for RTP Control Protocol (RTCP) Bandwidth",
              RFC 3556, July 2003.

   [RFC5117]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
              January 2008.

   [RFC3569]  Bhattacharyya, S., "An Overview of Source-Specific
              Multicast (SSM)", RFC 3569, July 2003.

   [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.









Devadoss, et al.         Expires April 30, 2009                [Page 10]

Internet-Draft          RTCP in Overlay Multicast           October 2008


Authors' Addresses

   Jegadish Devadoss
   Helsinki University of Technology
   Otakaari 5 A
   Espoo, FIN  02150
   Finland

   Email: jegadish@netlab.tkk.fi


   Joerg Ott
   Helsinki University of Technology
   Otakaari 5 A
   Espoo, FIN  02150
   Finland

   Email: jo@netlab.hut.fi


   Igor D.D. Curcio
   Nokia
   P.O. Box 88 (Tieteenkatu 1)
   Tampere, FIN  33721
   Finland

   Email: igor.curcio (at) nokia.com
























Devadoss, et al.         Expires April 30, 2009                [Page 11]

Internet-Draft          RTCP in Overlay Multicast           October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Devadoss, et al.         Expires April 30, 2009                [Page 12]