Internet DRAFT - draft-montagud-avtcore-eed-rtcp-idms

draft-montagud-avtcore-eed-rtcp-idms







Internet Engineering Task Force                         M. Montagud, Ed.
Internet-Draft                                                F. Boronat
Intended status: Standards Track                                     UPV
Expires: August 13, 2015                                     H. Stokking
                                                                     TNO
                                                        February 9, 2015


         Early Event-Driven (EED) RTCP Feedback for Rapid IDMS
                draft-montagud-avtcore-eed-rtcp-idms-00

Abstract

   RFC 7272 defines two RTCP messages to enable Inter-Destination Media
   Synchronization (IDMS).  However, if such RTCP messages are exchanged
   using the Regular RTCP reporting rules specified in RFC 3550,
   unacceptable delays can be originated when exchanging the
   synchronization information conveyed into RTCP packets.  Accordingly,
   this document proposes Early Event-Driven (EED) RTCP reporting rules
   and messages to enable higher interactivity, dynamism, flexibility
   and accuracy when using RTP/RTCP for IDMS.  Such IDMS extensions are
   targeted at providing faster reaction on dynamic situations, such as
   out-of-sync situations and channel change delays, as well as a finer
   granularity for synchronizing media-related events, while still
   adhering to the RTCP bandwidth bounds specified in RFC 3550.
   Besides, a new RTP/AVPF transport layer feedback message is proposed
   to allow the request of re-IDMS setting instructions (e.g., in case
   of RTCP packet loss) as well as rapid accommodation of latecomers in
   on-going sessions.  Finally, this document also discusses various
   situations in which the reporting of Reduced-Size RTCP packets (RFC
   3556) can be applicable and beneficial for IDMS.

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 August 13, 2015.



Montagud, et al.         Expires August 13, 2015                [Page 1]

Internet-Draft              EED RTCP for IDMS              February 2015


Copyright Notice

   Copyright (c) 2015 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
   (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.

   This document may not be modified, and derivative works of it may not
   be created, and it may not be published except as an Internet-Draft.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  RTP/RTCP for IDMS (RFC 7272)  . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Background: RTCP Reporting Rules  . . . . . . . . . . . . . .   7
     3.1.  Regular RTCP Feedback (RFC 3550)  . . . . . . . . . . . .   7
     3.2.  Early RTCP Feedback (RFC 4585)  . . . . . . . . . . . . .   9
     3.3.  Rapid Synchronization of RTP Flows (RFC 6051) . . . . . .  10
     3.4.  SDP Modifiers for RTCP Bandwidth (RFC 3556) . . . . . . .  11
   4.  Early Event-Driven (EED) RTCP Feedback for IDMS . . . . . . .  12
     4.1.  Immediate Initial RTCP IDMS Settings  . . . . . . . . . .  12
     4.2.  Dynamic EED Reporting of IDMS Settings  . . . . . . . . .  13
     4.3.  Rapid (Re-)Synchronization Request  . . . . . . . . . . .  16
     4.4.  Reduction of Channel Change Delays  . . . . . . . . . . .  18
   5.  Reduced-Size RTCP Reporting for IDMS  . . . . . . . . . . . .  20
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  23
   9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  23
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     10.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24









Montagud, et al.         Expires August 13, 2015                [Page 2]

Internet-Draft              EED RTCP for IDMS              February 2015


1.  Introduction

   RTP (Real-Time Transport Protocol) and RTCP (RTP Control Protocol)
   protocols provide support for both intra-media and inter-media
   synchronization [RFC3550].  Moreover, [RFC7272] extends the RTP/RTCP
   capabilities to also enable Inter-Destination Media Synchronization
   (IDMS).

   However, if the proposed RTCP messages for IDMS in [RFC7272] are
   exchanged using the Regular RTCP reporting rules specified in
   [RFC3550], this can lead to unnaceptable performance in some delay-
   sensitive applications requiring stringent synchronization
   requirements [Montagud2012].  This is because the RTCP packets are
   exchanged in a pre-scheduled and inflexible manner, uniquely based on
   preserving the allowed traffic bounds specified in [RFC3550].  There
   is no support for timely feedback that would allow to repair or to
   manage dynamic events of interest close to their occurrence.
   Accordingly, there may be a variable time lag (from few seconds to
   several minutes in large-scale environments) between detecting an
   event (e.g., an out-of-sync situation) and being able to send an
   appropriate RTCP packet to handle it.  Moreover, the RTCP reports may
   even not be received at the target side, since RTCP is sent over UDP,
   which does not provide a reliable control channel.

   This document proposes further extensions to RTP/RTCP to allow for a
   more strategic and efficient usage of the RTCP channel for IDMS.  In
   particular, the RTCP extensions from [RFC4585] and [RFC6051]
   encourage the specification of novel RTCP reporting rules and
   messages, which in conjunction we call Early Event-Driven (EED) RTCP
   Feedback for IDMS, to enable higher interactivity, dynamism,
   flexibility and accuracy when using RTP/RTCP for IDMS.  Such IDMS
   extensions are backward compatible with the solution specified in
   [RFC7272], while still adhering to the RTCP traffic bounds specified
   in [RFC3550].

   More specifically, the proposed EED RTCP Feedback for IDMS provides
   the following key benefits: i) earlier correction of out-of-sync
   situations; ii) higher granularity for synchronizing the presentation
   of dynamically triggered media-related events (e.g., to ensure that
   important pieces of media content are simultaneously watched by all
   the users); iii) ability of dynamically requesting IDMS setting
   instructions (e.g., in case of RTCP packet loss); iv) dynamic and
   rapid accommodation of latecomers in on-going sessions; and v)
   reduction of channel-change (i.e., zapping) delays.  Additionally,
   this document also discusses various situations in which the
   reporting of Reduced-Size RTCP packets [RFC3556] can be applicable
   and beneficial for IDMS.




Montagud, et al.         Expires August 13, 2015                [Page 3]

Internet-Draft              EED RTCP for IDMS              February 2015


   The proposed RTCP extensions for IDMS in this document are applicable
   to and can have a potentially high impact on a wide spectrum of
   scenarios with demanding IDMS characteristics [Montagud2012], such as
   Social TV, multi-party conferencing, and synchronous e-learning.

   A preliminary evaluation of such proposals can be found in
   [Montagud2013].

