idnits 2.17.1 draft-ietf-avtcore-rtp-multi-stream-optimisation-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? 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: 'TBA' is mentioned on line 292, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 604, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-rtp-multi-stream-02 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE WG J. Lennox 3 Internet-Draft Vidyo 4 Intended status: Standards Track M. Westerlund 5 Expires: August 18, 2014 Ericsson 6 Q. Wu 7 Huawei 8 C. Perkins 9 University of Glasgow 10 February 14, 2014 12 Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP 13 Reception Statistics and Other Feedback 14 draft-ietf-avtcore-rtp-multi-stream-optimisation-02 16 Abstract 18 RTP allows multiple media streams to be sent in a single session, but 19 requires each Synchronisation Source (SSRC) to send RTCP reception 20 quality reports for every other SSRC visible in the session. This 21 causes the number of RTCP reception reports to grow with the number 22 of SSRCs, rather than the number of endpoints. In many cases most of 23 these RTCP reception reports are unnecessary, since all SSRCs of an 24 endpoint are co-located and see the same reception quality. This 25 memo defines a Reporting Group extension to RTCP to reduce the 26 reporting overhead in such scenarios. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 18, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. RTCP Reporting Groups . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Semantics and Behaviour of RTCP Reporting Groups . . . . 3 66 3.2. Identifying Members of an RTCP Reporting Group . . . . . 5 67 3.2.1. Definition and Use of the RTCP RGRP SDES Item . . . . 5 68 3.2.2. Definition and Use of the RTCP RGRS Packet . . . . . 6 69 3.3. Interactions with the RTP/AVPF Feedback Profile . . . . . 7 70 3.4. Interactions with RTCP Extended Report (XR) Packets . . . 8 71 3.5. Middlebox Considerations . . . . . . . . . . . . . . . . 9 72 3.6. SDP Signalling for Reporting Groups . . . . . . . . . . . 9 73 4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 9 74 4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 10 75 4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 10 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 7.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for 86 group communication, supporting multiparty multimedia sessions. A 87 single RTP session can support multiple participants sending at once, 88 and can also support participants sending multiple simultaneous media 89 streams. Examples of the latter might include a participant with 90 multiple cameras who chooses to send multiple views of a scene, or a 91 participant that sends audio and video flows multiplexed in a single 92 RTP session. Rules for handling RTP sessions containing multiple 93 media streams are described in [RFC3550] with some clarifications in 94 [I-D.ietf-avtcore-rtp-multi-stream]. 96 An RTP endpoint will have one or more synchronisation sources (SSRCs) 97 that send media streams. It will have at least one SSRC for each 98 media stream it sends, and might use multiple SSRCs when using media 99 scalability features [RFC6190], forward error correction, RTP 100 retransmission [RFC4588], or similar mechanisms. An endpoint that is 101 not sending any media streams, will have at least one SSRC to use for 102 reporting and any feedback messages. Each SSRC has to send RTCP 103 sender reports corresponding to the RTP packets it sends, and 104 receiver reports for traffic it receives. That is, every SSRC will 105 send RTCP packets to report on every other SSRC. This rule is 106 simple, but can be quite inefficient for endpoints that send large 107 numbers of media streams in a single RTP session. Consider a session 108 comprising ten participants, each sending three media streams with 109 their own SSRC. There will be 30 SSRCs in such an RTP session, and 110 30 RTCP reception reports will be sent per reporting interval as each 111 SSRC reports on all the others. However, the three SSRCs comprising 112 each participant will almost certainly see identical reception 113 quality, since they are co-located. If there was a way to indicate 114 that several SSRCs are co-located, and see the same reception 115 quality, then two-thirds of those RTCP reports could be suppressed. 116 This would allow the remaining RTCP reports to be sent more often, 117 while keeping within the same RTCP bandwidth fraction. 119 This memo defines such an RTCP extension, RTCP Reporting Groups. 120 This extension is used to indicate the SSRCs that originate from the 121 same endpoint, and therefore have identical reception quality, hence 122 allowing the endpoints to suppress unnecessary RTCP reception quality 123 reports. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. RTCP Reporting Groups 133 An RTCP Reporting Group is a set of synchronization sources (SSRCs) 134 that are co-located at a single endpoint (which could be an end host 135 or a middlebox) in an RTP session. Since they are co-located, every 136 SSRC in the RTCP reporting group will have an identical view of the 137 network conditions, and see the same lost packets, jitter, etc. This 138 allows a single representative to send RTCP reception quality reports 139 on behalf of the rest of the reporting group, reducing the number of 140 RTCP packets that need to be sent without loss of information. 142 3.1. Semantics and Behaviour of RTCP Reporting Groups 144 A group of co-located SSRCs that see identical network conditions can 145 form an RTCP reporting group. If reporting groups are in use, an RTP 146 endpoint with multiple SSRCs MAY put those SSRCs into a reporting 147 group if their view of the network is identical; i.e., if they report 148 on traffic received at the same interface of an RTP endpoint. SSRCs 149 with different views of the network MUST NOT be put into the same 150 reporting group. 152 An endpoint that has combined its SSRCs into an RTCP reporting group 153 will choose one (or a subset) of those SSRCs as a "reporting source" 154 for that RTCP reporting group. A reporting source will send RTCP SR/ 155 RR reception quality reports on behalf of the other members of the 156 RTCP reporting group. A reporting source MUST suppress the RTCP SR/ 157 RR reports that relate to other members of the reporting group, and 158 only report on remote SSRCs. The other members (non reporting 159 sources) of the RTCP reporting group will suppress their RTCP 160 reception quality reports, and instead send an RTCP RGRS packet (see 161 Section 3.2.2) to indicate that they are part of an RTCP reporting 162 group and give the SSRCs of the reporting sources. 164 If there are large numbers of remote SSRCs in the RTP session, then 165 the reception quality reports generated by the reporting source might 166 grow too large to fit into a single compound RTCP packet, forcing the 167 reporting source to use a round-robin policy to determine what remote 168 SSRCs it includes in each compound RTCP packet, and so reducing the 169 frequency of reports on each SSRC. To avoid this, in sessions with 170 large numbers of remote SSRCs, an RTCP reporting group MAY use more 171 than one reporting source. If several SSRCs are acting as reporting 172 sources for an RTCP reporting group, then each reporting source MUST 173 have non-overlapping sets of remote SSRCs it reports on. 175 An endpoint SHOULD NOT create an RTCP reporting group that comprises 176 only a single local SSRC (i.e., an RTCP reporting group where the 177 reporting source is the only member of the group), unless it is 178 anticipated that the group might have additional SSRCs added to it in 179 the future. 181 If a reporting source leaves the RTP session (i.e., if it sends a 182 RTCP BYE packet, or leaves the session without sending BYE under the 183 rules of [RFC3550] section 6.3.7), the remaining members of the RTCP 184 reporting group MUST either (a) have another reporting source, if 185 existing, report on the remote SSRCs the leaving SSRC reported on, 186 (b) choose a new reporting source, or (c) disband the RTCP reporting 187 group and begin sending reception quality reports following [RFC3550] 188 and [I-D.ietf-avtcore-rtp-multi-stream]. 190 The RTCP timing rules assign different bandwidth fractions to senders 191 and receivers. This lets senders to transmit RTCP reception quality 192 reports more often than receivers. If a reporting source in an RTCP 193 reporting group is a receiver, but one or more non-reporting SSRCs in 194 the RTCP reporting group are senders, then the endpoint MAY treat the 195 reporting source as a sender for the purpose of RTCP bandwidth 196 allocation, increasing its RTCP bandwidth allocation, provided it 197 also treats one of the senders as if it were a receiver and makes the 198 corresponding reduction in RTCP bandwidth for that SSRC. 200 3.2. Identifying Members of an RTCP Reporting Group 202 When RTCP Reporting Groups are in use, the other SSRCs in the RTP 203 session need to be able to identify which SSRCs are members of an 204 RTCP reporting group. Two RTCP extensions are defined to support 205 this: the RTCP RGRP SDES item is used by the reporting source(s) to 206 identify an RTCP reporting group, and the RTCP RGRS packet is used by 207 other members of an RTCP reporting group to identify the reporting 208 source(s). 210 3.2.1. Definition and Use of the RTCP RGRP SDES Item 212 A new RTCP SDES item is defined to identify an RTCP reporting group. 213 This motivation for giving a reporting group an identify is to ensure 214 that the RTCP reporting group and its member SSRCs can be correctly 215 associated when there are multiple reporting sources, and to ensure 216 that a reporting SSRC can be associated with the correct reporting 217 group if an SSRC collision occurs. 219 The RTCP Source Description (SDES) RGRP item is defined. The RTCP 220 SDES RGRP item MUST be sent by the reporting sources in a reporting 221 group, and MUST NOT be sent by other members of the reporting group 222 or by SSRCs that are not members of any RTCP reporting group. 223 Specifically, every reporting source in an RTCP reporting group MUST 224 include an RTCP SDES packet containing an RGRP item in every compound 225 RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP 226 packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). 228 Syntactically, the format of the RTCP SDES RGRP item is identical to 229 that of the RTCP SDES CNAME item [RFC7022]. The value of the RTCP 230 SDES RGRP item MUST be chosen with the same concerns about global 231 uniqueness and the same privacy considerations as the RTCP SDES CNAME 232 them. The value of the RTCP SDES RGRP item MUST be stable throughout 233 the lifetime of the reporting group, even if the some or all of the 234 reporting sources change their SSRC due to collisions, or if the set 235 of reporting sources changes. 237 An RTP mixer or translator that forwards RTCP SR or RR packets from 238 members of a reporting group MUST forward the corresponding RTCP SDES 239 RGRP items as well, even if it otherwise strips SDES items other than 240 the CNAME item. 242 3.2.2. Definition and Use of the RTCP RGRS Packet 244 A new RTCP packet type is defined to allow the members of an RTCP 245 reporting group to identify the reporting sources for that group. 246 This allows participants in an RTP session to distinguish an SSRC 247 that is sending empty RTCP reception reports because it is a member 248 of an RTCP reporting group, from an SSRC that is sending empty RTCP 249 reception reports because it is not receiving any traffic. It also 250 explicitly identifies the reporting sources, allowing other members 251 of the RTP session to know which SSRCs are acting as the reporting 252 sources for an RTCP reporting group, and allowing them to detect if 253 RTCP packets from any of the reporting sources are being lost. 255 The format of the RTCP RGRS packet is defined below. It comprises 256 the fixed RTCP header that indicates the packet type and length, the 257 SSRC of the packet sender, and a list of reporting sources for the 258 RTCP reporting group of which the packet sender is a member. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |V=2|P| SC | PT=RGRS(TBA) | length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | SSRC of packet sender | 266 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 267 : List of SSRCs for the Reporting Source(s) : 268 : ... : 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 The fields in the RTCP RGRS packet have the following definition: 273 version (V): This field identifies the RTP version. The current RTP 274 version is 2. 276 padding (P): If set, the padding bit indicates that the RTCP packet 277 contains additional padding octets at the end that are not part of 278 the control information but are included in the length field. See 279 [RFC3550]. 281 Source Count (SC): Indicates the number of reporting source SSRCs 282 that are included in this RTCP packet. As the RTCP RGRS packet 283 MUST NOT be not sent by reporting sources, all the SSRCs in the 284 list of reporting sources will be different from the SSRC of the 285 packet sender. Every RTCP RGRS packet MUST contain at least one 286 reporting source SSRC. 288 Payload type (PT): The RTCP packet type number that identifies the 289 packet as being an RTCP RGRS packet. The RGRS RTCP packet has the 290 value [TBA]. 292 Note to RFC Editor: please replace [TBA] here, and in the 293 packet format diagram above, with the RTCP packet type that 294 IANA assigns to the RTCP RGRS packet. 296 Length: The length of this packet in 32-bit words minus one, 297 including the header and any padding. This is in line with the 298 definition of the length field used in RTCP sender and receiver 299 reports [RFC3550]. Since all RTCP RGRS packets include at least 300 one reporting source SSRC, the length will always be 2 or greater. 302 SSRC of packet sender: The SSRC of the sender of this packet. 304 List of SSRCs for the Reporting Source(s): A variable length size 305 (as indicated by SC header field) of the 32 bit SSRC values of the 306 reporting sources for the RTCP Reporting Group of which the packet 307 sender is a member. 309 Every source that belongs to an RTCP reporting group but is not a 310 reporting source MUST include an RTCP RGRS packet in every compound 311 RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP 312 packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). Each 313 RTCP RGRS packet MUST contain the SSRC identifier of at least one 314 reporting source. If there are more reporting sources in an RTCP 315 reporting group than can fit into an RTCP RGRS packet, the members of 316 that reporting group MUST send the SSRCs of the reporting sources in 317 a round-robin fashion in consecutive RTCP RGRS packets, such that all 318 the SSRCs of the reporting sources are included over the course of 319 several RTCP reporting intervals. 321 An RTP mixer or translator that forwards RTCP SR or RR packets from 322 members of a reporting group MUST also forward the corresponding RGRS 323 RTCP packets. If the RTP mixer or translator rewrites SSRC values of 324 the packets it forwards, it MUST make the corresponding changes to 325 the RTCP RGRS packets. 327 3.3. Interactions with the RTP/AVPF Feedback Profile 329 Use of the RTP/AVPF Feedback Profile [RFC4585] allows SSRCs to send 330 rapid RTCP feedback requests and codec control messages. If use of 331 the RTP/AVPF profile has been negotiated in an RTP session, members 332 of an RTCP reporting group can send rapid RTCP feedback and codec 333 control messages following [RFC4585] and [RFC5104], as updated by 334 Section 5.4 of [I-D.ietf-avtcore-rtp-multi-stream], and by the 335 following considerations. 337 The members of an RTCP reporting group will all see identical network 338 conditions. Accordingly, one might therefore think that it doesn't 339 matter which SSRC in the reporting group sends the RTP/AVPF feedback 340 or codec control messages. There are, however, some cases where the 341 sender of the feedback/codec control message has semantic importance, 342 or when only a subset of the members of an RTCP reporting group might 343 want to send RTP/AVPF feedback or a codec control message in response 344 to a particular event. 346 Each member of an RTCP reporting group SHOULD therefore send RTP/AVPF 347 feedback/codec control messages independently of the other members of 348 the reporting group, to respect the semantic meaning of the message 349 sender. The suppression rules of [RFC4585] will ensure that only a 350 single copy of each feedback packet is (typically) generated, even if 351 several members of a reporting group send the same feedback. When an 352 endpoint knows that several members of its RTCP reporting group will 353 be sending identical feedback, and that the sender of the feedback is 354 not semantically important, then that endpoint MAY choose to send all 355 its feedback from the reporting source and deterministically suppress 356 feedback packets generated by the other sources in the reporting 357 group. 359 It is important to note that the RTP/AVPF timing rules operate on a 360 per-SSRC basis. Using a single reporting source to send all feedback 361 for a reporting group will hence limit the amount of feedback that 362 can be sent to that which can be sent by one SSRC. If this limit is 363 a problem, then the reporting group can allow each of its members to 364 send its own feedback, using its own SSRC. 366 If the RTP/AVPF feedback messages or codec control requests are sent 367 as compound RTCP packets, then those compound RTCP packets MUST 368 include either an RTCP RGRS packet or an RTCP SDES RGRP item, 369 depending on whether they are sent by the reporting source or a non- 370 reporting source in the RTCP reporting group respectively. The 371 contents of non-compound RTCP feedback or codec control messages are 372 not affected by the use of RTCP reporting groups. 374 3.4. Interactions with RTCP Extended Report (XR) Packets 376 When using RTCP Extended Reports (XR) [RFC3611] with RTCP reporting 377 groups, it is RECOMMENDED that the reporting source is used to send 378 the RTCP XR packets. If multiple reporting sources are in use, the 379 reporting source that sends the SR/RR packets that relate to a 380 particular remote SSRC SHOULD send the RTCP XR reports about that 381 SSRC. This is motivated as one commonly combine the RTCP XR metrics 382 with the regular report block to more fully understand the situation. 383 Receiving these blocks in different compound packets reduces their 384 value as the measuring intervals are not synchronized in those cases. 386 Some RTCP XR report blocks are specific to particular types of media, 387 so they are relevant to only some members of a reporting group. Such 388 XR reports MUST be sent by the source to which they are relevant, and 389 MUST NOT be included in the common report sent by the reporting 390 source. This can mean that some sources send XR packets in a 391 compound packet that contains an empty SR/RR packet and that the time 392 period covered by the XR packet is different to that covered by the 393 SR/RR packet. If it is important that the XR packet and SR/RR packet 394 cover the same time period, then that source SHOULD be removed from 395 the RTCP reporting group, and sent standard RTCP packets. 397 3.5. Middlebox Considerations 399 This section discusses middlebox considerations for Reporting groups. 401 (TBD: write this section) 403 3.6. SDP Signalling for Reporting Groups 405 This document defines the "a=rtcp-rgrp" Session Description Protocol 406 (SDP) [RFC4566] attribute to indicate if the session participant is 407 capable of supporting RTCP Reporting Groups for applications that use 408 SDP for configuration of RTP sessions. A participant that proposes 409 the use of RTCP Reporting Groups SHALL itself support the reception 410 of RTCP Reporting Groups. 412 An offering client that wishes to use RTCP Reporting Groups MUST 413 include the attribute "a=rtcp-rgrp" in the SDP offer. If "a=rtcp- 414 rgrp" is present in the offer SDP, the answerer that supports RTCP 415 Reporting Groups and wishes to use it SHALL include the "a=rtcp-rgrp" 416 attribute in the answer. 418 In declarative usage of SDP, such as the Real Time Streaming Protocol 419 (RTSP) [RFC2326] and the Session Announcement Protocol (SAP) 420 [RFC2974], the presence of the attribute indicates that the session 421 participant MAY use RTCP Reporting Groups in its RTCP transmissions. 423 4. Properties of RTCP Reporting Groups 425 This section provides additional information on what the resulting 426 properties are with the design specified in Section 3. The content 427 of this section is non-normative. 429 4.1. Bandwidth Benefits of RTCP Reporting Groups 431 To understand the benefits of RTCP reporting groups, consider a 432 scenario in which the two endpoints in a session each have a hundred 433 sources, of which eight each are sending within any given reporting 434 interval. 436 For ease of analysis, we can make the simplifying approximation that 437 the duration of the RTCP reporting interval is equal to the total 438 size of the RTCP packets sent during an RTCP interval, divided by the 439 RTCP bandwidth. (This will be approximately true in scenarios where 440 the bandwidth is not so high that the minimum RTCP interval is 441 reached.) For further simplification, we can assume RTCP senders are 442 following the recommendations regarding Compound RTCP Packets in 443 [I-D.ietf-avtcore-rtp-multi-stream]; thus, the per-packet transport- 444 layer overhead will be small relative to the RTCP data. Thus, only 445 the actual RTCP data itself need be considered. 447 In a report interval in this scenario, there will, as a baseline, be 448 200 SDES packets, 184 RR packets, and 16 SR packets. This amounts to 449 approximately 6.5 kB of RTCP per report interval, assuming 16-byte 450 CNAMEs and no other SDES information. 452 Using the original [RFC3550] everyone-reports-on-every-sender 453 feedback rules, each of the 184 receivers will send 16 report blocks, 454 and each of the 16 senders will send 15. This amounts to 455 approximately 76 kB of report block traffic per interval; 92% of RTCP 456 traffic consists of report blocks. 458 If reporting groups are used, however, there is only 0.4 kB of 459 reports per interval, with no loss of useful information. 460 Additionally, there will be (assuming 16-byte RGRPs, and a single 461 reporting source per reporting group) an additional 2.4 kB per cycle 462 of RGRP SDES items and RGRS packets. Put another way, the unmodified 463 [RFC3550] reporting interval is approximately 8.9 times longer than 464 if reporting groups are in use. 466 4.2. Compatibility of RTCP Reporting Groups 468 The RTCP traffic generated by receivers using RTCP Reporting Groups 469 might appear, to observers unaware of these semantics, to be 470 generated by receivers who are experiencing a network disconnection, 471 as the non-reporting sources appear not to be receiving a given 472 sender at all. 474 This could be a potentially critical problem for such a sender using 475 RTCP for congestion control, as such a sender might think that it is 476 sending so much traffic that it is causing complete congestion 477 collapse. 479 However, such an interpretation of the session statistics would 480 require a fairly sophisticated RTCP analysis. Any receiver of RTCP 481 statistics which is just interested in information about itself needs 482 to be prepared that any given reception report might not contain 483 information about a specific media source, because reception reports 484 in large conferences can be round-robined. 486 Thus, it is unclear to what extent such backward compatibility issues 487 would actually cause trouble in practice. 489 5. Security Considerations 491 The security considerations of [RFC3550] and 492 [I-D.ietf-avtcore-rtp-multi-stream] apply. If the RTP/AVPF profile 493 is in use, then the security considerations of [RFC4585] (and 494 [RFC5104], if used) also apply. If RTCP XR is used, the security 495 consideration of [RFC3611] and any XR report blocks used also apply. 497 The RTCP SDES RGRP item is vulnerable to malicious modifications 498 unless integrity protected is used. A modification of this item's 499 length field cause the parsing of the RTCP packet in which it is 500 contained to fail. Depending on the implementation, parsing of the 501 full compound RTCP packet can also fail causing the whole packet to 502 be discarded. A modification to the value of this SDES item would 503 make the receiver of the report think that the sender of the report 504 was a member of a different RTCP reporting group. This will 505 potentially create an inconsistency, when the RGRS reports the source 506 as being in the same reporting group as another source with another 507 reporting group identifier. What impact on a receiver implementation 508 such inconsistencies would have are difficult to fully predict. One 509 case is when congestion control or other adaptation mechanisms are 510 used, an inconsistent report can result in a media sender to reduce 511 its bit-rate. However, a direct modification of the receiver report 512 or a feedback message itself would be a more efficient attack, and 513 equally costly to perform. 515 The new RGRS RTCP Packet type is very simple. The common RTCP packet 516 type header shares the security risks with previous RTCP packet 517 types. Errors or modification of the length field can cause the full 518 compound packet to fail header validation (see Appendix A.2 in 519 [RFC3550]) resulting in the whole compound RTCP packet being 520 discarded. Modification of the SC or P fields would cause 521 inconsistency when processing the RTCP packet, likely resulting it 522 being classified as invalid. A modification of the PT field would 523 cause the packet being interpreted under some other packet type's 524 rules. In such case the result might be more or less predictable but 525 packet type specific. Modification of the SSRC of packet sender 526 would attribute this packet to another sender. Resulting in a 527 receiver believing the reporting group applies also for this SSRC, if 528 it exists. If it doesn't exist, unless also corresponding 529 modifications are done on a SR/RR packet and a SDES packet the RTCP 530 packet SHOULD be discarded. If consistent changes are done, that 531 could be part of a resource exhaustion attack on a receiver 532 implementation. Modification of the "List of SSRCs for the Reporting 533 Source(s)" would change the SSRC the receiver expect to report on 534 behalf of this SSRC. If that SSRC exist, that could potentially 535 change the report group used for this SSRC. A change to another 536 reporting group belonging to another endpoint is likely detectable as 537 there would be a mismatch between the SSRC of the packet sender's 538 endpoint information, transport addresses, SDES CNAME etc and the 539 corresponding information from the reporting group indicated. 541 In general the reporting group is providing limited impacts attacks. 542 The most significant result from an deliberate attack would be to 543 cause the information to be discarded or be inconsistent, including 544 discard of all RTCP packets that are modified. This causes a lack of 545 information at any receiver entity, possibly disregarding the 546 endpoints participation in the session. 548 To protect against this type of attacks from external non trusted 549 entities, integrity and source authentication SHOULD be applied. 550 This can be done, for example, by using SRTP [RFC3711] with 551 appropriate key-management, other options exist as discussed in RTP 552 Security Options [I-D.ietf-avtcore-rtp-security-options]. 554 The Report Group Identifier has a potential privacy impacting 555 properties. If this would be generated by an implementation in such 556 a way that is long term stable or predictable, it could be used for 557 tracking a particular end-point. Therefore it is RECOMMENDED that it 558 be generated as a short-term persistent RGRP, following the rules for 559 short-term persistent CNAMEs in [RFC7022]. The rest of the 560 information revealed, i.e. the SSRCs, the size of reporting group 561 and the number of reporting sources in a reporting group is of less 562 sensitive nature, considering that the SSRCs and the communication 563 would anyway be revealed without this extension. By encrypting the 564 report group extensions the SSRC values would preserved confidential, 565 but can still be revealed if SRTP [RFC3711] is used. The size of the 566 reporting groups and number of reporting sources are likely 567 determinable from analysis of the packet pattern and sizes. However, 568 this information appears to have limited value. 570 6. IANA Considerations 572 (Note to the RFC-Editor: please replace "TBA" with the IANA-assigned 573 value, and "XXXX" with the number of this document, prior to 574 publication as an RFC.) 576 The IANA is requested to register one new RTCP SDES items in the 577 "RTCP SDES Item Types" registry, as follows: 579 Value Abbrev Name Reference 580 TBA RGRP Reporting Group Identifier [RFCXXXX] 582 Figure 1: Item for the IANA Source Attribute Registry 584 The IANA is also requested to register one new RTCP packet type as 585 follows: 587 Value Abbrev Name Reference 588 TBA RGRS Reporting Group Reporting Sources [RFCXXXX] 590 Figure 2: Item for the IANA RTCP Control Packet Types (PT) Registry 592 The IANA is also request to register one new SDP attribute "a=rtcp- 593 rgrp": 595 SDP Attribute ("att-field"): 596 Attribute name: rtcp-rgrp 597 Long form: RTCP Reporting Groups 598 Type of name: att-field 599 Type of attribute: Media or session level 600 Subject to charset: No 601 Purpose: Negotiate or configure the usage of the RTCP 602 Reporting Group Extension. 603 Reference: [RFCXXXX] 604 Values: See [RFCXXXX] 606 7. References 608 7.1. Normative References 610 [I-D.ietf-avtcore-rtp-multi-stream] 611 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, 612 "Sending Multiple Media Streams in a Single RTP Session", 613 draft-ietf-avtcore-rtp-multi-stream-02 (work in progress), 614 January 2014. 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, March 1997. 619 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 620 Jacobson, "RTP: A Transport Protocol for Real-Time 621 Applications", STD 64, RFC 3550, July 2003. 623 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 624 Description Protocol", RFC 4566, July 2006. 626 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 627 "Guidelines for Choosing RTP Control Protocol (RTCP) 628 Canonical Names (CNAMEs)", RFC 7022, September 2013. 630 7.2. Informative References 632 [I-D.ietf-avtcore-rtp-security-options] 633 Westerlund, M. and C. Perkins, "Options for Securing RTP 634 Sessions", draft-ietf-avtcore-rtp-security-options-10 635 (work in progress), January 2014. 637 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 638 Streaming Protocol (RTSP)", RFC 2326, April 1998. 640 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 641 Announcement Protocol", RFC 2974, October 2000. 643 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 644 Protocol Extended Reports (RTCP XR)", RFC 3611, November 645 2003. 647 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 648 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 649 RFC 3711, March 2004. 651 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 652 "Extended RTP Profile for Real-time Transport Control 653 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 654 2006. 656 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 657 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 658 July 2006. 660 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 661 "Codec Control Messages in the RTP Audio-Visual Profile 662 with Feedback (AVPF)", RFC 5104, February 2008. 664 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 665 Real-Time Transport Control Protocol (RTCP): Opportunities 666 and Consequences", RFC 5506, April 2009. 668 [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. 669 Eleftheriadis, "RTP Payload Format for Scalable Video 670 Coding", RFC 6190, May 2011. 672 Authors' Addresses 674 Jonathan Lennox 675 Vidyo, Inc. 676 433 Hackensack Avenue 677 Seventh Floor 678 Hackensack, NJ 07601 679 US 681 Email: jonathan@vidyo.com 683 Magnus Westerlund 684 Ericsson 685 Farogatan 6 686 SE-164 80 Kista 687 Sweden 689 Phone: +46 10 714 82 87 690 Email: magnus.westerlund@ericsson.com 692 Qin Wu 693 Huawei 694 101 Software Avenue, Yuhua District 695 Nanjing, Jiangsu 210012 696 China 698 Email: sunseawq@huawei.com 700 Colin Perkins 701 University of Glasgow 702 School of Computing Science 703 Glasgow G12 8QQ 704 United Kingdom 706 Email: csp@csperkins.org