idnits 2.17.1 draft-montagud-avtcore-eed-rtcp-idms-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 616 has weird spacing: '...epaired t_d3...' == Line 667 has weird spacing: '...Skipped t_r...' -- The document date (February 9, 2015) is 3364 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NOTE' is mentioned on line 567, but not defined == Unused Reference: 'RFC3611' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: 'RFC5576' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'RFC5968' is defined on line 1096, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Montagud, Ed. 3 Internet-Draft F. Boronat 4 Intended status: Standards Track UPV 5 Expires: August 13, 2015 H. Stokking 6 TNO 7 February 9, 2015 9 Early Event-Driven (EED) RTCP Feedback for Rapid IDMS 10 draft-montagud-avtcore-eed-rtcp-idms-00 12 Abstract 14 RFC 7272 defines two RTCP messages to enable Inter-Destination Media 15 Synchronization (IDMS). However, if such RTCP messages are exchanged 16 using the Regular RTCP reporting rules specified in RFC 3550, 17 unacceptable delays can be originated when exchanging the 18 synchronization information conveyed into RTCP packets. Accordingly, 19 this document proposes Early Event-Driven (EED) RTCP reporting rules 20 and messages to enable higher interactivity, dynamism, flexibility 21 and accuracy when using RTP/RTCP for IDMS. Such IDMS extensions are 22 targeted at providing faster reaction on dynamic situations, such as 23 out-of-sync situations and channel change delays, as well as a finer 24 granularity for synchronizing media-related events, while still 25 adhering to the RTCP bandwidth bounds specified in RFC 3550. 26 Besides, a new RTP/AVPF transport layer feedback message is proposed 27 to allow the request of re-IDMS setting instructions (e.g., in case 28 of RTCP packet loss) as well as rapid accommodation of latecomers in 29 on-going sessions. Finally, this document also discusses various 30 situations in which the reporting of Reduced-Size RTCP packets (RFC 31 3556) can be applicable and beneficial for IDMS. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 13, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may not be modified, and derivative works of it may not 66 be created, and it may not be published except as an Internet-Draft. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. RTP/RTCP for IDMS (RFC 7272) . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Background: RTCP Reporting Rules . . . . . . . . . . . . . . 7 74 3.1. Regular RTCP Feedback (RFC 3550) . . . . . . . . . . . . 7 75 3.2. Early RTCP Feedback (RFC 4585) . . . . . . . . . . . . . 9 76 3.3. Rapid Synchronization of RTP Flows (RFC 6051) . . . . . . 10 77 3.4. SDP Modifiers for RTCP Bandwidth (RFC 3556) . . . . . . . 11 78 4. Early Event-Driven (EED) RTCP Feedback for IDMS . . . . . . . 12 79 4.1. Immediate Initial RTCP IDMS Settings . . . . . . . . . . 12 80 4.2. Dynamic EED Reporting of IDMS Settings . . . . . . . . . 13 81 4.3. Rapid (Re-)Synchronization Request . . . . . . . . . . . 16 82 4.4. Reduction of Channel Change Delays . . . . . . . . . . . 18 83 5. Reduced-Size RTCP Reporting for IDMS . . . . . . . . . . . . 20 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 86 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 87 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 90 10.2. Informative References . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 93 1. Introduction 95 RTP (Real-Time Transport Protocol) and RTCP (RTP Control Protocol) 96 protocols provide support for both intra-media and inter-media 97 synchronization [RFC3550]. Moreover, [RFC7272] extends the RTP/RTCP 98 capabilities to also enable Inter-Destination Media Synchronization 99 (IDMS). 101 However, if the proposed RTCP messages for IDMS in [RFC7272] are 102 exchanged using the Regular RTCP reporting rules specified in 103 [RFC3550], this can lead to unnaceptable performance in some delay- 104 sensitive applications requiring stringent synchronization 105 requirements [Montagud2012]. This is because the RTCP packets are 106 exchanged in a pre-scheduled and inflexible manner, uniquely based on 107 preserving the allowed traffic bounds specified in [RFC3550]. There 108 is no support for timely feedback that would allow to repair or to 109 manage dynamic events of interest close to their occurrence. 110 Accordingly, there may be a variable time lag (from few seconds to 111 several minutes in large-scale environments) between detecting an 112 event (e.g., an out-of-sync situation) and being able to send an 113 appropriate RTCP packet to handle it. Moreover, the RTCP reports may 114 even not be received at the target side, since RTCP is sent over UDP, 115 which does not provide a reliable control channel. 117 This document proposes further extensions to RTP/RTCP to allow for a 118 more strategic and efficient usage of the RTCP channel for IDMS. In 119 particular, the RTCP extensions from [RFC4585] and [RFC6051] 120 encourage the specification of novel RTCP reporting rules and 121 messages, which in conjunction we call Early Event-Driven (EED) RTCP 122 Feedback for IDMS, to enable higher interactivity, dynamism, 123 flexibility and accuracy when using RTP/RTCP for IDMS. Such IDMS 124 extensions are backward compatible with the solution specified in 125 [RFC7272], while still adhering to the RTCP traffic bounds specified 126 in [RFC3550]. 128 More specifically, the proposed EED RTCP Feedback for IDMS provides 129 the following key benefits: i) earlier correction of out-of-sync 130 situations; ii) higher granularity for synchronizing the presentation 131 of dynamically triggered media-related events (e.g., to ensure that 132 important pieces of media content are simultaneously watched by all 133 the users); iii) ability of dynamically requesting IDMS setting 134 instructions (e.g., in case of RTCP packet loss); iv) dynamic and 135 rapid accommodation of latecomers in on-going sessions; and v) 136 reduction of channel-change (i.e., zapping) delays. Additionally, 137 this document also discusses various situations in which the 138 reporting of Reduced-Size RTCP packets [RFC3556] can be applicable 139 and beneficial for IDMS. 141 The proposed RTCP extensions for IDMS in this document are applicable 142 to and can have a potentially high impact on a wide spectrum of 143 scenarios with demanding IDMS characteristics [Montagud2012], such as 144 Social TV, multi-party conferencing, and synchronous e-learning. 146 A preliminary evaluation of such proposals can be found in 147 [Montagud2013]. 149 1.1. RTP/RTCP for IDMS (RFC 7272) 151 IDMS refers to the playout of media streams at two or more 152 geographically distributed locations in a time-synchronized manner. 153 A large number of applications requiring IDMS can be found in 154 [Montagud2012]. Some relevant examples are: Social TV, multi-party 155 conferencing, networked loudspeakers and networked multi-player 156 games. 158 [RFC7272] extends the RTP/RTCP mechanisms to exchange useful feedback 159 information for IDMS between Synchronization Clients (SC) and a 160 centralized Media Synchronization Application Server (MSAS). First, 161 an RTCP XR block for IDMS, called "IDMS report", is defined to enable 162 the SCs to report on packet reception and/or presentation times for a 163 specific RTP stream. Second, a new RTCP IDMS packet type, called 164 "IDMS Settings packet", is defined to allow the MSAS the transmission 165 of IDMS setting instructions to the distributed SCs, based on the 166 collected IDMS timings from them. This IDMS Settings packet will 167 provide a common target playout point, referred to a specific RTP 168 packet (concretely, to its generation timestamp) to which all the SCs 169 belonging to a specific synchronization group (identified by the 170 SyncGroupId field, specified in [RFC7272]) must synchronize. 171 Besides, a new Session Description Protocol (SDP) parameter, called 172 "rtcp-idms", is defined to notify about the usage of the above IDMS 173 messages and to manage the group membership, thus allowing the co- 174 existence of various independent groups of users in IDMS-enabled 175 sessions. 177 Figure 1 shows the architectural solution for IDMS adopted in 178 [RFC7272], wich is based on a sync-maestro scheme [Montagud2012]. In 179 this particular case, the SCs are co-located with RTP Receivers and 180 the MSAS is co-located with the RTP Sender (although it could be co- 181 located with an SC or with a third-party entity). The MSAS is 182 responsible for collecting the IDMS reports from all the SCs 183 belonging to a specific group, computing the delay differences among 184 them and, if needed, sending IDMS Settings packets to make them to 185 enforce the required adjustments to achieve IDMS. Although other 186 architectural solutions are feasible, such as a distributed or a 187 master/slave scheme [Montagud2012], this document also focuses on the 188 sync-maestro scheme. 190 +-----------------------+ +-----------------------+ 191 | | | | 192 | RTP Sender | | RTP Receiver | 193 | | RTCP RR + | | 194 | +-----------------+ | XR for IDMS | +-----------------+ | 195 | | | | <-------------- | | | | 196 | | Media | | | | | | 197 | | Synchronization | | | | Synchronization | | 198 | | Application | | | | Client | | 199 | | Server | | RTCP SR + | | (SC) | | 200 | | (MSAS) | | IDMS Settings | | | | 201 | | | | --------------> | | | | 202 | +-----------------+ | | +-----------------+ | 203 | | | | 204 +-----------------------+ +-----------------------+ 206 Figure 1: IDMS Architecture 208 2. Terminology 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in RFC 2119 [RFC2119]. 214 The terminology defined in "RTP: A Transport Protocol for Real-Time 215 Applications" [RFC3550], "Extended RTP Profile for Real-time 216 Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" 217 [RFC4585], "Rapid Synchronisation of RTP Flows" [RFC6051], and in 218 "RTCP for Inter-Destination Media Synchronization" [RFC7272], apply. 220 The naming convention for RTCP is sometimes confusing. Below is a 221 list of RTCP related terms and their meaning. Those concepts were 222 defined in [RFC3550], [RFC4585], and [RFC5506], but refreshed here 223 for a better understanding of this document: 225 o RTCP packet: There are different types of RTCP packets, each one 226 reporting on a specific metric or event of interest. It consists 227 of a fixed header part followed by structured fields or elements 228 depending on the information conveyed in that RTCP packet type. 230 o Regular RTCP mode: Mode of operation in which no preferred 231 transmission of feedback messages is allowed. Instead, RTCP 232 packets are sent following the rules specified in [RFC3550]. 234 o Regular RTCP packet: RTCP packet that is sent using Regular RTCP 235 mode. 237 o Event: An observation that is (potentially) of interest to the 238 participants of a media session and thus useful to be reported by 239 means of an RTCP feedback message in a timely fashion. 241 o Regular RTCP packet: RTCP packet that is sent using Regular RTCP 242 mode. 244 o Early RTCP mode: Mode of operation in which a participant is 245 capable of reporting events of interest in a timely fashion (i.e., 246 close to their occurrence). 248 o Early RTCP packet: RTCP packet that is transmitted earlier than 249 the scheduled transmission time when following the reporting rules 250 specified in [RFC3550]. In [RFC4585], Early RTCP packets may be 251 sent either as "Immediate Feedback" or as "Early RTCP" modes, 252 depending on the group size. In the context of this document, 253 Early RTCP packets are sent by the MSAS, which is a single 254 centralized entity. Therefore, no dithering interval is needed to 255 avoid feedback implosion, and RTCP packets can be sent in an 256 "Immediate Feedback" mode. Sending an Early RTCP packet is also 257 referred to as sending Early Feedback in this document. 259 o Compound RTCP packet: A collection of two or more RTCP packets. 260 In [RFC3550], it is mandatory to send RTCP packets as compound 261 packets including at least an RTCP RR or SR packet, followed by an 262 SDES packet with the CNAME item for the transmitting source 263 identifier. Often the term "compound" is left out, so the 264 interpretation of RTCP packet is therefore dependent on the 265 context. 267 o Minimal compound RTCP packet: A compound RTCP packet that contains 268 only mandatory information, such as encryption prefix (if 269 necessary), exactly one RTCP RR or SR packet, exactly one SDES 270 packet with the CNAME item, and possible additional Feedback 271 Messages [RFC4585] that must be sent as an Early RTCP packet. 273 o (Full) Compound RTCP packet: A compound RTCP packet that conforms 274 to the requirements on minimal compound RTCP packets and contains 275 any additional number of RTCP packets (additional RRs, further 276 SDES items, etc.). RTCP compound packets are typically sent when 277 using Regular RTCP Feedback [RFC3550], although they may be also 278 sent when using Early RTCP Feedback [RFC4585]. 280 o Reduced-Size RTCP packet: It only contains one or more RTCP 281 packets, being much smaller than (minimal and full) compound RTCP 282 packets [RFC3550]. Such RTCP packets are sent when using Early 283 RTCP Feedback, but must not be sent when using Regular RTCP 284 Feedback. The full definition is in Section 4.1 of [RFC5506]. 286 Besides, the definition of three key concepts will help understanding 287 (the proposed IDMS extensions in) this document:. 289 o Inter-Stream Synchronization Delay (or Latency): It refers to the 290 time difference between the instant at which a user joins an on- 291 going multimedia session, probably involving different media 292 (e.g., audio and video, or when using layered and/or multi- 293 description media) carried in separate streams, and the instant at 294 which these correlated streams can be presented to that user in a 295 synchronized manner. It is defined in [RFC6051]. 297 o IDMS Delay (or Latency): It refers to the time difference between 298 the instant at which an IDMS-related event occurs (e.g., a user 299 joins an on-going session or an out-of-sync situation is detected) 300 and the instant at which the IDMS Setting instructions to handle/ 301 repair such event have been received and processed at the target 302 side/s or SCs. 304 o Latecomer: In multi-party multimedia services, users may join and 305 leave the session quite frequently. A user who joins a session in 306 progress is usually called a latecomer (or late joiner) [RFC6051]. 308 3. Background: RTCP Reporting Rules 310 In this section, an overview of the RTCP reporting rules is provided. 311 This is important to help understanding the benefits of the RTCP 312 reporting rules and reports proposed in this document. 314 3.1. Regular RTCP Feedback (RFC 3550) 316 During the media session's lifetime, the participants of an RTP 317 Session (i.e., senders and receivers) regularly exchange RTCP reports 318 (typically conveyed into compound RTCP packets) to inform mainly 319 about QoS (Quality of Service) statistics, either in a unicast or 320 multicast way (depending on the specific networked environment). On 321 the one hand, a low frequency of RTCP feedback reporting can lead to 322 faulty behavior due to outdated statistics. On the other hand, 323 excessive reports can be redundant and cause unnecessary control 324 traffic, probably leading to potential congestion situations. 326 Also, if the RTCP packets were exchanged at a constant rate, the 327 control traffic would grow linearly with the number of participants. 328 Accordingly, a trade-off between up-to-date information and the 329 amount of control traffic must be met. This would allow an 330 application to (automatically) scale over session sizes ranging from 331 few participants to tens of thousands. 333 The total amount of control traffic added by RTCP should be limited 334 to a small (so that the primary function of media data transport is 335 not impaired) and known (so that each participant can independently 336 calculate its share) fraction of the allocated RTP session bandwidth. 337 A fraction of 5 % is recommended in [RFC3550]. In such process, 338 media senders are given special consideration to allow a more 339 frequent report exchange of their RTCP statistics, some of which are 340 indeed very relevant for multimedia synchronization. In particular, 341 if the proportion of senders constitute less than one quarter of the 342 session membership, this percentage is further divided into two 343 parts, where 25 % must be dedicated to active senders and the 344 remaining can be consumed by receivers. Otherwise, the RTCP 345 bandwidth is equally shared between senders and receivers. 347 Based on the above aspects, the RTCP report interval is dynamically 348 and locally computed in each RTP entity, every time an RTCP packet is 349 sent, according to the available session bandwidth, the average size 350 of all received and sent RTCP packets, the number of participants in 351 the session, their role (senders or receivers), as well as the 352 unicast or multicast nature of the session (see Section 6.2 of 353 [RFC3550] for further details). 355 This (deterministically) calculated RTCP report interval should also 356 have a lower bound to avoid having bursts (cumpling) of RTCP packets 357 when the number of participants is small and the law of large numbers 358 is not helping to smooth out the traffic overhead. This would also 359 help to avoid excessive frequent reports during transient outages 360 like a network partition. The recommended value in [RFC3550] for 361 that fixed minimum interval is 5 s. 363 Besides, a delay should be imposed to each participant before sending 364 the first RTCP packet upon joining the session. This allows a 365 quicker convergence of the RTCP report interval to the correct value. 366 This initial delay may be set to half the minimum RTCP report 367 interval (i.e., 2.5 s) in multicast sessions, whilst it may be set to 368 zero in unicast sessions. 370 In some cases (e.g. if the data rate is high and the application 371 demands more frequent RTCP reports), an implementation may scale the 372 minimum RTCP interval to a smaller value given by 360 divided by the 373 session bandwidth (in kbps). This yields to an interval smaller than 374 5 s when the session bandwidth becomes greater than 72 kbps. In 375 multicast sessions, only active senders may use that reduced minimum 376 interval, whilst in unicast sessions it also may be used by 377 receivers. In the above cases, however, the minimum interval of 5 s 378 must be still taken into account during the membership accounting 379 procedure to not prematurely time out participants (who can indeed be 380 using it) because of inactivity. 382 After that, the interval between RTCP packets is varied randomly over 383 the range [0.5, 1.5] times that RTCP report interval to prevent 384 floods of RTCP reports (i.e., to avoid that all RTCP packets are sent 385 and received almost at the same time, in every report interval). 387 Additionally, "timer reconsideration" algorithms are introduced to 388 allow for a more rapid adaptation of the RTCP report interval in 389 large-scale sessions, where the membership can largely vary (e.g., 390 many receivers join and leave the session quite frequently). To 391 compensate for the fact that the "timer reconsideration" algorithms 392 converge to a lower value than the intended average RTCP bandwidth, 393 the (randomized) report interval is finally divided by e-3/2=1.21828. 395 3.2. Early RTCP Feedback (RFC 4585) 397 In [RFC4585], further RTCP reporting mechanisms are specified to 398 enable receivers to provide, statistically, more immediate RTCP 399 feedback to the senders. This Early RTCP Feedback profile, which is 400 known as RTP Audio-Visual Profile with Feedback (RTP/AVPF), allows 401 for short-term adaptation and efficient feedback-based repairing 402 mechanisms to be implemented, while maintaining the RTCP bandwidth 403 constraints and preserving scalability to large groups. 405 The RTCP report interval specified in [RFC3550] is denoted as Regular 406 RTCP interval in [RFC4585]. In addition, [RFC4585] enables to send 407 RTCP reports earlier that the next scheduled Regular RTCP 408 transmission time if a receiver detects the need to inform about 409 media stream related events (e.g., picture or slice loss) close to 410 their occurrence. 412 [NOTE] A feedback suppression mechanism is adopted, in which 413 receivers wait for a random dithering interval to avoid feedback 414 implosion (i.e., lots of receivers reporting on the same event). 416 The reporting rules for Regular RTCP packets in [RFC4585] are similar 417 than the ones in [RFC3550]. However, the recommended minimum RTCP 418 report interval of 5 s in [RFC3550] is dropped in [RFC4585]. 419 Instead, an optional attribute, called "trr-int", is specified as an 420 offset parameter (in ms) to the computed Regular RTCP Report 421 interval. 423 Note that providing "trr-int" as an independent variable is intended 424 to restrain from sending too frequent Regular RTCP packets (i.e., 425 saving RTCP bandwidth) while enabling higher flexibility to transmit 426 Early RTCP packets (i.e., using the saved RTCP bandwidth) in response 427 to dynamic events. This could not be achieved by reducing the 428 overall RTCP bandwidth, because the frequency of Early RTCP packets 429 would be affected as well. Values between 4 and 5 s for "trr-int" 430 are recommended to assure interworking with RTP entities only using 431 Regular RTCP Feedback. However, as "trr-int" is an optional 432 attribute, it may be set to zero (default value) if a specific 433 application would benefit from a higher frequency of Regular RTCP 434 packets. In such a case, the only difference between the RTCP timing 435 rules from [RFC3550] and [RFC4585] for transmitting Regular RTCP 436 packets resides in the minimum value for the report interval, which 437 is dropped in [RFC4585]. 439 In order to preserve the RTCP traffic bounds, only one Early RTCP 440 packet can be transmitted between two consecutive Regular RTCP 441 packets (i.e. receivers cannot send two consecutive Early RTCP 442 packets). After sending an Early RTCP packet, the RTCP reporting 443 engine must schedule the transmission time for the next RTCP packet 444 by skipping the next Regular RTCP interval. 446 Furthermore, [RFC4585] defines a small number of general-purpose 447 feedback messages as well as a format for codec- and application- 448 specific feedback information for transmission in the RTCP payloads. 450 3.3. Rapid Synchronization of RTP Flows (RFC 6051) 452 When using RTP streaming, the inter-stream synchronization delay can 453 greatly increase in certain scenarios, especially in large multicast 454 groups or when Multipoint Conference Units (MCU) are involved in the 455 media delivery process. This increase of delay can be inacceptable 456 and annoying to users, resulting in an overall poor Qualilty of 457 Experience (QoE). 459 The aim of [RFC6051] is to minimize the inter-stream synchronization 460 delay when using RTP/RTCP-based streaming. The motivation is that a 461 receiver cannot synchronize playout of the incoming media streams 462 until compound RTCP packets, including a Source Description or SDES 463 packet (including the media source identification) and a Sender 464 Report or SR (including timing correlation parameters), are received 465 for all the involved RTP senders in a multimedia session. In most 466 implementations, media data will not be played out (watched or 467 listened) until inter-stream synchronization is (initially) achieved. 468 If there is no packet loss, this gives an expected delay equal to the 469 average time for receiving the first RTCP packet from the RTP Session 470 with the longest RTCP report interval. This delay is even more 471 problematic if an RTCP SR packet from one of the involved RTP 472 sessions is lost. 474 [NOTE] Note that the inter-stream synchronization delay depends on 475 the specific instant at which a user joins the multimedia session or 476 each RTP session (e.g., the user may first receive the RTCP packets 477 from the RTP session with the longest RTCP interval), as well as on 478 the impact of the randomization processes in all the involved RTP 479 sessions. 481 In [RFC6051], three backward compatible extensions to the RTP/RTCP 482 protocols are proposed to reduce the inter-stream synchronization 483 delay. First, the RTCP timing rules are updated to allow Single 484 Source Multicast (SSM) senders [RFC5760] the immediate transmission 485 of an initial compound RTCP packet upon joining each RTP session in a 486 multimedia session (in parallel with the initial RTP packets). The 487 rationale for not allowing the transmission of immediate RTCP packets 488 to SSM receivers is to avoid feedback implosion in case that many 489 receivers join the session almost simultaneously ("flash crowd" 490 effect). This is clearly not an issue for SSM senders, since there 491 can be at most one sender. Likewise, feedback implosion is a concern 492 for Any Source Multicast (ASM) sessions, so [RFC6051] does not 493 propose changes to the RTCP timing rules in these kinds of multicast 494 environments. Second, a new RTP/AVPF transport layer feedback 495 message (this type of RTCP messages is defined in [RFC4585]), called 496 RTCP-SR-REQ, is defined to allow requesting the generation of an 497 Early RTCP SR packet from the media sender. This enables rapid 498 (re-)synchronization in case that an RTCP SR has not been received 499 for a long period (e.g. due to packet loss or in sessions with large 500 RTCP reporting intervals). Likewise, this enables latecomers to 501 achieve inter-stream synchronization as soon as possible upon joining 502 the session. Finally, new RTP header extensions are defined to 503 enable the inclusion of metadata (in particular, NTP-based 504 timestamps) in RTP data packets for in-band synchronization, thus 505 avoiding the need for receiving RTCP SR packets before streams can be 506 synchronized. These RTP header extensions do not eliminate the need 507 for RTCP SR messages, but both mechanisms must be used for the 508 synchronization control process. The use of RTCP SR packets for 509 inter-stream synchronization allows backwards compatibility, but also 510 provides higher robustness in the presence of middle boxes (e.g., RTP 511 translators) that might strip RTP header extensions. 513 An accurate and rapid inter-stream synchronization is especially 514 relevant when using layered, multi-description and multi-view media 515 encodings. This is because all the individual RTP streams need to be 516 synchronized before starting the decoding processes. 518 3.4. SDP Modifiers for RTCP Bandwidth (RFC 3556) 520 In some applications, it may be appropriate to specify the RTCP 521 bandwidth independently of the allocated RTP session bandwidth. 522 Accordingly, [RFC3556] defines two additional Session Description 523 Protocol (SDP) attributes to specify modifiers for the RTCP bandwidth 524 for senders and receivers. 526 On the one hand, using a separate parameter allows rate-adaptive 527 applications to set an RTCP bandwidth consistent with a "typical" 528 data bandwidth that is lower than the maximum bandwidth specified by 529 the session bandwidth parameter. This allows the RTCP bandwidth to 530 be kept under 5% of the session bandwidth when the rate has been 531 adapted downward, e.g. based on the stability of the network 532 conditions. On the other hand, there may be applications that send 533 data at very low rates, but need to communicate quite frequent RTCP 534 information. These applications may need to specify an RTCP 535 bandwidth that is higher than 5% of the data bandwidth. 537 If any of the SDP attributes for the RTCP bandwidth modifiers are 538 omitted, the default value for that parameter is the one specified in 539 the RTP profile in use for the session. [RFC3556] does not impose 540 limits on the values that may be specified for both RTCP bandwidth 541 modifiers, other than that they must be non-negative. However, the 542 RTP specification and the appropriate RTP profile may specify limits. 544 4. Early Event-Driven (EED) RTCP Feedback for IDMS 546 This section introduces the EED RTCP reporting mechanisms proposed in 547 this document to enable higher flexibility, dynamism, interactivity 548 and accuracy when using RTP/RTCP for IDMS, with a sync-maestro 549 architecture. 551 4.1. Immediate Initial RTCP IDMS Settings 553 [RFC6051] relaxes the timing rules for unicast and layered sessions 554 so that SSM senders are allowed to transmit an initial compound RTCP 555 packet (containing an RTCP SR packet and an RTCP SDES packet with a 556 CNAME item) immediately on joining each RTP session in a multimedia 557 session, in parallel with the initial RTP data packets. Hence, the 558 inter-stream synchronization delay is significantly reduced, provided 559 that the initial RTCP packet is not lost. 561 The same rationale for reducing the inter-stream synchronization 562 delay in [RFC6051] can also be extrapolated to IDMS. In such a case, 563 it would also be desirable the transmission of a nearly-immediate 564 RTCP IDMS Settings packet by the MSAS upon establishing a multimedia 565 session. 567 [NOTE]: Note that in this document, the terms (nearly-)immediate, 568 close-to-instant and Early are used as synonymous. This is because 569 the MSAS is a single centralized entity in the media session, and the 570 Early RTCP packets can be sent immediately by this entity without 571 requiring a contention algorithm, as required for receivers in 572 [RFC4585]. 574 If the MSAS is integrated within the RTP Server, it MUST send the 575 IDMS Settings packet in parallel with the initial RTP data packets. 576 If the Sync Manager is co-located within a SC or a third party entity 577 (that also needs to be an RTP receiver for that session), it MUST 578 send the IDMS Settings packet as soon as it receives the initial RTP 579 data packets from the RTP Sender. In either case, as the MSAS is a 580 single centralized RTP entity, it is also allowed to transmit Early 581 RTCP packets [RFC6051]. This way, the SCs can start consuming the 582 media in a synchronized manner earlier, thus ensuring a reduction of 583 the IDMS Delay. 585 This mechanism is purely a local change to the MSAS that can be 586 implemented as a configurable option, as stated in [RFC6051]. 588 4.2. Dynamic EED Reporting of IDMS Settings 590 During the media session's lifetime, if Regular RTCP Feedback is 591 used, the MSAS may have to wait a nearly-complete RTCP reporting 592 interval to be able to send a new compound RTCP packet (including an 593 IDMS Settings packet) after detecting an out-of-sync situation, which 594 might potentially take several seconds (up to 5 s or even more) 595 [RFC3550]. 597 This is illustrated in Figure 2. In such a case, if an event (e.g. 598 out-of-sync situation) is detected just after the transmission of an 599 RTCP packet (at instant t_r1), the next RTCP packet cannot be sent 600 until the next randomized (over the scheduled transmission instant, 601 t_d2) RTCP transmission time (at instant t_r2). The figure shows the 602 worst case, in which the randomized RTCP report interval at that 603 moment is near the upper limit, i.e.:. 605 (t_r2 - t_r1) = 1.5 * (t_d2 - t_r1) 606 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)] 607 ____/\____ ____/\____ ____/\____ 608 / \ / \ / \ 609 t_r1 t_r2 t_r3 610 | | | 611 | | | 612 |-------(---&-|-+-o-)----(-----|----+)----#-(---+-|-----)------> 613 | | | | | | | Time 614 | Event | Event is | Event is | 615 | Occurs | Detected | Handled or | 616 t_d0 t_d1 t_d2 Repaired t_d3 617 \_____ _____/ \_____ _____/ \_____ _____/ 618 \/ \/ \/ 619 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 620 \______ ______/\________ _________/\____ ____/ 621 \/ \/ \/ 622 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 623 \_ _/\______ _______/\_ _/ 624 \/ \/ \/ 625 DD M S A S AD 626 D E L A Y 627 \_____________ ____________/ 628 \/ 629 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) 631 Figure 2: Regular RTCP Timing Rules 633 Legend 634 ------- 635 & Event Occurs 636 O Event is detected 637 # Event is handled/repaired 638 ( ) Random Interval 639 | t_d(n): Scheduled (Deterministic) RTCP Transmission Times 640 + t_r(n): Real (Randomized) RTCP Transmission Times 641 X RTCP Transmission Restriction (Cancellation) 642 DD Detection Delay 643 AD Adjustment Delay 645 Figure 3: Legend 647 Therefore, the contribution of the MSAS delay (i.e., the time 648 interval since an event is detected and an IDMS Settings packet to 649 handle or to repair it is transmitted) to the total IDMS Delay 650 becomes a serious barrier for those use cases requiring stringent 651 synchronization levels (e.g., networked loudspeakers, or networked 652 games) [Montagud2012]. 654 Accordingly, the MSAS is also allowed to dynamically send Early RTCP 655 IDMS Settings packets once detecting events throughout the duration 656 of the media session. This is illustrated in Figure 4. In such a 657 case, an RTCP IDMS Settings packet is sent just after the detection 658 of an event, despite that this moment moment is earlier than the next 659 regular RTCP transmission time. Consequently, the IDMS Delay is 660 significantly reduced, mainly due to the fact that the MSAS delay has 661 been minimized (due to the inmediate transmission of the IDMS 662 Settings packet). 664 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)] 665 ____/\____ ____/\____ ____/\____ 666 / \ / \ / \ 667 t_r1 t_r2 Skipped t_r3 668 | | Handled | | 669 | | | | | 670 |-------(---&-|-+-o+)----(#----|----x)------(---+-|-----)------> 671 | | | | | | Time 672 | Event | Event is | | 673 | Occurs | Detected | | 674 t_d0 t_d1 t_d2 t_d3 675 \_____ _____/ \_____ _____/ \_____ _____/ 676 \/ \/ \/ 677 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 678 \______ ______/|_ _|\____________ ____________/ 679 \/ | \/ 680 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 681 |_| 682 | 683 M S A S D E L A Y 684 \_____ _____/ 685 \/ 686 I D M S D E L A Y (E E D R T C P I N T E R V A L) 688 Figure 4: Early Event-Driven (EED) RTCP Timing Rules 690 Note that if "trr-int" is set to zero, only one Early RTCP packet can 691 be transmitted between two consecutive Regular RTCP packets to 692 preserve the RTCP traffic bounds [RFC3550]. It means that an Early 693 RTCP packet can only be sent if the previous transmitted RTCP packet 694 was a Regular RTCP packet. Hence, after sending an Early RTCP 695 packet, the RTCP reporting engine MUST schedule the sending time for 696 the next RTCP packet by delaying (i.e., skipping) one more Regular 697 RTCP report interval, as in [RFC4585]. 699 In case of high frequency of events, setting an offset value for the 700 Regular RTCP report interval, by means of using the "trr-int" 701 attribute, can help to save RTCP bandwidth (by restraining the 702 transmission of too frequent Regular RTCP packets) while being able 703 to use the (saved) bandwidth when events occur. This is out of scope 704 of this document. 706 Therefore, the proposed EED RTCP reporting rules are based on the 707 fact that not all the feedback reports from the MSAS are of equal 708 importance. This means that some feedback reports from the MSAS need 709 to be reported in a timely fashion. 711 The dynamic EED reporting of IDMS Settings packets is also be very 712 useful to provide playout hints for specific events that must be 713 presented to all the involved users in a fine-grained synchronized 714 way with the piece of content they refer to. Those events can be 715 media-related events whose timing can be known in advance (e.g., 716 commercials, start of the match in a sports event...), but the 717 events' timing could be even unknown (e.g., a goal in a football 718 match...) or dynamically triggered by either operators (e.g., a TV 719 quiz show, in-game actions, interesting scenes...) or users (e.g., 720 shared service control, interactive instant messaging...). 721 Therefore, the use of EED RTCP Feedback for IDMS implies an 722 interaction between the application-layer (through which operator or 723 user generated events are triggered) and the transport/control layer 724 (i.e., RTP/RTCP protocols) in order to translate the high-level 725 (i.e., content-based or action-based) events into lower level calls 726 (i.e., transmission of Early RTCP packets), as well as their 727 alignment in terms of timelines. These are not severe issues, since 728 the MSAS will be co-located with the Media Sender in most 729 implementations. However, this differs from the use of Regular RTCP 730 Feedback for IDMS, in which the IDMS adjustments are purely based on 731 packet-level timestamps. 733 4.3. Rapid (Re-)Synchronization Request 735 If the initial compound RTCP packet (including an SR, SDES and IDMS 736 Settings packets) is lost, the affected SCs will not be able to 737 synchronize the media playout until the report interval has passed, 738 and the next RTCP packet can be sent. This is undesirable. 739 [RFC6051] defines a new RTP/AVPF transport layer feedback message to 740 request the generation of an Early RTCP SR, allowing rapid inter- 741 stream (re-)synchronization. 743 A similar mechanism is proposed in this document to be applied for 744 IDMS purposes. A new RTP/AVPF transport layer feedback message 745 [RFC4585], called RTCP-IDMS-REQ, is introduced to request the rapid 746 generation (and transmission) of an RTCP IDMS Settings packet by the 747 MSAS (see Figure 5). 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 |V=2|P| FMT=TBD | PT=RTPFB=205 | length | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | SSRC of packet sender | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | SSRC of media source | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Media Stream Correlation Identifier (SyncGroupId) | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 (TBD: To Be Determined) 762 Figure 5: RTCP-IDMS-REQ Feedback Message 764 The Payload Type (PT) of this type of RTCP message should be 205, as 765 specified in [RFC4585], the Frame Message Type (FMT) MUST be assigned 766 by IANA (Internet Assigned Numbers Authority), and its length must be 767 equal to 3. The SSRC of the packet sender MUST indicate the SC 768 sending the packet, while the SSRC of the media source field MUST 769 indicate the source of the media stream the SC (who sends this RTCP- 770 IDMS-REQ) is unable to synchronize. In contrast to the RTCP-SR-REQ 771 feedback message defined in [RFC6051], in which the Feedback Control 772 Information (FCI) part is kept empty, in the RTCP-IDMS-REQ it must 773 carry the SyncGroupId (specified in [RFC7272]) to which the sender of 774 this message belongs. 776 Once a new RTCP-IDMS-REQ is received by the MSAS, it MUST generate an 777 Early RTCP IDMS Settings packet as soon as possible, while complying 778 with the Early RTCP feedback rules. 780 This mechanism can also be employed if a SC has not received RTCP 781 IDMS Settings in a (configurable) long time interval. The RTCP-IDMS- 782 REQ packet MAY be repeated once per RTCP reporting interval if no 783 RTCP IDMS Settings packet is forthcoming. Likewise, the MSAS MAY 784 ignore RTCP-IDMS-REQ packets if its regular schedule for RTCP 785 transmission will allow the SC to synchronize within a reasonable 786 time interval. 788 Although this mechanism is similar to the one in [RFC6051] to request 789 rapid RTCP SRs, it is especially necessary since, in most 790 implementations,the IDMS Settings packets will not be regularly sent 791 in each RTCP report interval, as RTCP SRs, but only when the detected 792 asynchrony exceeds an allowable threshold.. 794 When using SSM sessions with unicast feedback, it is possible that 795 the feedback target and the MSAS are not co-located. If a feedback 796 target receives an RTCP-IDMS-REQ feedback message in such a case, the 797 request SHOULD be forwarded to the MSAS. However, the mechanism to 798 be used for forwarding such requests is not defined in this document. 800 If the feedback target provides a network management interface, it 801 might be useful to provide a log of which SCs send RTCP-IDMS-REQ 802 feedback packets and which do not, since the later will experience 803 slower stream synchronization. 805 4.4. Reduction of Channel Change Delays 807 The participation and support of latecomers are key issues to enable 808 dynamic IDMS-enabled sessions. One widely applicability of the RTCP- 809 IDMS-REQ messages is the dynamic and rapid accommodation of 810 latecomers. 812 Once a latecomer joins an IDMS-enabled session, it MUST send an RTCP- 813 IDMS-REQ to the MSAS of that session. Then, the MSAS MUST generate 814 an Early RTCP IDMS Settings packet to rapidly bring the latecomer up- 815 to-date, thus minimizing the IDMS Delay experienced by that latecomer 816 (i.e. the time interval between joining and acquiring IDMS). 818 Immediately after receiving the RTCP IDMS Settings packet, the 819 latecomer will begin to play out the media stream in a time 820 synchronized way with the other SCs, thus becoming an additional 821 member in the IDMS-enabled session, as shown in Figure 5. This will 822 prevent from both long annoying startup delays and initial playout 823 inconsistencies. 825 MSAS i-th SC j-th SC k-th SC 826 (Media Sender) (Latecomer) 827 | | | | 828 | :::::: Media Session Set-up :::::: | 829 | (see Section 3 in [RFC7272]) | 830 | ... ... ... | 831 |RTCP IDMS Packet | | | 832 |---------------->|---------------->| | 833 |===> | | | 834 |===> RTP Packets | | | 835 |===> | | | 836 | ... ... ... | 837 | RR + IDMS XR | | | 838 |<++++++++++++++++| | | 839 | | RR + IDMS XR | | 840 |<++++++++++++++++|+++++++++++++++++| | 841 |RTCP IDMS Packet |RTCP IDMS Packet | | 842 |---------------->|---------------->| | 843 | ... ... x t0 k-th SC 844 | | | RTCP AVPF | joins 845 | | | IDMS-REQ Packet | 846 t2 x<****************|*****************|*****************x t1 847 | | | | 848 |RTCP IDMS Packet | | | 849 t3 x---------------->|---------------->|---------------->x t4 850 | | | | IDMS Settings 851 | | | | reception 852 | ... | 853 | | | x t5: In Sync! 854 | | | RR + IDMS XR | 855 |<++++++++++++++++|+++++++++++++++++|+++++++++++++++++x 856 | ... | 858 Figure 6: IDMS Operation and Rapid Accommodation of Latecomers 860 The timing diagram for the RTCP exchange processes is illustrated in 861 Figure 6. It can be seen that, if enabling EED RTCP Feedback for 862 IDMS, the IDMS delay (which is the time interval between joining and 863 acquiring IDMS, represented by (t5 - t0) in Figure 6) for the 864 latecomer (k-th SC) can be significantly reduced, mainly due to the 865 fact that the MSAS delay ((t3 - t2) in Figure 6) can be minimized. 867 Although the above discussion has been focused for latecomers, it is 868 also applicable for reducing channel change (i.e., zapping) delays in 869 IDMS-enable sessions, which is currently a hot research topic in the 870 IPTV area. Concretely, the relevance of channel change delays and 871 their variability in IDMS-sensitive services is threefold. First, as 872 for inter-stream synchronization, the required time to receive the 873 IDMS setting instructions must not contribute to further increase the 874 channel change delays. Second, apart from the magnitudes of channel 875 change delays, their variability (i.e., the delay variation for each 876 user) will also impact the IDMS performance. Third, when a group of 877 users are watching IPTV together and they (simultaneously) change (or 878 must change) to another channel, any playout time differences among 879 them will also influence the resulting delay. Therefore, in this 880 context, the use of EED RTCP Feedback for IDMS is very beneficial 881 because: i) it significantly reduces the time needed to receive the 882 initial RTCP IDMS Settings packet; and ii) it enables the 883 compensation of the delay differences when changing channels. 885 Two additional mechanisms could contribute to further reduce the IDMS 886 Delay. The first one consists of employing priority mechanisms for 887 the transport of RTCP messages, e.g., by adopting a Differentiated 888 Services (DiffServ) policy. This would help to decrease the Round 889 Trip Time (RTT) delays and the loss probability for RTCP packets (out 890 of the scope of this document). The second one is based on the 891 transmission of Early RTCP-IDMS-REQ messages by latecomers upon 892 joining the session. According to [RFC6051], the delay since joining 893 and sending an RTCP-IDMS-REQ message ((t1-t0) in Figure 6) should not 894 be reduced to avoid flooding of requests at specific time instants 895 (e.g., at the time a broadcasted sport event begins). Although we 896 initially adhere to this standard compliant rule in this document, we 897 believe that it should be discussed within the AVTCORE WG if this 898 flash crowd effect is a real limiting issue in real SSM scenarios 899 (e.g., networked quiz shows, gaming, IPTV, etc.). Our initial 900 assumption is that the upstream bandwidth availability by the SCs 901 (which is not used for other purposes) and the aggregation and re- 902 distribution mechanisms by Feedback Targets [RFC5760] do not entail a 903 real constraint for allowing the transmission of Early RTCP-IDMS-REQ 904 by the SCs. Moreover, it is assumed in [RFC6051] that all SCs switch 905 channels simultaneously, but even though using automated procedures 906 (e.g., through notifications via the Electronic Program Guides in 907 IPTV), this would not be a matter of a few seconds, but most probably 908 of minutes. 910 5. Reduced-Size RTCP Reporting for IDMS 912 RTCP SR and RR contain relevant QoS statistics usable for monitoring 913 of the media stream transmission and thus enable media adaptation. 914 The regular transmission of these RTCP packets becomes very useful to 915 infer trends between successive reports due to the dynamic nature of 916 the conveyed information. Likewise, the tracking of the session size 917 thanks to that regular reports warrants bounded RTCP traffic 918 bandwidth. Moreover, compound RTCP packets are useful to establish 919 and maintain multimedia synchronization. Due to the above issues, 920 the regular transmission of compound RTCP packets must be maintained 921 throughout the RTP session's lifetime. 923 However, [RFC5506] defines certain changes to the RTCP reporting 924 rules to allow feedback messages to be sent as Reduced-Size RTCP 925 packets under certain conditions when using the RTP/AVPF profile 926 [RFC4585]. The motivation is that, in some cases, it is more useful 927 to report certain events of interest the more frequently or the 928 sooner as possible to enable short-term adaptation, rather than 929 sending full compound RTCP packets including periodic statistics. 931 In low bitrate links (e.g. radio access technologies), there are some 932 benefits of reporting Reduced-Size RTCP packets. First, if channels 933 conditions are poor, smaller RTCP packets are much more likely to be 934 successfully transmitted than larger compound RTCP packets, and they 935 will also introduce lower traffic overhead. The last issue is 936 critical, as those messages are likely to occur when channel 937 conditions are poor (e.g., for reporting picture or slice loss). 938 Second, the serialization time when transmitting small size RTCP 939 packets is shorter than when transmitting full (larger) RTCP compound 940 packets. Third, when the bandwidth availability is scarce, smaller 941 RTCP packets will enable more frequent feedback messages. 943 In high bitrate environments, the above issues are not real 944 limitations, but using Reduced-Size RTCP packets may also be 945 beneficial to reduce the processing delay and complexity of RTCP 946 packets. 948 Independently of the link type, additional benefits with sending 949 feedback in small Reduced-Size RTCP packets can be cited. For 950 instance, when using Early RTCP Feedback [RFC4585], receivers 951 typically need to send frequent event-driven feedback messages. In 952 such cases, if using Reduced-Sized RTCP packets, the risk that the 953 RTCP bandwidth becomes too high during periods of heavy feedback 954 signaling is reduced. 956 More details about use cases for, benefits of and issues with 957 Reduced-Size RTP reporting can be found in [RFC5506]. 959 Accordingly, the use of Reduced-Size RTCP packets MAY also be 960 beneficial when enabling the EED RTCP reporting rules for IDMS 961 proposed in this document. [RFC5506] specifies that in Immediate 962 Feedback mode, as it is the case of RTCP IDMS Settings packets, all 963 feedback messages may be sent as Reduced-Size RTCP packets. However, 964 it is also stated that Reduced-Size RTCP packets shall not be sent 965 until at least one compound RTCP packet has been transmitted. 967 This implies that if the use of non-compound RTCP packets [RFC5506] 968 has been previously negotiated between the participants in an IDMS- 969 enabled session, both the RTCP-IDMS-REQ and the RTCP IDMS Settings 970 packets MAY be sent as non-compound RTCP packets, but only if a 971 compound RTCP packet has been already sent by the senders of those 972 feedback messages. 974 The Reduced-Size RTCP reporting features do not apply to the first 975 IDMS Settings packet, which SHOULD be sent in parallel with the 976 initial RTP data packets (Section 4.1). In such a case, SCs would 977 also be benefited by the reception of a compound RTCP packet 978 including SR and SDES packets. This is also the case when a 979 latecomer sends an Early RTCP-IDMS-REQ. Here, the media sender and 980 the MSAS would also need an SDES packet from that latecomer for 981 membership accounting. 983 However, the use of Reduced-Size RTCP reporting MAY be beneficial 984 when an RTCP-IDMS-REQ is sent by an active SC that has not received 985 an RTCP IDMS Settings packet for a long period, requesting re- 986 synchronization setting instructions. Moreover, Reduced-Size RTCP 987 reporting MAY be especially useful for Dynamic EED transmission of 988 IDMS Settings packets (Section 4.2), e.g. immediately after detecting 989 an out-of-sync situation, or when a specific media event is targeted 990 to be simultaneously presented in all the SCs. 992 Reduced-Size RTCP packets can become substantially smaller than 993 compound packets. A compound packet is forced to contain both an RR 994 or an SR and an SDES with at least the CNAME item. The RR containing 995 a report block for a single source is 32 bytes, and an SR is 52 996 bytes. Both may be larger if they contain report blocks for multiple 997 sources. The SDES packet containing a CNAME item will be 10 bytes 998 plus the CNAME string length. Here, it is reasonable that the CNAME 999 string is at least 10 bytes to get a decent collision resistance. If 1000 the recommended form of user@host is used, then most strings will be 1001 longer than 20 characters. Additionally, for IDMS purposes: i) SCs 1002 will regularly send RTCP XR blocks for IDMS, which consist of 10 1003 32-bit words (40 bytes); ii) the MSAS will send RTCP IDMS Settings 1004 packets, which consists of 9 32-bit words (36 bytes). 1006 Therefore, Reduced-Size RTCP packets can become at least 70-80 bytes 1007 smaller than RTCP compound packets, thus reducing the mean RTCP 1008 packet size, decreasing sporadic traffic peaks, reducing the 1009 transmission delay, and increasing the overall RTCP feedback 1010 frequency. 1012 6. Security Considerations 1014 This document does not impose security considerations, beyond the 1015 ones described in [RFC3550], [RFC4585], [RFC6051], and [RFC7272]. 1017 7. IANA Considerations 1019 This document defines a new RTP/AVPF transport layer feedback message 1020 [RFC4585], called RTCP-IDMS-REQ, whose FMT Value needs to be assigned 1021 by IANA.. 1023 8. Contributors 1025 Authors would like to thank the co-authors of [RFC7272] for their 1026 collaboration on specifying the RTCP extensions for IDMS, which are 1027 starting point of this work. 1029 9. Conclusions 1031 This document proposes Early Event-Driven RTCP reporting rules to 1032 enable higher interactivity, dynamism and accuracy when using RTP/ 1033 RTCP for IDMS. 1035 10. References 1037 10.1. Normative References 1039 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1040 Requirement Levels", BCP 14, RFC 2119, March 1997. 1042 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1043 Jacobson, "RTP: A Transport Protocol for Real-Time 1044 Applications", STD 64, RFC 3550, July 2003. 1046 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 1047 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 1048 3556, July 2003. 1050 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 1051 Protocol Extended Reports (RTCP XR)", RFC 3611, November 1052 2003. 1054 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1055 "Extended RTP Profile for Real-time Transport Control 1056 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 1057 2006. 1059 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1060 Real-Time Transport Control Protocol (RTCP): Opportunities 1061 and Consequences", RFC 5506, April 2009. 1063 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1064 Media Attributes in the Session Description Protocol 1065 (SDP)", RFC 5576, June 2009. 1067 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1068 Protocol (RTCP) Extensions for Single-Source Multicast 1069 Sessions with Unicast Feedback", RFC 5760, February 2010. 1071 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 1072 Flows", RFC 6051, November 2010. 1074 [RFC7272] van Brandenburg, R., Stokking, H., van Deventer, O., 1075 Boronat, F., Montagud, M., and K. Gross, "Inter- 1076 Destination Media Synchronization (IDMS) Using the RTP 1077 Control Protocol (RTCP)", RFC 7272, June 2014. 1079 10.2. Informative References 1081 [Montagud2012] 1082 Montagud, M., Boronat, F., Stokking, H., and R. van 1083 Brandenburg, ""Inter-Destination Multimedia 1084 Synchronization; Schemes, Use Cases and Standardization", 1085 Multimedia Systems Journal (Springer), 18(6), pp. 1086 459-482", November 2012, . 1089 [Montagud2013] 1090 Montagud, M., Boronat, F., and H. Stokking, ""Early Event- 1091 Driven (EED) RTCP Feedback for Rapid IDMS", The 21st ACM 1092 International Conference on Multimedia (ACM MM 2013), 1093 Barcelona (Spain)", October 2013, 1094 . 1096 [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP 1097 Control Protocol (RTCP)", RFC 5968, September 2010. 1099 Authors' Addresses 1100 Mario Montagud (editor) 1101 Universitat Politecnica de Valencia 1102 C/ Paraninf, 1 1103 Grau de Gandia, Valencia 46730 1104 Spain 1106 Phone: +34 962 849 341 1107 Email: mamontor@upv.es 1109 Fernando Boronat 1110 Universitat Politecnica de Valencia 1111 C/ Paraninf, 1 1112 Grau de Gandia, Valencia 46730 1113 Spain 1115 Phone: +34 962 849 341 1116 Email: fboronat@dcom.upv.es 1118 Hans Stokking 1119 TNO 1120 Brassersplein 2 1121 Delft 2612CT 1122 The Netherlands 1124 Phone: +31-88-866-7000 1125 Email: hans.stokking@tno.nl