1.1.  RTP/RTCP for IDMS (RFC 7272)

   IDMS refers to the playout of media streams at two or more
   geographically distributed locations in a time-synchronized manner.
   A large number of applications requiring IDMS can be found in
   [Montagud2012].  Some relevant examples are: Social TV, multi-party
   conferencing, networked loudspeakers and networked multi-player
   games.

   [RFC7272] extends the RTP/RTCP mechanisms to exchange useful feedback
   information for IDMS between Synchronization Clients (SC) and a
   centralized Media Synchronization Application Server (MSAS).  First,
   an RTCP XR block for IDMS, called "IDMS report", is defined to enable
   the SCs to report on packet reception and/or presentation times for a
   specific RTP stream.  Second, a new RTCP IDMS packet type, called
   "IDMS Settings packet", is defined to allow the MSAS the transmission
   of IDMS setting instructions to the distributed SCs, based on the
   collected IDMS timings from them.  This IDMS Settings packet will
   provide a common target playout point, referred to a specific RTP
   packet (concretely, to its generation timestamp) to which all the SCs
   belonging to a specific synchronization group (identified by the
   SyncGroupId field, specified in [RFC7272]) must synchronize.
   Besides, a new Session Description Protocol (SDP) parameter, called
   "rtcp-idms", is defined to notify about the usage of the above IDMS
   messages and to manage the group membership, thus allowing the co-
   existence of various independent groups of users in IDMS-enabled
   sessions.

   Figure 1 shows the architectural solution for IDMS adopted in
   [RFC7272], wich is based on a sync-maestro scheme [Montagud2012].  In
   this particular case, the SCs are co-located with RTP Receivers and
   the MSAS is co-located with the RTP Sender (although it could be co-
   located with an SC or with a third-party entity).  The MSAS is
   responsible for collecting the IDMS reports from all the SCs
   belonging to a specific group, computing the delay differences among
   them and, if needed, sending IDMS Settings packets to make them to
   enforce the required adjustments to achieve IDMS.  Although other
   architectural solutions are feasible, such as a distributed or a
   master/slave scheme [Montagud2012], this document also focuses on the
   sync-maestro scheme.



Montagud, et al.         Expires August 13, 2015                [Page 4]

Internet-Draft              EED RTCP for IDMS              February 2015


    +-----------------------+                 +-----------------------+
    |                       |                 |                       |
    |      RTP Sender       |                 |     RTP  Receiver     |
    |                       |    RTCP RR +    |                       |
    |  +-----------------+  |   XR for IDMS   |  +-----------------+  |
    |  |                 |  | <-------------- |  |                 |  |
    |  |     Media       |  |                 |  |                 |  |
    |  | Synchronization |  |                 |  | Synchronization |  |
    |  |   Application   |  |                 |  |      Client     |  |
    |  |     Server      |  |    RTCP SR +    |  |       (SC)      |  |
    |  |     (MSAS)      |  | IDMS Settings   |  |                 |  |
    |  |                 |  | --------------> |  |                 |  |
    |  +-----------------+  |                 |  +-----------------+  |
    |                       |                 |                       |
    +-----------------------+                 +-----------------------+


                        Figure 1: IDMS Architecture

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 RFC 2119 [RFC2119].

   The terminology defined in "RTP: A Transport Protocol for Real-Time
   Applications" [RFC3550], "Extended RTP Profile for Real-time
   Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"
   [RFC4585], "Rapid Synchronisation of RTP Flows" [RFC6051], and in
   "RTCP for Inter-Destination Media Synchronization" [RFC7272], apply.

   The naming convention for RTCP is sometimes confusing.  Below is a
   list of RTCP related terms and their meaning.  Those concepts were
   defined in [RFC3550], [RFC4585], and [RFC5506], but refreshed here
   for a better understanding of this document:

   o  RTCP packet: There are different types of RTCP packets, each one
      reporting on a specific metric or event of interest.  It consists
      of a fixed header part followed by structured fields or elements
      depending on the information conveyed in that RTCP packet type.

   o  Regular RTCP mode: Mode of operation in which no preferred
      transmission of feedback messages is allowed.  Instead, RTCP
      packets are sent following the rules specified in [RFC3550].

   o  Regular RTCP packet: RTCP packet that is sent using Regular RTCP
      mode.




Montagud, et al.         Expires August 13, 2015                [Page 5]

Internet-Draft              EED RTCP for IDMS              February 2015


   o  Event: An observation that is (potentially) of interest to the
      participants of a media session and thus useful to be reported by
      means of an RTCP feedback message in a timely fashion.

   o  Regular RTCP packet: RTCP packet that is sent using Regular RTCP
      mode.

   o  Early RTCP mode: Mode of operation in which a participant is
      capable of reporting events of interest in a timely fashion (i.e.,
      close to their occurrence).

   o  Early RTCP packet: RTCP packet that is transmitted earlier than
      the scheduled transmission time when following the reporting rules
      specified in [RFC3550].  In [RFC4585], Early RTCP packets may be
      sent either as "Immediate Feedback" or as "Early RTCP" modes,
      depending on the group size.  In the context of this document,
      Early RTCP packets are sent by the MSAS, which is a single
      centralized entity.  Therefore, no dithering interval is needed to
      avoid feedback implosion, and RTCP packets can be sent in an
      "Immediate Feedback" mode.  Sending an Early RTCP packet is also
      referred to as sending Early Feedback in this document.

   o  Compound RTCP packet: A collection of two or more RTCP packets.
      In [RFC3550], it is mandatory to send RTCP packets as compound
      packets including at least an RTCP RR or SR packet, followed by an
      SDES packet with the CNAME item for the transmitting source
      identifier.  Often the term "compound" is left out, so the
      interpretation of RTCP packet is therefore dependent on the
      context.

   o  Minimal compound RTCP packet: A compound RTCP packet that contains
      only mandatory information, such as encryption prefix (if
      necessary), exactly one RTCP RR or SR packet, exactly one SDES
      packet with the CNAME item, and possible additional Feedback
      Messages [RFC4585] that must be sent as an Early RTCP packet.

   o  (Full) Compound RTCP packet: A compound RTCP packet that conforms
      to the requirements on minimal compound RTCP packets and contains
      any additional number of RTCP packets (additional RRs, further
      SDES items, etc.).  RTCP compound packets are typically sent when
      using Regular RTCP Feedback [RFC3550], although they may be also
      sent when using Early RTCP Feedback [RFC4585].

   o  Reduced-Size RTCP packet: It only contains one or more RTCP
      packets, being much smaller than (minimal and full) compound RTCP
      packets [RFC3550].  Such RTCP packets are sent when using Early
      RTCP Feedback, but must not be sent when using Regular RTCP
      Feedback.  The full definition is in Section 4.1 of [RFC5506].



Montagud, et al.         Expires August 13, 2015                [Page 6]

