Network Working Group G. Babonneau Internet-Draft X. Marjou Intended status: Standards Track E. Stephan Expires: January 6, 2011 France Telecom Orange july 5, 2010 SSRC Multiplexing for Unicast and Multicast RTP Sessions draft-babonneau-avt-ssrc-mux-for-port-mapping-00 Abstract [RFC4588] documents two methods to multiplex RTP sessions: session- multiplexing and SSRC-multiplexing. This document specifies the SSRC-multiplexing for RTP sessions. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Babonneau, et al. Expires January 6, 2011 [Page 1] Internet-Draft SSRC Multiplexing july 2010 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Babonneau, et al. Expires January 6, 2011 [Page 2] Internet-Draft SSRC Multiplexing july 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. SSRC multiplexing . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. SSRC-multiplexing for RET . . . . . . . . . . . . . . . . . 6 4.2. SSRC-multiplexing for RAMS . . . . . . . . . . . . . . . . 7 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Babonneau, et al. Expires January 6, 2011 [Page 3] Internet-Draft SSRC Multiplexing july 2010 1. Introduction [RFC4588] documents two methods to multiplex RTP sessions: Session- multiplexing and SSRC-multiplexing. [I-D.ietf-avt-ports-for-ucast-mcast-rtp] and [I-D.ietf-avt-ports-for-ucast-mcast-rtp] currently specify the use of the first method: sessions multiplexing. This document specifies the second method: SSRC multiplexing method. The main motivation being the acceleration of real time services like fast retransmission (RET) and rapid multicast source acquisition (RAMS) in presence of NAT. Section 1 develops the motivation. Section 2 specifies the SSRC multiplexing for RET and RAMS. Section 3 discusses the solution. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119]. The following terms are given to avoid misunderstanding between [I-D.ietf-avt-ports-for-ucast-mcast-rtp], [RFC4588] and [RFC5760] Terminology. session-multiplexing: [RFC4588]specifies Session-multiplexing as a scheme by which the original stream and the associated retransmission stream are sent into two different RTP sessions. SSRC-multiplexing: [RFC4588]specifies SSRC-multiplexing as a scheme by which the original stream and the retransmission stream are sent in the same RTP session with different SSRC values. source1: The initial source (e.g. multicast source) of content is named 'source1' in this document. source1 is sometime named 'Media sender'. source2: The additional source (e.g. RAMS and RET server) of content to multiplex with the initial source is named 'source2' in this document. Source2 is sometime named 'Distribution Source'. Retransmission (RET): [RFC4588] specifies Retransmission request as a means by which an RTP receiver is able to request the retransmission of the original packet. Usually, an RTCP FB NACK packet as specified in[RFC4588]is used as retransmission request for lost packets. Rapid multicast source acquisition (RAMS): Babonneau, et al. Expires January 6, 2011 [Page 4] Internet-Draft SSRC Multiplexing july 2010 [I-D.ietf-avt-rapid-acquisition-for-rtp]specifies the RTCP FB RAMS request based on [RFC4588] is used to request for the burst of packets of the new channel. 3. Motivation The delay to switch from one TV channel to another is much longer on IP multicast than on broadcast network because on IP networks the receiver does not receive all the channels simultaneously. The loss of IP packets multicasted over IP networks decreases the quality of the video received because it introduces blockyness. RAMS [draft-ietf-avt-rapid-acquisition-for-rtp-10] defines a method that reduces the acquisition delay when a receiver switch among different multicast session, such as video broadcasts. RET [RFC4588] defines an RTP retransmission method that repairs packet losses between an RTP sender and a receiver. SSRC multiplexing is part of this effort. The motivation for this draft is to specify a method that reduces the number of packets exchanged and the processing time to improve and guarantee RAMS and RET performance. Briefly saying, SSRC multiplexing is based on the sharing of the same transport parameters by a request/response procedure like RET or RAMS, each direction having its own SSRC identifier: The RTCP request initiates the NAT binding for downloading the RTP content. As the 2 directions share the NAT binding there is not port mapping need. Per design RET and RAMS must improve the QoE of the multicast video session considered. The usage of RET must reduce the blockyness. The usage of RAMS must reduce the zapping duration. Both rely on the ability of the server 'source2' to send the data requested in real time over RTP. Delaying the response must be avoided because it reduces the improvement of the QoE intrinsically expected. Additional processing must be avoided because it introduces non deterministic delay which may jeopardize the initial objective. SSRC-multiplexing reduces the processing duration in the server and in the terminal. It reduces the processing in the server. It reduces the processing and simplifies the logic in the terminal: the response arrives naturally on the port which sent the request. Furthermore, the real time request/response approach of the SSRC- multiplexing guarantees the aliveness of the NAT binding. Babonneau, et al. Expires January 6, 2011 [Page 5] Internet-Draft SSRC Multiplexing july 2010 4. SSRC multiplexing This section specifies SSRC-multiplexing for RET and RAMS. According to [RFC4588], when ssrc-multiplexed is selected, each RTP session has its own SSRC, so that RTCP messages can distinguish them whatever RTP sessions are multicast or unicast. 4.1. SSRC-multiplexing for RET This section specifies SSRC-multiplexing for RET. In the figure below SSRC multiplexing occurs because the new RTP session created by source2 to send the missing packets shares the transport parameters (addresses, port) of the session which requests the packets retransmission. Consequently the streams corresponding to the 2 SSRCs share the natural NAT binding. The RTCP upstream opens the NAT for the RTP download stream. source1 source2 NAT Receiver | | | | | RTP multicast SSRC_ChA | | 1 |--------.------>| | | | \----------------X---------------->|--------->| | | packets loss | | | | | | | | | | | RTCP FB NACK Port2 SSRC_B, SSRC_ChA | | 2 | |<==========================|<=========| | | | | | | | | | | RTP Port2 SSRC_C | | 3 | |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~>| | | | | Figure 1: SSRC-multiplexing for RET Step 1: source1 sends RTP packets with SSRC_ChA that identifies the video session. Source2 receives the packets. Receiver detects several lost of packets. Step 2: The receiver requests a fast retransmission (RET) of the packets not received, it sends a RTCP FB NACK message in a session identified by a SSRC chosen by itself. This message identifies the packets of channel A requested. Step 3: source2 sends the retransmission packet with the same ports and IP addresses than the RTCP FB message received. The flow of retransmitted packet is identified by a new SSRC SSRC_C. Babonneau, et al. Expires January 6, 2011 [Page 6] Internet-Draft SSRC Multiplexing july 2010 4.2. SSRC-multiplexing for RAMS This section specifies SSRC-multiplexing for RAMS. In the figure below SSRC multiplexing occurs because the new RTP session created by source2 to send the burst of channel B content reuses the transport parameters (addresses, port) of the RTCP request: SSRC_B and SSRC_C are multiplexed over the same transport session. source1 source2 NAT Receiver | | | | | RTP multicastA SSRC_ChA | | 1 |--------.------>| | | | \--------------------------------->|--------->| | | | | | RTP multicastB SSRC_ChB | | |--------------->| | | | | | | | | | | | RTCP RAMS Port2 SSRC_B, SSRC_ChB | | 2 | |<==========================|<=========| | | | | | | | | | | RTP Port2 SSRC_C | | 3 | |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~>| | | | | Figure 2: SSRC-multiplexing for RAMS Step 1: Source1 sends RTP packets of Channel A in a session identified with SSRC_ChA. Step 2: when the user switches to channel B, its terminal sends a RTCP RAMS request in a session identified by a SSRC choosen locally, SSRC_B. The RAMS request includes the identifier of the new channel selected, the SSRC of Channel_B. Step 3: source2 sends the retransmission packet with the same ports and IP addresses than the RTCP RAMS request received. The flow of retransmited packet is identified by a new SSRC SSRC_C choosen locally by source2. After receiving the RAMS content the terminal switches to the regular source of Channel B content, source1. Babonneau, et al. Expires January 6, 2011 [Page 7] Internet-Draft SSRC Multiplexing july 2010 5. Discussion Keep Alive: The adding of extra signaling and processing does not benefit of NAT binding naturally created by the request . One consequence is the need of additional messages to maintain the session open on the NAT. In other term the bootstrap of the session may be so long that the NAT has closed the session before the RET or the RAMS traffic is sent by the server source2. Performance: RET and RAMS were introduced to improve the QoE of multicast video sessions. RET is designed to reduce the blockyness. RAMS is designed to reduce the zapping duration. Both rely on the ability of the server 'source2' to send the data requested in real time over RTP. The adding of extra signaling and processing delays the response and consequently reduces the improvement of the QoE intrisically expected. SSRC-multiplexing reduces the processing duration in the server and in the terminal. It reduces the processing in the server. It reduces the processing and simplifies the logic in the terminal: the response arrives naturally on the port which sent the request without additional processing. Scalability: The adding of extra signaling and processing like Keeplive and NAT binding management adds non deterministic processing duration and resource comsumption in the server source2. This prevent any optimization of the deployment of RET and RAMS services. NAT binding management: NAT binding maps the local transport parameters on the public transport parameters. It must be performed for each service request to capture any change of local transport parameters. The adding of extra signaling and processing during the binding must be avoided at this step to keep the delay of response as low as possible. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Babonneau, et al. Expires January 6, 2011 [Page 8] Internet-Draft SSRC Multiplexing july 2010 7. Security Considerations The scope of application of the SSRC multiplexing specified in this document is limited to the cases of there is a NAT on the path. 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.ietf-avt-ports-for-ucast-mcast-rtp] Begen, A. and B. Steeg, "Port Mapping Between Unicast and Multicast RTP Sessions", draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in progress), May 2010. [I-D.ietf-avt-rapid-acquisition-for-rtp] Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- Based Rapid Acquisition of Multicast RTP Sessions", draft-ietf-avt-rapid-acquisition-for-rtp-10 (work in progress), May 2010. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006. [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, February 2010. Appendix A. An Appendix Babonneau, et al. Expires January 6, 2011 [Page 9] Internet-Draft SSRC Multiplexing july 2010 Authors' Addresses Gerard Babonneau France Telecom Orange 4, rue du Clos Courtel Cesson Sevigne 35510 France Email: gerard.babonneau@orange-ftgroup.com Xavier Marjou France Telecom Orange 2, avenue Pierre Marzin Lannion 22307 France Email: xavier.marjou@orange-ftgroup.com Stephan Emile France Telecom Orange 2 avenue Pierre Marzin Lannion F-22307 France Email: emile.stephan@orange-ftgroup.com Babonneau, et al. Expires January 6, 2011 [Page 10]