idnits 2.17.1 draft-ietf-avtcore-rtp-multi-stream-optimisation-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3550, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2013) is 3942 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 225, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 366, but not defined ** Obsolete normative reference: RFC 6222 (Obsoleted by RFC 7022) == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-rtp-multi-stream-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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 Updates: 3550 (if approved) M. Westerlund 5 Intended status: Standards Track Ericsson 6 Expires: January 12, 2014 Q. Wu 7 Huawei 8 C. Perkins 9 University of Glasgow 10 July 11, 2013 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-00 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 January 12, 2014. 45 Copyright Notice 47 Copyright (c) 2013 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. Grouping of RTCP Reception Statistics and Other Feedback . . 3 65 3.1. Semantics and Behavior of Reporting Groups . . . . . . . 3 66 3.2. Determine the Report Group . . . . . . . . . . . . . . . 4 67 3.3. RTCP Packet Reporting Group's Reporting Sources . . . . . 5 68 3.4. RTCP Source Description (SDES) item for Reporting Groups 6 69 3.5. Middlebox Considerations . . . . . . . . . . . . . . . . 6 70 3.6. SDP signaling for Reporting Groups . . . . . . . . . . . 6 71 3.7. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 6 72 3.8. Consequences of RTCP Reporting Groups . . . . . . . . . . 7 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 6.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for 83 group communication, supporting multiparty multimedia sessions. A 84 single RTP session can support multiple participants sending at once, 85 and can also support participants sending multiple simultaneous media 86 streams. Examples of the latter might include a participant with 87 multiple cameras who chooses to send multiple views of a scene, or a 88 participant that sends audio and video flows multiplexed in a single 89 RTP session. Rules for handling RTP sessions containing multiple 90 media streams are described in [RFC3550] with some clarifications in 91 [I-D.ietf-avtcore-rtp-multi-stream]. 93 An RTP endpoint will have one or more synchronisation sources (SSRCs) 94 that send and receive media streams (it will have one SSRC for each 95 media stream it sends). Each SSRC has to send RTCP sender reports 96 corresponding to the RTP packets it sends, and receiver reports for 97 traffic it receives. That is, every SSRC will send RTCP packets to 98 report on every other SSRC. This rule is simple, but can be quite 99 inefficient for endpoints that send large numbers of media streams in 100 a single RTP session. Consider a session comprising ten 101 participants, each sending three media streams with their own SSRC. 102 There will be 30 SSRCs in such an RTP session, and 30 RTCP reception 103 reports will be sent per reporting interval as each SSRC reports on 104 all the others. However, the three SSRCs comprising each participant 105 will almost certainly see identical reception quality, since they are 106 co-located. If there was a way to indicate that several SSRCs are 107 co-located, and see the same reception quality, then two-thirds of 108 those RTCP reports could be suppressed. 110 This memo defines such an RTCP extension, Reporting Groups. This 111 extension is used to indicate the SSRCs that originate from the same 112 endpoint, and therefore have identical reception quality, allowing 113 the endpoint to suppress unnecessary RTCP reception reports. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Grouping of RTCP Reception Statistics and Other Feedback 123 3.1. Semantics and Behavior of Reporting Groups 125 An RTCP Reporting Group indicates that a set of sources (SSRCs) that 126 originate from a single entity (endpoint or middlebox) in an RTP 127 session, and therefore all the sources in the group have an identical 128 view of the network. If reporting groups are in use, two sources 129 SHOULD be put into the same reporting group if their view of the 130 network is identical; i.e., if they report on traffic received at the 131 same interface of an RTP endpoint. Sources with different views of 132 the network MUST NOT be put into the same reporting group. 134 If reporting groups are in use, an endpoint MUST NOT send reception 135 reports from one source in a reporting group about another one in the 136 same group ("self-reports"). Similarly, an endpoint MUST NOT send 137 reception reports about a remote media source from more than one 138 source in a reporting group ("cross-reports"). Instead, it MUST pick 139 one of its local media sources as the "reporting" source for each 140 remote media source, and use it to send reception reports about that 141 remote source; all the other media sources in the reporting group 142 MUST NOT send any reception reports about that remote media source. 144 This reporting source MUST also be the source for any RTP/AVPF 145 Feedback [RFC4585] or Extended Report (XR) [RFC3611] packets about 146 the corresponding remote sources as well. If a reporting source 147 leaves the session (i.e., if it sends a BYE, or leaves the group 148 without sending BYE under the rules of [RFC3550] section 6.3.7), 149 another reporting source MUST be chosen if any members of the group 150 still exist. 152 An endpoint or middlebox MAY use multiple sources as reporting 153 sources; however, each reporting source MUST have non-overlapping 154 sets of remote SSRCs it reports on. This is primarily to be done 155 when the reporting source's number of reception report blocks is so 156 large that it would be forced to round-robin around the sources. 157 Thus, by splitting the reports among several reporting SSRCs, more 158 consistent reporting can be achieved. 160 If RTP/AVPF feedback is in use, a reporting source MAY send immediate 161 or early feedback at any point when any member of the reporting group 162 could validly do so. 164 An endpoint SHOULD NOT create single-source reporting groups, unless 165 it is anticipated that the group might have additional sources added 166 to it in the future. 168 3.2. Determine the Report Group 170 A remote RTP entity, such as an endpoint or a middlebox needs to be 171 able to determine the report group used by another RTP entity. To 172 achieve this goal two RTCP extensions have been defined. For the 173 SSRCs that are reporting on behalf of the reporting group, an SDES 174 item RGRP has been defined for providing the report group with an 175 identifier. For SSRCs that aren't reporting on any peer SSRC a new 176 RTCP packet type is defined. This RTCP packet type "Reporting 177 Sources" lists the SSRC that are reporting on this SSRC's behalf. 179 This divided approach has been selected for the following reasons: 181 1. To enable an explicit indication of who reports on this SSRC's 182 behalf. Being explicit prevents the remote entity from detecting 183 that is missing the reports if there issues with the reporting 184 SSRC's RTCP packets. 186 2. To enable explicit identification of the SSRCs that are actively 187 reporting as one entity. 189 3.3. RTCP Packet Reporting Group's Reporting Sources 191 This section defines a new RTCP packet type called "Reporting Group's 192 Reporting Sources" (RGRS). It identifies the SSRC(s) that report on 193 behalf of the SSRC that is the sender of the RGRS packet. 195 This packet consists of the fixed RTCP packet header which indicates 196 the packet type, the number of reporting sources included and the 197 SSRC which behalf the reporting SSRCs report on. This is followed by 198 the list of reporting SSRCs. 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |V=2|P| SC | PT=RGRS(TBA) | length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | SSRC of packet sender | 206 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 207 : SSRC for Reporting Source : 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 The RTCP Packets field has the following definition. 212 version (V): This field identifies the RTP version. The current 213 version is 2. 215 padding (P): 1 bit If set, the padding bit indicates that the packet 216 contains additional padding octets at the end that are not part of 217 the control information but are included in the length field. See 218 [RFC3550]. 220 Source Count (SC): 5 bits Indicating the number of reporting SSRCs 221 (1-31) that are included in this RTCP packet type. 223 Payload type (PT): 8 bits This is the RTCP packet type that 224 identifies the packet as being an RTCP FB message. The RGRS RTCP 225 packet has the value [TBA]. 227 Length: 16 bits The length of this packet in 32-bit words minus one, 228 including the header and any padding. This is in line with the 229 definition of the length field used in RTCP sender and receiver 230 reports [RFC3550]. 232 SSRC of packet sender: 32 bits. The SSRC of the sender of this 233 packet which indicates which SSRCs that reports on its behalf, 234 instead of reporting itself. 236 SSRC for Reporting Source: A variable number (as indicated by Source 237 Count) of 32-bit SSRC values. Each SSRC is an reporting SSRC 238 belonging to the same Report Group. 240 Each RGRS packet MUST contain at least one reporting SSRC. In case 241 the reporting SSRC field is insufficient to list all the SSRCs that 242 are reporting in this report group, the SSRC SHALL round robin around 243 the reporting sources. 245 Any RTP mixer or translator which forwards SR or RR packets from 246 members of a reporting group MUST forward the corresponding RGRS RTCP 247 packet as well. 249 3.4. RTCP Source Description (SDES) item for Reporting Groups 251 A new RTCP Source Description (SDES) item is defined for the purpose 252 of identifying reporting groups. 254 The Source Description (SDES) item "RGRP" is sent by a reporting 255 group's reporting SSRC. Syntactically, its format is the same as the 256 RTCP SDES CNAME item [RFC6222], and MUST be chosen with the same 257 global-uniqueness and privacy considerations as CNAME. This name 258 MUST be stable across the lifetime of the reporting group, even if 259 the SSRC of a reporting source changes. 261 Every source which belongs to a reporting group MUST either include 262 an RGRP SDES item in an SDES packet (if it is a reporting source), or 263 an RGRS packet (if it is not), in every compound RTCP packet in which 264 it sends an RR or SR packet (i.e., in every RTCP packet it sends, 265 unless Reduced-Size RTCP [RFC5506] is in use). 267 Any RTP mixer or translator which forwards SR or RR packets from 268 members of a reporting group MUST forward the corresponding RGRP SDES 269 items as well, even if it otherwise strips SDES items other than 270 CNAME. 272 3.5. Middlebox Considerations 274 This section discusses middlebox considerations for Reporting groups. 276 To be expanded. 278 3.6. SDP signaling for Reporting Groups 280 TBD 282 3.7. Bandwidth Benefits of RTCP Reporting Groups 283 To understand the benefits of RTCP reporting groups, consider a 284 scenario in which the two endpoints in a session each have a hundred 285 sources, of which eight each are sending within any given reporting 286 interval. 288 For ease of analysis, we can make the simplifying approximation that 289 the duration of the RTCP reporting interval is equal to the total 290 size of the RTCP packets sent during an RTCP interval, divided by the 291 RTCP bandwidth. (This will be approximately true in scenarios where 292 the bandwidth is not so high that the minimum RTCP interval is 293 reached.) For further simplification, we can assume RTCP senders are 294 following the recommendations regarding Compound RTCP Packets in 295 [I-D.ietf-avtcore-rtp-multi-stream]; thus, the per-packet transport- 296 layer overhead will be small relative to the RTCP data. Thus, only 297 the actual RTCP data itself need be considered. 299 In a report interval in this scenario, there will, as a baseline, be 300 200 SDES packets, 184 RR packets, and 16 SR packets. This amounts to 301 approximately 6.5 kB of RTCP per report interval, assuming 16-byte 302 CNAMEs and no other SDES information. 304 Using the original [RFC3550] everyone-reports-on-every-sender 305 feedback rules, each of the 184 receivers will send 16 report blocks, 306 and each of the 16 senders will send 15. This amounts to 307 approximately 76 kB of report block traffic per interval; 92% of RTCP 308 traffic consists of report blocks. 310 If reporting groups are used, however, there is only 0.4 kB of 311 reports per interval, with no loss of useful information. 312 Additionally, there will be (assuming 16-byte RGRPs, and a single 313 reporting source per reporting group) an additional 2.4 kB per cycle 314 of RGRP SDES items and RGRS packets. Put another way, the unmodified 315 [RFC3550] reporting interval is approximately 8.9 times longer than 316 if reporting groups are in use. 318 3.8. Consequences of RTCP Reporting Groups 320 The RTCP traffic generated by receivers using RTCP Reporting Groups 321 might appear, to observers unaware of these semantics, to be 322 generated by receivers who are experiencing a network disconnection, 323 as the non-reporting sources appear not to be receiving a given 324 sender at all. 326 This could be a potentially critical problem for such a sender using 327 RTCP for congestion control, as such a sender might think that it is 328 sending so much traffic that it is causing complete congestion 329 collapse. 331 However, such an interpretation of the session statistics would 332 require a fairly sophisticated RTCP analysis. Any receiver of RTCP 333 statistics which is just interested in information about itself needs 334 to be prepared that any given reception report might not contain 335 information about a specific media source, because reception reports 336 in large conferences can be round-robined. 338 Thus, it is unclear to what extent such backward compatibility issues 339 would actually cause trouble in practice. 341 4. Security Considerations 343 The security considerations of [RFC3550] and 344 [I-D.ietf-avtcore-rtp-multi-stream] apply. 346 (tbd: any security considerations due to these extensions?) 348 5. IANA Considerations 350 (Note to the RFC-Editor: please replace "TBA" with the IANA-assigned 351 value, and "XXXX" with the number of this document, prior to 352 publication as an RFC.) 354 The IANA is requested to register one new RTCP SDES items in the 355 "RTCP SDES Item Types" registry, as follows: 357 Value Abbrev Name Reference 358 TBA RGRP Reporting Group [RFCXXXX] 360 Figure 1: Item for the IANA Source Attribute Registry 362 The IANA is also requested to register one new RTCP packet type as 363 follows: 365 Value Abbrev Name Reference 366 TBA RGRR Reporting Group Reporting Sources [RFCXXXX] 368 Figure 2: Item for the IANA RTCP Control Packet Types (PT) Registry 370 6. References 372 6.1. Normative References 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, March 1997. 377 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 378 Jacobson, "RTP: A Transport Protocol for Real-Time 379 Applications", STD 64, RFC 3550, July 2003. 381 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 382 Choosing RTP Control Protocol (RTCP) Canonical Names 383 (CNAMEs)", RFC 6222, April 2011. 385 6.2. Informative References 387 [I-D.ietf-avtcore-rtp-multi-stream] 388 Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "RTP 389 Considerations for Endpoints Sending Multiple Media 390 Streams", draft-ietf-avtcore-rtp-multi-stream-00 (work in 391 progress), April 2013. 393 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 394 Protocol Extended Reports (RTCP XR)", RFC 3611, November 395 2003. 397 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 398 "Extended RTP Profile for Real-time Transport Control 399 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 400 2006. 402 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 403 Real-Time Transport Control Protocol (RTCP): Opportunities 404 and Consequences", RFC 5506, April 2009. 406 Authors' Addresses 408 Jonathan Lennox 409 Vidyo, Inc. 410 433 Hackensack Avenue 411 Seventh Floor 412 Hackensack, NJ 07601 413 US 415 Email: jonathan@vidyo.com 416 Magnus Westerlund 417 Ericsson 418 Farogatan 6 419 SE-164 80 Kista 420 Sweden 422 Phone: +46 10 714 82 87 423 Email: magnus.westerlund@ericsson.com 425 Qin Wu 426 Huawei 427 101 Software Avenue, Yuhua District 428 Nanjing, Jiangsu 210012 429 China 431 Email: sunseawq@huawei.com 433 Colin Perkins 434 University of Glasgow 435 School of Computing Science 436 Glasgow G12 8QQ 437 United Kingdom 439 Email: csp@csperkins.org