Internet-Draft              EED RTCP for IDMS              February 2015


   Besides, the definition of three key concepts will help understanding
   (the proposed IDMS extensions in) this document:.

   o  Inter-Stream Synchronization Delay (or Latency): It refers to the
      time difference between the instant at which a user joins an on-
      going multimedia session, probably involving different media
      (e.g., audio and video, or when using layered and/or multi-
      description media) carried in separate streams, and the instant at
      which these correlated streams can be presented to that user in a
      synchronized manner.  It is defined in [RFC6051].

   o  IDMS Delay (or Latency): It refers to the time difference between
      the instant at which an IDMS-related event occurs (e.g., a user
      joins an on-going session or an out-of-sync situation is detected)
      and the instant at which the IDMS Setting instructions to handle/
      repair such event have been received and processed at the target
      side/s or SCs.

   o  Latecomer: In multi-party multimedia services, users may join and
      leave the session quite frequently.  A user who joins a session in
      progress is usually called a latecomer (or late joiner) [RFC6051].

3.  Background: RTCP Reporting Rules

   In this section, an overview of the RTCP reporting rules is provided.
   This is important to help understanding the benefits of the RTCP
   reporting rules and reports proposed in this document.

3.1.  Regular RTCP Feedback (RFC 3550)

   During the media session's lifetime, the participants of an RTP
   Session (i.e., senders and receivers) regularly exchange RTCP reports
   (typically conveyed into compound RTCP packets) to inform mainly
   about QoS (Quality of Service) statistics, either in a unicast or
   multicast way (depending on the specific networked environment).  On
   the one hand, a low frequency of RTCP feedback reporting can lead to
   faulty behavior due to outdated statistics.  On the other hand,
   excessive reports can be redundant and cause unnecessary control
   traffic, probably leading to potential congestion situations.

   Also, if the RTCP packets were exchanged at a constant rate, the
   control traffic would grow linearly with the number of participants.
   Accordingly, a trade-off between up-to-date information and the
   amount of control traffic must be met.  This would allow an
   application to (automatically) scale over session sizes ranging from
   few participants to tens of thousands.





Montagud, et al.         Expires August 13, 2015                [Page 7]

Internet-Draft              EED RTCP for IDMS              February 2015


   The total amount of control traffic added by RTCP should be limited
   to a small (so that the primary function of media data transport is
   not impaired) and known (so that each participant can independently
   calculate its share) fraction of the allocated RTP session bandwidth.
   A fraction of 5 % is recommended in [RFC3550].  In such process,
   media senders are given special consideration to allow a more
   frequent report exchange of their RTCP statistics, some of which are
   indeed very relevant for multimedia synchronization.  In particular,
   if the proportion of senders constitute less than one quarter of the
   session membership, this percentage is further divided into two
   parts, where 25 % must be dedicated to active senders and the
   remaining can be consumed by receivers.  Otherwise, the RTCP
   bandwidth is equally shared between senders and receivers.

   Based on the above aspects, the RTCP report interval is dynamically
   and locally computed in each RTP entity, every time an RTCP packet is
   sent, according to the available session bandwidth, the average size
   of all received and sent RTCP packets, the number of participants in
   the session, their role (senders or receivers), as well as the
   unicast or multicast nature of the session (see Section 6.2 of
   [RFC3550] for further details).

   This (deterministically) calculated RTCP report interval should also
   have a lower bound to avoid having bursts (cumpling) of RTCP packets
   when the number of participants is small and the law of large numbers
   is not helping to smooth out the traffic overhead.  This would also
   help to avoid excessive frequent reports during transient outages
   like a network partition.  The recommended value in [RFC3550] for
   that fixed minimum interval is 5 s.

   Besides, a delay should be imposed to each participant before sending
   the first RTCP packet upon joining the session.  This allows a
   quicker convergence of the RTCP report interval to the correct value.
   This initial delay may be set to half the minimum RTCP report
   interval (i.e., 2.5 s) in multicast sessions, whilst it may be set to
   zero in unicast sessions.

   In some cases (e.g. if the data rate is high and the application
   demands more frequent RTCP reports), an implementation may scale the
   minimum RTCP interval to a smaller value given by 360 divided by the
   session bandwidth (in kbps).  This yields to an interval smaller than
   5 s when the session bandwidth becomes greater than 72 kbps.  In
   multicast sessions, only active senders may use that reduced minimum
   interval, whilst in unicast sessions it also may be used by
   receivers.  In the above cases, however, the minimum interval of 5 s
   must be still taken into account during the membership accounting
   procedure to not prematurely time out participants (who can indeed be
   using it) because of inactivity.



Montagud, et al.         Expires August 13, 2015                [Page 8]

Internet-Draft              EED RTCP for IDMS              February 2015


   After that, the interval between RTCP packets is varied randomly over
   the range [0.5, 1.5] times that RTCP report interval to prevent
   floods of RTCP reports (i.e., to avoid that all RTCP packets are sent
   and received almost at the same time, in every report interval).

   Additionally, "timer reconsideration" algorithms are introduced to
   allow for a more rapid adaptation of the RTCP report interval in
   large-scale sessions, where the membership can largely vary (e.g.,
   many receivers join and leave the session quite frequently).  To
   compensate for the fact that the "timer reconsideration" algorithms
   converge to a lower value than the intended average RTCP bandwidth,
   the (randomized) report interval is finally divided by e-3/2=1.21828.

3.2.  Early RTCP Feedback (RFC 4585)

   In [RFC4585], further RTCP reporting mechanisms are specified to
   enable receivers to provide, statistically, more immediate RTCP
   feedback to the senders.  This Early RTCP Feedback profile, which is
   known as RTP Audio-Visual Profile with Feedback (RTP/AVPF), allows
   for short-term adaptation and efficient feedback-based repairing
   mechanisms to be implemented, while maintaining the RTCP bandwidth
   constraints and preserving scalability to large groups.

   The RTCP report interval specified in [RFC3550] is denoted as Regular
   RTCP interval in [RFC4585].  In addition, [RFC4585] enables to send
   RTCP reports earlier that the next scheduled Regular RTCP
   transmission time if a receiver detects the need to inform about
   media stream related events (e.g., picture or slice loss) close to
   their occurrence.

   [NOTE] A feedback suppression mechanism is adopted, in which
   receivers wait for a random dithering interval to avoid feedback
   implosion (i.e., lots of receivers reporting on the same event).

   The reporting rules for Regular RTCP packets in [RFC4585] are similar
   than the ones in [RFC3550].  However, the recommended minimum RTCP
   report interval of 5 s in [RFC3550] is dropped in [RFC4585].
   Instead, an optional attribute, called "trr-int", is specified as an
   offset parameter (in ms) to the computed Regular RTCP Report
   interval.

   Note that providing "trr-int" as an independent variable is intended
   to restrain from sending too frequent Regular RTCP packets (i.e.,
   saving RTCP bandwidth) while enabling higher flexibility to transmit
   Early RTCP packets (i.e., using the saved RTCP bandwidth) in response
   to dynamic events.  This could not be achieved by reducing the
   overall RTCP bandwidth, because the frequency of Early RTCP packets
   would be affected as well.  Values between 4 and 5 s for "trr-int"



