idnits 2.17.1 draft-babonneau-avt-ssrc-mux-for-port-mapping-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 abstract seems to contain references ([RFC4588]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date () is 739398 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) == Unused Reference: 'I-D.ietf-avt-rapid-acquisition-for-rtp' is defined on line 341, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-avt-ports-for-ucast-mcast-rtp-02 == Outdated reference: A later version (-17) exists of draft-ietf-avt-rapid-acquisition-for-rtp-10 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Babonneau 3 Internet-Draft X. Marjou 4 Intended status: Standards Track E. Stephan 5 Expires: January 6, 2011 France Telecom Orange 6 july 5, 2010 8 SSRC Multiplexing for Unicast and Multicast RTP Sessions 9 draft-babonneau-avt-ssrc-mux-for-port-mapping-00 11 Abstract 13 [RFC4588] documents two methods to multiplex RTP sessions: session- 14 multiplexing and SSRC-multiplexing. This document specifies the 15 SSRC-multiplexing for RTP sessions. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 6, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. SSRC multiplexing . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. SSRC-multiplexing for RET . . . . . . . . . . . . . . . . . 6 74 4.2. SSRC-multiplexing for RAMS . . . . . . . . . . . . . . . . 7 75 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 82 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 [RFC4588] documents two methods to multiplex RTP sessions: Session- 88 multiplexing and SSRC-multiplexing. 89 [I-D.ietf-avt-ports-for-ucast-mcast-rtp] and 90 [I-D.ietf-avt-ports-for-ucast-mcast-rtp] currently specify the use of 91 the first method: sessions multiplexing. This document specifies the 92 second method: SSRC multiplexing method. The main motivation being 93 the acceleration of real time services like fast retransmission (RET) 94 and rapid multicast source acquisition (RAMS) in presence of NAT. 96 Section 1 develops the motivation. Section 2 specifies the SSRC 97 multiplexing for RET and RAMS. Section 3 discusses the solution. 99 2. Terminology 101 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 102 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 103 and "OPTIONAL" are to be interpreted as described in RFC 2119 104 [RFC2119]. 106 The following terms are given to avoid misunderstanding between 107 [I-D.ietf-avt-ports-for-ucast-mcast-rtp], [RFC4588] and [RFC5760] 108 Terminology. 110 session-multiplexing: [RFC4588]specifies Session-multiplexing as a 111 scheme by which the original stream and the associated retransmission 112 stream are sent into two different RTP sessions. 114 SSRC-multiplexing: [RFC4588]specifies SSRC-multiplexing as a scheme 115 by which the original stream and the retransmission stream are sent 116 in the same RTP session with different SSRC values. 118 source1: The initial source (e.g. multicast source) of content is 119 named 'source1' in this document. source1 is sometime named 'Media 120 sender'. 122 source2: The additional source (e.g. RAMS and RET server) of content 123 to multiplex with the initial source is named 'source2' in this 124 document. Source2 is sometime named 'Distribution Source'. 126 Retransmission (RET): [RFC4588] specifies Retransmission request as a 127 means by which an RTP receiver is able to request the retransmission 128 of the original packet. Usually, an RTCP FB NACK packet as specified 129 in[RFC4588]is used as retransmission request for lost packets. 131 Rapid multicast source acquisition (RAMS): 133 [I-D.ietf-avt-rapid-acquisition-for-rtp]specifies the RTCP FB RAMS 134 request based on [RFC4588] is used to request for the burst of 135 packets of the new channel. 137 3. Motivation 139 The delay to switch from one TV channel to another is much longer on 140 IP multicast than on broadcast network because on IP networks the 141 receiver does not receive all the channels simultaneously. The loss 142 of IP packets multicasted over IP networks decreases the quality of 143 the video received because it introduces blockyness. 145 RAMS [draft-ietf-avt-rapid-acquisition-for-rtp-10] defines a method 146 that reduces the acquisition delay when a receiver switch among 147 different multicast session, such as video broadcasts. RET [RFC4588] 148 defines an RTP retransmission method that repairs packet losses 149 between an RTP sender and a receiver. 151 SSRC multiplexing is part of this effort. The motivation for this 152 draft is to specify a method that reduces the number of packets 153 exchanged and the processing time to improve and guarantee RAMS and 154 RET performance. 156 Briefly saying, SSRC multiplexing is based on the sharing of the same 157 transport parameters by a request/response procedure like RET or 158 RAMS, each direction having its own SSRC identifier: The RTCP request 159 initiates the NAT binding for downloading the RTP content. As the 2 160 directions share the NAT binding there is not port mapping need. 162 Per design RET and RAMS must improve the QoE of the multicast video 163 session considered. The usage of RET must reduce the blockyness. 164 The usage of RAMS must reduce the zapping duration. Both rely on the 165 ability of the server 'source2' to send the data requested in real 166 time over RTP. Delaying the response must be avoided because it 167 reduces the improvement of the QoE intrinsically expected. 168 Additional processing must be avoided because it introduces non 169 deterministic delay which may jeopardize the initial objective. 171 SSRC-multiplexing reduces the processing duration in the server and 172 in the terminal. It reduces the processing in the server. It 173 reduces the processing and simplifies the logic in the terminal: the 174 response arrives naturally on the port which sent the request. 175 Furthermore, the real time request/response approach of the SSRC- 176 multiplexing guarantees the aliveness of the NAT binding. 178 4. SSRC multiplexing 180 This section specifies SSRC-multiplexing for RET and RAMS. According 181 to [RFC4588], when ssrc-multiplexed is selected, each RTP session has 182 its own SSRC, so that RTCP messages can distinguish them whatever RTP 183 sessions are multicast or unicast. 185 4.1. SSRC-multiplexing for RET 187 This section specifies SSRC-multiplexing for RET. 189 In the figure below SSRC multiplexing occurs because the new RTP 190 session created by source2 to send the missing packets shares the 191 transport parameters (addresses, port) of the session which requests 192 the packets retransmission. Consequently the streams corresponding 193 to the 2 SSRCs share the natural NAT binding. The RTCP upstream 194 opens the NAT for the RTP download stream. 196 source1 source2 NAT Receiver 197 | | | | 198 | RTP multicast SSRC_ChA | | 199 1 |--------.------>| | | 200 | \----------------X---------------->|--------->| 201 | | packets loss | | 202 | | | | 203 | | | | 204 | RTCP FB NACK Port2 SSRC_B, SSRC_ChA | | 205 2 | |<==========================|<=========| 206 | | | | 207 | | | | 208 | | RTP Port2 SSRC_C | | 209 3 | |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~>| 210 | | | | 211 Figure 1: SSRC-multiplexing for RET 213 Step 1: source1 sends RTP packets with SSRC_ChA that identifies the 214 video session. Source2 receives the packets. Receiver detects 215 several lost of packets. 217 Step 2: The receiver requests a fast retransmission (RET) of the 218 packets not received, it sends a RTCP FB NACK message in a session 219 identified by a SSRC chosen by itself. This message identifies the 220 packets of channel A requested. 222 Step 3: source2 sends the retransmission packet with the same ports 223 and IP addresses than the RTCP FB message received. The flow of 224 retransmitted packet is identified by a new SSRC SSRC_C. 226 4.2. SSRC-multiplexing for RAMS 228 This section specifies SSRC-multiplexing for RAMS. 230 In the figure below SSRC multiplexing occurs because the new RTP 231 session created by source2 to send the burst of channel B content 232 reuses the transport parameters (addresses, port) of the RTCP 233 request: SSRC_B and SSRC_C are multiplexed over the same transport 234 session. 236 source1 source2 NAT Receiver 237 | | | | 238 | RTP multicastA SSRC_ChA | | 239 1 |--------.------>| | | 240 | \--------------------------------->|--------->| 241 | | | | 242 | RTP multicastB SSRC_ChB | | 243 |--------------->| | | 244 | | | | 245 | | | | 246 | RTCP RAMS Port2 SSRC_B, SSRC_ChB | | 247 2 | |<==========================|<=========| 248 | | | | 249 | | | | 250 | | RTP Port2 SSRC_C | | 251 3 | |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~>| 252 | | | | 254 Figure 2: SSRC-multiplexing for RAMS 256 Step 1: Source1 sends RTP packets of Channel A in a session 257 identified with SSRC_ChA. 259 Step 2: when the user switches to channel B, its terminal sends a 260 RTCP RAMS request in a session identified by a SSRC choosen locally, 261 SSRC_B. The RAMS request includes the identifier of the new channel 262 selected, the SSRC of Channel_B. 264 Step 3: source2 sends the retransmission packet with the same ports 265 and IP addresses than the RTCP RAMS request received. The flow of 266 retransmited packet is identified by a new SSRC SSRC_C choosen 267 locally by source2. 269 After receiving the RAMS content the terminal switches to the regular 270 source of Channel B content, source1. 272 5. Discussion 274 Keep Alive: 276 The adding of extra signaling and processing does not benefit of NAT 277 binding naturally created by the request . One consequence is the 278 need of additional messages to maintain the session open on the NAT. 279 In other term the bootstrap of the session may be so long that the 280 NAT has closed the session before the RET or the RAMS traffic is sent 281 by the server source2. 283 Performance: 285 RET and RAMS were introduced to improve the QoE of multicast video 286 sessions. RET is designed to reduce the blockyness. RAMS is 287 designed to reduce the zapping duration. Both rely on the ability of 288 the server 'source2' to send the data requested in real time over 289 RTP. The adding of extra signaling and processing delays the 290 response and consequently reduces the improvement of the QoE 291 intrisically expected. SSRC-multiplexing reduces the processing 292 duration in the server and in the terminal. It reduces the 293 processing in the server. It reduces the processing and simplifies 294 the logic in the terminal: the response arrives naturally on the port 295 which sent the request without additional processing. 297 Scalability: 299 The adding of extra signaling and processing like Keeplive and NAT 300 binding management adds non deterministic processing duration and 301 resource comsumption in the server source2. This prevent any 302 optimization of the deployment of RET and RAMS services. 304 NAT binding management: 306 NAT binding maps the local transport parameters on the public 307 transport parameters. It must be performed for each service request 308 to capture any change of local transport parameters. The adding of 309 extra signaling and processing during the binding must be avoided at 310 this step to keep the delay of response as low as possible. 312 6. IANA Considerations 314 This document makes no request of IANA. 316 Note to RFC Editor: this section may be removed on publication as an 317 RFC. 319 7. Security Considerations 321 The scope of application of the SSRC multiplexing specified in this 322 document is limited to the cases of there is a NAT on the path. 324 8. Acknowledgements 326 9. References 328 9.1. Normative References 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, March 1997. 333 9.2. Informative References 335 [I-D.ietf-avt-ports-for-ucast-mcast-rtp] 336 Begen, A. and B. Steeg, "Port Mapping Between Unicast and 337 Multicast RTP Sessions", 338 draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in 339 progress), May 2010. 341 [I-D.ietf-avt-rapid-acquisition-for-rtp] 342 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 343 Based Rapid Acquisition of Multicast RTP Sessions", 344 draft-ietf-avt-rapid-acquisition-for-rtp-10 (work in 345 progress), May 2010. 347 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 348 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 349 July 2006. 351 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 352 Protocol (RTCP) Extensions for Single-Source Multicast 353 Sessions with Unicast Feedback", RFC 5760, February 2010. 355 Appendix A. An Appendix 356 Authors' Addresses 358 Gerard Babonneau 359 France Telecom Orange 360 4, rue du Clos Courtel 361 Cesson Sevigne 35510 362 France 364 Email: gerard.babonneau@orange-ftgroup.com 366 Xavier Marjou 367 France Telecom Orange 368 2, avenue Pierre Marzin 369 Lannion 22307 370 France 372 Email: xavier.marjou@orange-ftgroup.com 374 Stephan Emile 375 France Telecom Orange 376 2 avenue Pierre Marzin 377 Lannion F-22307 378 France 380 Email: emile.stephan@orange-ftgroup.com