Montagud, et al.         Expires August 13, 2015                [Page 9]

Internet-Draft              EED RTCP for IDMS              February 2015


   are recommended to assure interworking with RTP entities only using
   Regular RTCP Feedback.  However, as "trr-int" is an optional
   attribute, it may be set to zero (default value) if a specific
   application would benefit from a higher frequency of Regular RTCP
   packets.  In such a case, the only difference between the RTCP timing
   rules from [RFC3550] and [RFC4585] for transmitting Regular RTCP
   packets resides in the minimum value for the report interval, which
   is dropped in [RFC4585].

   In order to preserve the RTCP traffic bounds, only one Early RTCP
   packet can be transmitted between two consecutive Regular RTCP
   packets (i.e. receivers cannot send two consecutive Early RTCP
   packets).  After sending an Early RTCP packet, the RTCP reporting
   engine must schedule the transmission time for the next RTCP packet
   by skipping the next Regular RTCP interval.

   Furthermore, [RFC4585] defines a small number of general-purpose
   feedback messages as well as a format for codec- and application-
   specific feedback information for transmission in the RTCP payloads.

3.3.  Rapid Synchronization of RTP Flows (RFC 6051)

   When using RTP streaming, the inter-stream synchronization delay can
   greatly increase in certain scenarios, especially in large multicast
   groups or when Multipoint Conference Units (MCU) are involved in the
   media delivery process.  This increase of delay can be inacceptable
   and annoying to users, resulting in an overall poor Qualilty of
   Experience (QoE).

   The aim of [RFC6051] is to minimize the inter-stream synchronization
   delay when using RTP/RTCP-based streaming.  The motivation is that a
   receiver cannot synchronize playout of the incoming media streams
   until compound RTCP packets, including a Source Description or SDES
   packet (including the media source identification) and a Sender
   Report or SR (including timing correlation parameters), are received
   for all the involved RTP senders in a multimedia session.  In most
   implementations, media data will not be played out (watched or
   listened) until inter-stream synchronization is (initially) achieved.
   If there is no packet loss, this gives an expected delay equal to the
   average time for receiving the first RTCP packet from the RTP Session
   with the longest RTCP report interval.  This delay is even more
   problematic if an RTCP SR packet from one of the involved RTP
   sessions is lost.

   [NOTE] Note that the inter-stream synchronization delay depends on
   the specific instant at which a user joins the multimedia session or
   each RTP session (e.g., the user may first receive the RTCP packets
   from the RTP session with the longest RTCP interval), as well as on



Montagud, et al.         Expires August 13, 2015               [Page 10]

Internet-Draft              EED RTCP for IDMS              February 2015


   the impact of the randomization processes in all the involved RTP
   sessions.

   In [RFC6051], three backward compatible extensions to the RTP/RTCP
   protocols are proposed to reduce the inter-stream synchronization
   delay.  First, the RTCP timing rules are updated to allow Single
   Source Multicast (SSM) senders [RFC5760] the immediate transmission
   of an initial compound RTCP packet upon joining each RTP session in a
   multimedia session (in parallel with the initial RTP packets).  The
   rationale for not allowing the transmission of immediate RTCP packets
   to SSM receivers is to avoid feedback implosion in case that many
   receivers join the session almost simultaneously ("flash crowd"
   effect).  This is clearly not an issue for SSM senders, since there
   can be at most one sender.  Likewise, feedback implosion is a concern
   for Any Source Multicast (ASM) sessions, so [RFC6051] does not
   propose changes to the RTCP timing rules in these kinds of multicast
   environments.  Second, a new RTP/AVPF transport layer feedback
   message (this type of RTCP messages is defined in [RFC4585]), called
   RTCP-SR-REQ, is defined to allow requesting the generation of an
   Early RTCP SR packet from the media sender.  This enables rapid
   (re-)synchronization in case that an RTCP SR has not been received
   for a long period (e.g. due to packet loss or in sessions with large
   RTCP reporting intervals).  Likewise, this enables latecomers to
   achieve inter-stream synchronization as soon as possible upon joining
   the session.  Finally, new RTP header extensions are defined to
   enable the inclusion of metadata (in particular, NTP-based
   timestamps) in RTP data packets for in-band synchronization, thus
   avoiding the need for receiving RTCP SR packets before streams can be
   synchronized.  These RTP header extensions do not eliminate the need
   for RTCP SR messages, but both mechanisms must be used for the
   synchronization control process.  The use of RTCP SR packets for
   inter-stream synchronization allows backwards compatibility, but also
   provides higher robustness in the presence of middle boxes (e.g., RTP
   translators) that might strip RTP header extensions.

   An accurate and rapid inter-stream synchronization is especially
   relevant when using layered, multi-description and multi-view media
   encodings.  This is because all the individual RTP streams need to be
   synchronized before starting the decoding processes.

3.4.  SDP Modifiers for RTCP Bandwidth (RFC 3556)

   In some applications, it may be appropriate to specify the RTCP
   bandwidth independently of the allocated RTP session bandwidth.
   Accordingly, [RFC3556] defines two additional Session Description
   Protocol (SDP) attributes to specify modifiers for the RTCP bandwidth
   for senders and receivers.




Montagud, et al.         Expires August 13, 2015               [Page 11]

Internet-Draft              EED RTCP for IDMS              February 2015


   On the one hand, using a separate parameter allows rate-adaptive
   applications to set an RTCP bandwidth consistent with a "typical"
   data bandwidth that is lower than the maximum bandwidth specified by
   the session bandwidth parameter.  This allows the RTCP bandwidth to
   be kept under 5% of the session bandwidth when the rate has been
   adapted downward, e.g. based on the stability of the network
   conditions.  On the other hand, there may be applications that send
   data at very low rates, but need to communicate quite frequent RTCP
   information.  These applications may need to specify an RTCP
   bandwidth that is higher than 5% of the data bandwidth.

   If any of the SDP attributes for the RTCP bandwidth modifiers are
   omitted, the default value for that parameter is the one specified in
   the RTP profile in use for the session.  [RFC3556] does not impose
   limits on the values that may be specified for both RTCP bandwidth
   modifiers, other than that they must be non-negative.  However, the
   RTP specification and the appropriate RTP profile may specify limits.

4.  Early Event-Driven (EED) RTCP Feedback for IDMS

   This section introduces the EED RTCP reporting mechanisms proposed in
   this document to enable higher flexibility, dynamism, interactivity
   and accuracy when using RTP/RTCP for IDMS, with a sync-maestro
   architecture.

4.1.  Immediate Initial RTCP IDMS Settings

   [RFC6051] relaxes the timing rules for unicast and layered sessions
   so that SSM senders are allowed to transmit an initial compound RTCP
   packet (containing an RTCP SR packet and an RTCP SDES packet with a
   CNAME item) immediately on joining each RTP session in a multimedia
   session, in parallel with the initial RTP data packets.  Hence, the
   inter-stream synchronization delay is significantly reduced, provided
   that the initial RTCP packet is not lost.

   The same rationale for reducing the inter-stream synchronization
   delay in [RFC6051] can also be extrapolated to IDMS.  In such a case,
   it would also be desirable the transmission of a nearly-immediate
   RTCP IDMS Settings packet by the MSAS upon establishing a multimedia
   session.

   [NOTE]: Note that in this document, the terms (nearly-)immediate,
   close-to-instant and Early are used as synonymous.  This is because
   the MSAS is a single centralized entity in the media session, and the
   Early RTCP packets can be sent immediately by this entity without
   requiring a contention algorithm, as required for receivers in
   [RFC4585].




Montagud, et al.         Expires August 13, 2015               [Page 12]

Internet-Draft              EED RTCP for IDMS              February 2015


   If the MSAS is integrated within the RTP Server, it MUST send the
   IDMS Settings packet in parallel with the initial RTP data packets.
   If the Sync Manager is co-located within a SC or a third party entity
   (that also needs to be an RTP receiver for that session), it MUST
   send the IDMS Settings packet as soon as it receives the initial RTP
   data packets from the RTP Sender.  In either case, as the MSAS is a
   single centralized RTP entity, it is also allowed to transmit Early
   RTCP packets [RFC6051].  This way, the SCs can start consuming the
   media in a synchronized manner earlier, thus ensuring a reduction of
   the IDMS Delay.

   This mechanism is purely a local change to the MSAS that can be
   implemented as a configurable option, as stated in [RFC6051].

4.2.  Dynamic EED Reporting of IDMS Settings

   During the media session's lifetime, if Regular RTCP Feedback is
   used, the MSAS may have to wait a nearly-complete RTCP reporting
   interval to be able to send a new compound RTCP packet (including an
   IDMS Settings packet) after detecting an out-of-sync situation, which
   might potentially take several seconds (up to 5 s or even more)
   [RFC3550].

   This is illustrated in Figure 2.  In such a case, if an event (e.g.
   out-of-sync situation) is detected just after the transmission of an
   RTCP packet (at instant t_r1), the next RTCP packet cannot be sent
   until the next randomized (over the scheduled transmission instant,
   t_d2) RTCP transmission time (at instant t_r2).  The figure shows the
   worst case, in which the randomized RTCP report interval at that
   moment is near the upper limit, i.e.:.

   (t_r2 - t_r1) = 1.5 * (t_d2 - t_r1)



















Montagud, et al.         Expires August 13, 2015               [Page 13]

Internet-Draft              EED RTCP for IDMS              February 2015


       R A N D O M    I N T E R V A L S --> [0.5;1.5]*[t_d(n)- t_d(n-1)]
            ____/\____       ____/\____         ____/\____
           /          \     /          \       /          \
                 t_r1                t_r2        t_r3
                   |                   |           |
                   |                   |           |
   |-------(---&-|-+-o-)----(-----|----+)----#-(---+-|-----)------>
   |           | |   |            |          |       |        Time
   |       Event |   Event is     |       Event is   |
   |      Occurs |   Detected     |      Handled or  |
  t_d0          t_d1            t_d2      Repaired  t_d3
   \_____  _____/   \_____  _____/      \_____  _____/
         \/               \/                  \/
    S C H E D U L E D   R T C P   R E P O R T   I N T E R V A L S
   \______  ______/\________  _________/\____  ____/
          \/                \/               \/
   R A N D O M I Z E D   R T C P   R E P O R T   I N T E R V A L S
               \_  _/\______  _______/\_  _/
                 \/         \/          \/
                 DD      M S A S        AD
                        D E L A Y
               \_____________  ____________/
                             \/
   I D M S   D E L A Y   (R E G U L A R  R T C P   I N T E R V A L)


                    Figure 2: Regular RTCP Timing Rules


          Legend
          -------
        &    Event Occurs
        O    Event is detected
        #    Event is handled/repaired
      (   )  Random Interval
        |    t_d(n): Scheduled (Deterministic) RTCP Transmission Times
        +    t_r(n): Real (Randomized) RTCP Transmission Times
        X    RTCP Transmission Restriction (Cancellation)
       DD    Detection Delay
       AD    Adjustment Delay


                             Figure 3: Legend

   Therefore, the contribution of the MSAS delay (i.e., the time
   interval since an event is detected and an IDMS Settings packet to
   handle or to repair it is transmitted) to the total IDMS Delay
   becomes a serious barrier for those use cases requiring stringent



Montagud, et al.         Expires August 13, 2015               [Page 14]

Internet-Draft              EED RTCP for IDMS              February 2015


   synchronization levels (e.g., networked loudspeakers, or networked
   games) [Montagud2012].

   Accordingly, the MSAS is also allowed to dynamically send Early RTCP
   IDMS Settings packets once detecting events throughout the duration
   of the media session.  This is illustrated in Figure 4.  In such a
   case, an RTCP IDMS Settings packet is sent just after the detection
   of an event, despite that this moment moment is earlier than the next
   regular RTCP transmission time.  Consequently, the IDMS Delay is
   significantly reduced, mainly due to the fact that the MSAS delay has
   been minimized (due to the inmediate transmission of the IDMS
   Settings packet).


    R A N D O M    I N T E R V A L S --> [0.5;1.5]*[t_d(n)- t_d(n-1)]
              ____/\____       ____/\____         ____/\____
             /          \     /          \       /          \
               t_r1 t_r2             Skipped    t_r3
                 |   |     Handled       |       |
                 |   |         |         |       |
     |-------(---&-|-+-o+)----(#----|----x)------(---+-|-----)------>
     |           | |   |            |                  |       Time
     |       Event |   Event is     |                  |
     |      Occurs |   Detected     |                  |
    t_d0          t_d1            t_d2                t_d3
     \_____  _____/   \_____  _____/      \_____  _____/
           \/               \/                  \/
      S C H E D U L E D   R T C P   R E P O R T   I N T E R V A L S
     \______  ______/|_ _|\____________  ____________/
            \/         |               \/
     E V E N T ? D R I V E N   R T C P   R E P O R T   I N T E R V A L S
                       |_|
                        |
               M S A S   D E L A Y
                 \_____  _____/
                       \/
   I D M S   D E L A Y (E E D   R T C P    I N T E R V A L)



           Figure 4: Early Event-Driven (EED) RTCP Timing Rules

   Note that if "trr-int" is set to zero, only one Early RTCP packet can
   be transmitted between two consecutive Regular RTCP packets to
   preserve the RTCP traffic bounds [RFC3550].  It means that an Early
   RTCP packet can only be sent if the previous transmitted RTCP packet
   was a Regular RTCP packet.  Hence, after sending an Early RTCP
   packet, the RTCP reporting engine MUST schedule the sending time for



Montagud, et al.         Expires August 13, 2015               [Page 15]

Internet-Draft              EED RTCP for IDMS              February 2015


   the next RTCP packet by delaying (i.e., skipping) one more Regular
   RTCP report interval, as in [RFC4585].

   In case of high frequency of events, setting an offset value for the
   Regular RTCP report interval, by means of using the "trr-int"
   attribute, can help to save RTCP bandwidth (by restraining the
   transmission of too frequent Regular RTCP packets) while being able
   to use the (saved) bandwidth when events occur.  This is out of scope
   of this document.

   Therefore, the proposed EED RTCP reporting rules are based on the
   fact that not all the feedback reports from the MSAS are of equal
   importance.  This means that some feedback reports from the MSAS need
   to be reported in a timely fashion.

   The dynamic EED reporting of IDMS Settings packets is also be very
   useful to provide playout hints for specific events that must be
   presented to all the involved users in a fine-grained synchronized
   way with the piece of content they refer to.  Those events can be
   media-related events whose timing can be known in advance (e.g.,
   commercials, start of the match in a sports event...), but the
   events' timing could be even unknown (e.g., a goal in a football
   match...) or dynamically triggered by either operators (e.g., a TV
   quiz show, in-game actions, interesting scenes...) or users (e.g.,
   shared service control, interactive instant messaging...).
   Therefore, the use of EED RTCP Feedback for IDMS implies an
   interaction between the application-layer (through which operator or
   user generated events are triggered) and the transport/control layer
   (i.e., RTP/RTCP protocols) in order to translate the high-level
   (i.e., content-based or action-based) events into lower level calls
   (i.e., transmission of Early RTCP packets), as well as their
   alignment in terms of timelines.  These are not severe issues, since
   the MSAS will be co-located with the Media Sender in most
   implementations.  However, this differs from the use of Regular RTCP
   Feedback for IDMS, in which the IDMS adjustments are purely based on
   packet-level timestamps.

4.3.  Rapid (Re-)Synchronization Request

   If the initial compound RTCP packet (including an SR, SDES and IDMS
   Settings packets) is lost, the affected SCs will not be able to
   synchronize the media playout until the report interval has passed,
   and the next RTCP packet can be sent.  This is undesirable.
   [RFC6051] defines a new RTP/AVPF transport layer feedback message to
   request the generation of an Early RTCP SR, allowing rapid inter-
   stream (re-)synchronization.





Montagud, et al.         Expires August 13, 2015               [Page 16]

Internet-Draft              EED RTCP for IDMS              February 2015


   A similar mechanism is proposed in this document to be applied for
   IDMS purposes.  A new RTP/AVPF transport layer feedback message
   [RFC4585], called RTCP-IDMS-REQ, is introduced to request the rapid
   generation (and transmission) of an RTCP IDMS Settings packet by the
   MSAS (see Figure 5).


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |V=2|P| FMT=TBD | PT=RTPFB=205  |          length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC of packet sender                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  SSRC of media source                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Media Stream Correlation Identifier (SyncGroupId)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         (TBD: To Be Determined)


                 Figure 5: RTCP-IDMS-REQ Feedback Message

   The Payload Type (PT) of this type of RTCP message should be 205, as
   specified in [RFC4585], the Frame Message Type (FMT) MUST be assigned
   by IANA (Internet Assigned Numbers Authority), and its length must be
   equal to 3.  The SSRC of the packet sender MUST indicate the SC
   sending the packet, while the SSRC of the media source field MUST
   indicate the source of the media stream the SC (who sends this RTCP-
   IDMS-REQ) is unable to synchronize.  In contrast to the RTCP-SR-REQ
   feedback message defined in [RFC6051], in which the Feedback Control
   Information (FCI) part is kept empty, in the RTCP-IDMS-REQ it must
   carry the SyncGroupId (specified in [RFC7272]) to which the sender of
   this message belongs.

   Once a new RTCP-IDMS-REQ is received by the MSAS, it MUST generate an
   Early RTCP IDMS Settings packet as soon as possible, while complying
   with the Early RTCP feedback rules.

   This mechanism can also be employed if a SC has not received RTCP
   IDMS Settings in a (configurable) long time interval.  The RTCP-IDMS-
   REQ packet MAY be repeated once per RTCP reporting interval if no
   RTCP IDMS Settings packet is forthcoming.  Likewise, the MSAS MAY
   ignore RTCP-IDMS-REQ packets if its regular schedule for RTCP
   transmission will allow the SC to synchronize within a reasonable
   time interval.





Montagud, et al.         Expires August 13, 2015               [Page 17]

Internet-Draft              EED RTCP for IDMS              February 2015


   Although this mechanism is similar to the one in [RFC6051] to request
   rapid RTCP SRs, it is especially necessary since, in most
   implementations,the IDMS Settings packets will not be regularly sent
   in each RTCP report interval, as RTCP SRs, but only when the detected
   asynchrony exceeds an allowable threshold..

   When using SSM sessions with unicast feedback, it is possible that
   the feedback target and the MSAS are not co-located.  If a feedback
   target receives an RTCP-IDMS-REQ feedback message in such a case, the
   request SHOULD be forwarded to the MSAS.  However, the mechanism to
   be used for forwarding such requests is not defined in this document.

   If the feedback target provides a network management interface, it
   might be useful to provide a log of which SCs send RTCP-IDMS-REQ
   feedback packets and which do not, since the later will experience
   slower stream synchronization.

4.4.  Reduction of Channel Change Delays

   The participation and support of latecomers are key issues to enable
   dynamic IDMS-enabled sessions.  One widely applicability of the RTCP-
   IDMS-REQ messages is the dynamic and rapid accommodation of
   latecomers.

   Once a latecomer joins an IDMS-enabled session, it MUST send an RTCP-
   IDMS-REQ to the MSAS of that session.  Then, the MSAS MUST generate
   an Early RTCP IDMS Settings packet to rapidly bring the latecomer up-
   to-date, thus minimizing the IDMS Delay experienced by that latecomer
   (i.e. the time interval between joining and acquiring IDMS).

   Immediately after receiving the RTCP IDMS Settings packet, the
   latecomer will begin to play out the media stream in a time
   synchronized way with the other SCs, thus becoming an additional
   member in the IDMS-enabled session, as shown in Figure 5.  This will
   prevent from both long annoying startup delays and initial playout
   inconsistencies.















Montagud, et al.         Expires August 13, 2015               [Page 18]

Internet-Draft              EED RTCP for IDMS              February 2015


   MSAS            i-th SC          j-th SC           k-th  SC
(Media Sender)                                       (Latecomer)
    |                 |                 |                 |
    |         :::::: Media Session Set-up ::::::          |
    |            (see Section 3 in [RFC7272])             |
    |      ...                ...               ...       |
    |RTCP IDMS Packet |                 |                 |
    |---------------->|---------------->|                 |
    |===>             |                 |                 |
    |===> RTP Packets |                 |                 |
    |===>             |                 |                 |
    |      ...               ...               ...        |
    |   RR + IDMS XR  |                 |                 |
    |<++++++++++++++++|                 |                 |
    |                 |  RR + IDMS XR   |                 |
    |<++++++++++++++++|+++++++++++++++++|                 |
    |RTCP IDMS Packet |RTCP IDMS Packet |                 |
    |---------------->|---------------->|                 |
    |      ...                ...                         x t0 k-th SC
    |                 |                 |   RTCP AVPF     | joins
    |                 |                 | IDMS-REQ Packet |
t2  x<****************|*****************|*****************x t1
    |                 |                 |                 |
    |RTCP IDMS Packet |                 |                 |
t3  x---------------->|---------------->|---------------->x t4
    |                 |                 |                 | IDMS Settings
    |                 |                 |                 | reception
    |                        ...                          |
    |                 |                 |                 x t5: In Sync!
    |                 |                 |  RR + IDMS XR   |
    |<++++++++++++++++|+++++++++++++++++|+++++++++++++++++x
    |                          ...                        |


      Figure 6: IDMS Operation and Rapid Accommodation of Latecomers

   The timing diagram for the RTCP exchange processes is illustrated in
   Figure 6.  It can be seen that, if enabling EED RTCP Feedback for
   IDMS, the IDMS delay (which is the time interval between joining and
   acquiring IDMS, represented by (t5 - t0) in Figure 6) for the
   latecomer (k-th SC) can be significantly reduced, mainly due to the
   fact that the MSAS delay ((t3 - t2) in Figure 6) can be minimized.

   Although the above discussion has been focused for latecomers, it is
   also applicable for reducing channel change (i.e., zapping) delays in
   IDMS-enable sessions, which is currently a hot research topic in the
   IPTV area.  Concretely, the relevance of channel change delays and
   their variability in IDMS-sensitive services is threefold.  First, as



Montagud, et al.         Expires August 13, 2015               [Page 19]

Internet-Draft              EED RTCP for IDMS              February 2015


   for inter-stream synchronization, the required time to receive the
   IDMS setting instructions must not contribute to further increase the
   channel change delays.  Second, apart from the magnitudes of channel
   change delays, their variability (i.e., the delay variation for each
   user) will also impact the IDMS performance.  Third, when a group of
   users are watching IPTV together and they (simultaneously) change (or
   must change) to another channel, any playout time differences among
   them will also influence the resulting delay.  Therefore, in this
   context, the use of EED RTCP Feedback for IDMS is very beneficial
   because: i) it significantly reduces the time needed to receive the
   initial RTCP IDMS Settings packet; and ii) it enables the
   compensation of the delay differences when changing channels.

   Two additional mechanisms could contribute to further reduce the IDMS
   Delay.  The first one consists of employing priority mechanisms for
   the transport of RTCP messages, e.g., by adopting a Differentiated
   Services (DiffServ) policy.  This would help to decrease the Round
   Trip Time (RTT) delays and the loss probability for RTCP packets (out
   of the scope of this document).  The second one is based on the
   transmission of Early RTCP-IDMS-REQ messages by latecomers upon
   joining the session.  According to [RFC6051], the delay since joining
   and sending an RTCP-IDMS-REQ message ((t1-t0) in Figure 6) should not
   be reduced to avoid flooding of requests at specific time instants
   (e.g., at the time a broadcasted sport event begins).  Although we
   initially adhere to this standard compliant rule in this document, we
   believe that it should be discussed within the AVTCORE WG if this
   flash crowd effect is a real limiting issue in real SSM scenarios
   (e.g., networked quiz shows, gaming, IPTV, etc.).  Our initial
   assumption is that the upstream bandwidth availability by the SCs
   (which is not used for other purposes) and the aggregation and re-
   distribution mechanisms by Feedback Targets [RFC5760] do not entail a
   real constraint for allowing the transmission of Early RTCP-IDMS-REQ
   by the SCs.  Moreover, it is assumed in [RFC6051] that all SCs switch
   channels simultaneously, but even though using automated procedures
   (e.g., through notifications via the Electronic Program Guides in
   IPTV), this would not be a matter of a few seconds, but most probably
   of minutes.

5.  Reduced-Size RTCP Reporting for IDMS

   RTCP SR and RR contain relevant QoS statistics usable for monitoring
   of the media stream transmission and thus enable media adaptation.
   The regular transmission of these RTCP packets becomes very useful to
   infer trends between successive reports due to the dynamic nature of
   the conveyed information.  Likewise, the tracking of the session size
   thanks to that regular reports warrants bounded RTCP traffic
   bandwidth.  Moreover, compound RTCP packets are useful to establish
   and maintain multimedia synchronization.  Due to the above issues,



Montagud, et al.         Expires August 13, 2015               [Page 20]

Internet-Draft              EED RTCP for IDMS              February 2015


   the regular transmission of compound RTCP packets must be maintained
   throughout the RTP session's lifetime.

   However, [RFC5506] defines certain changes to the RTCP reporting
   rules to allow feedback messages to be sent as Reduced-Size RTCP
   packets under certain conditions when using the RTP/AVPF profile
   [RFC4585].  The motivation is that, in some cases, it is more useful
   to report certain events of interest the more frequently or the
   sooner as possible to enable short-term adaptation, rather than
   sending full compound RTCP packets including periodic statistics.

   In low bitrate links (e.g. radio access technologies), there are some
   benefits of reporting Reduced-Size RTCP packets.  First, if channels
   conditions are poor, smaller RTCP packets are much more likely to be
   successfully transmitted than larger compound RTCP packets, and they
   will also introduce lower traffic overhead.  The last issue is
   critical, as those messages are likely to occur when channel
   conditions are poor (e.g., for reporting picture or slice loss).
   Second, the serialization time when transmitting small size RTCP
   packets is shorter than when transmitting full (larger) RTCP compound
   packets.  Third, when the bandwidth availability is scarce, smaller
   RTCP packets will enable more frequent feedback messages.

   In high bitrate environments, the above issues are not real
   limitations, but using Reduced-Size RTCP packets may also be
   beneficial to reduce the processing delay and complexity of RTCP
   packets.

   Independently of the link type, additional benefits with sending
   feedback in small Reduced-Size RTCP packets can be cited.  For
   instance, when using Early RTCP Feedback [RFC4585], receivers
   typically need to send frequent event-driven feedback messages.  In
   such cases, if using Reduced-Sized RTCP packets, the risk that the
   RTCP bandwidth becomes too high during periods of heavy feedback
   signaling is reduced.

   More details about use cases for, benefits of and issues with
   Reduced-Size RTP reporting can be found in [RFC5506].

   Accordingly, the use of Reduced-Size RTCP packets MAY also be
   beneficial when enabling the EED RTCP reporting rules for IDMS
   proposed in this document.  [RFC5506] specifies that in Immediate
   Feedback mode, as it is the case of RTCP IDMS Settings packets, all
   feedback messages may be sent as Reduced-Size RTCP packets.  However,
   it is also stated that Reduced-Size RTCP packets shall not be sent
   until at least one compound RTCP packet has been transmitted.





Montagud, et al.         Expires August 13, 2015               [Page 21]

Internet-Draft              EED RTCP for IDMS              February 2015


   This implies that if the use of non-compound RTCP packets [RFC5506]
   has been previously negotiated between the participants in an IDMS-
   enabled session, both the RTCP-IDMS-REQ and the RTCP IDMS Settings
   packets MAY be sent as non-compound RTCP packets, but only if a
   compound RTCP packet has been already sent by the senders of those
   feedback messages.

   The Reduced-Size RTCP reporting features do not apply to the first
   IDMS Settings packet, which SHOULD be sent in parallel with the
   initial RTP data packets (Section 4.1).  In such a case, SCs would
   also be benefited by the reception of a compound RTCP packet
   including SR and SDES packets.  This is also the case when a
   latecomer sends an Early RTCP-IDMS-REQ.  Here, the media sender and
   the MSAS would also need an SDES packet from that latecomer for
   membership accounting.

   However, the use of Reduced-Size RTCP reporting MAY be beneficial
   when an RTCP-IDMS-REQ is sent by an active SC that has not received
   an RTCP IDMS Settings packet for a long period, requesting re-
   synchronization setting instructions.  Moreover, Reduced-Size RTCP
   reporting MAY be especially useful for Dynamic EED transmission of
   IDMS Settings packets (Section 4.2), e.g. immediately after detecting
   an out-of-sync situation, or when a specific media event is targeted
   to be simultaneously presented in all the SCs.

   Reduced-Size RTCP packets can become substantially smaller than
   compound packets.  A compound packet is forced to contain both an RR
   or an SR and an SDES with at least the CNAME item.  The RR containing
   a report block for a single source is 32 bytes, and an SR is 52
   bytes.  Both may be larger if they contain report blocks for multiple
   sources.  The SDES packet containing a CNAME item will be 10 bytes
   plus the CNAME string length.  Here, it is reasonable that the CNAME
   string is at least 10 bytes to get a decent collision resistance.  If
   the recommended form of user@host is used, then most strings will be
   longer than 20 characters.  Additionally, for IDMS purposes: i) SCs
   will regularly send RTCP XR blocks for IDMS, which consist of 10
   32-bit words (40 bytes); ii) the MSAS will send RTCP IDMS Settings
   packets, which consists of 9 32-bit words (36 bytes).

   Therefore, Reduced-Size RTCP packets can become at least 70-80 bytes
   smaller than RTCP compound packets, thus reducing the mean RTCP
   packet size, decreasing sporadic traffic peaks, reducing the
   transmission delay, and increasing the overall RTCP feedback
   frequency.







Montagud, et al.         Expires August 13, 2015               [Page 22]

Internet-Draft              EED RTCP for IDMS              February 2015


6.  Security Considerations

   This document does not impose security considerations, beyond the
   ones described in [RFC3550], [RFC4585], [RFC6051], and [RFC7272].

7.  IANA Considerations

   This document defines a new RTP/AVPF transport layer feedback message
   [RFC4585], called RTCP-IDMS-REQ, whose FMT Value needs to be assigned
   by IANA..

8.  Contributors

   Authors would like to thank the co-authors of [RFC7272] for their
   collaboration on specifying the RTCP extensions for IDMS, which are
   starting point of this work.

9.  Conclusions

   This document proposes Early Event-Driven RTCP reporting rules to
   enable higher interactivity, dynamism and accuracy when using RTP/
   RTCP for IDMS.

10.  References

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

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

   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
              Protocol Extended Reports (RTCP XR)", RFC 3611, November
              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.





Montagud, et al.         Expires August 13, 2015               [Page 23]

Internet-Draft              EED RTCP for IDMS              February 2015


   [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
              Real-Time Transport Control Protocol (RTCP): Opportunities
              and Consequences", RFC 5506, April 2009.

   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
              Media Attributes in the Session Description Protocol
              (SDP)", RFC 5576, June 2009.

   [RFC5760]  Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
              Protocol (RTCP) Extensions for Single-Source Multicast
              Sessions with Unicast Feedback", RFC 5760, February 2010.

   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
              Flows", RFC 6051, November 2010.

   [RFC7272]  van Brandenburg, R., Stokking, H., van Deventer, O.,
              Boronat, F., Montagud, M., and K. Gross, "Inter-
              Destination Media Synchronization (IDMS) Using the RTP
              Control Protocol (RTCP)", RFC 7272, June 2014.

10.2.  Informative References

   [Montagud2012]
              Montagud, M., Boronat, F., Stokking, H., and R. van
              Brandenburg, ""Inter-Destination Multimedia
              Synchronization; Schemes, Use Cases and Standardization",
              Multimedia Systems Journal (Springer), 18(6), pp.
              459-482", November 2012, <http://link.springer.com/
              article/10.1007%2Fs00530-012-0278-9#page-1>.

   [Montagud2013]
              Montagud, M., Boronat, F., and H. Stokking, ""Early Event-
              Driven (EED) RTCP Feedback for Rapid IDMS", The 21st ACM
              International Conference on Multimedia (ACM MM 2013),
              Barcelona (Spain)", October 2013,
              <http://dl.acm.org/citation.cfm?id=2502114>.

   [RFC5968]  Ott, J. and C. Perkins, "Guidelines for Extending the RTP
              Control Protocol (RTCP)", RFC 5968, September 2010.

Authors' Addresses










Montagud, et al.         Expires August 13, 2015               [Page 24]

Internet-Draft              EED RTCP for IDMS              February 2015


   Mario Montagud (editor)
   Universitat Politecnica de Valencia
   C/ Paraninf, 1
   Grau de Gandia, Valencia  46730
   Spain

   Phone: +34 962 849 341
   Email: mamontor@upv.es


   Fernando Boronat
   Universitat Politecnica de Valencia
   C/ Paraninf, 1
   Grau de Gandia, Valencia  46730
   Spain

   Phone: +34 962 849 341
   Email: fboronat@dcom.upv.es


   Hans Stokking
   TNO
   Brassersplein 2
   Delft  2612CT
   The Netherlands

   Phone: +31-88-866-7000
   Email: hans.stokking@tno.nl























Montagud, et al.         Expires August 13, 2015               [Page 25]