Network Working Group I. Johansson Internet-Draft Ericsson AB Intended status: Standards Track June 9, 2010 Expires: December 11, 2010 Extended Rapid Acquisition of Multicast RTP Sessions (ERAMS) draft-johansson-avt-mcast-based-rams-03 Abstract This document proposes Extended RAMS (ERAMS), which is a complement to the unicast based Rapid Acquisition for Multicast based Streaming (RAMS) discussed in [ID-RAMS]. The outline of this added functionality to RAMS is to gather up Rapid Acquisition requests for many users and transmit them in dedicated multicast streams. With this technique the peak load on the retransmission server and on the outgoing link from the retransmission server can be reduced. For a problem description of the channel change problem in multicast based IPTV the reader is encouraged to read [ID-RAMS]. 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 December 11, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Johansson Expires December 11, 2010 [Page 1] Internet-Draft Extended RAMS June 2010 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 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. Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. RAMS-R Message . . . . . . . . . . . . . . . . . . . . 7 3.2.2. RAMS-I Message . . . . . . . . . . . . . . . . . . . . 8 3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Different max Bitrates . . . . . . . . . . . . . . . . 8 3.3.2. Reaction to Packet Loss . . . . . . . . . . . . . . . 9 3.3.3. RTP/RTCP Port Multiplexing . . . . . . . . . . . . . . 9 3.4. Alternative Solutions . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4.1. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 10 4.2. RAMS Response Code Space Registry . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Johansson Expires December 11, 2010 [Page 2] Internet-Draft Extended RAMS June 2010 1. Definitions This document uses the following acronyms and definitions frequently: RTP_Rx: RTP Receiver RS: Retransmission Server TLV: Type Length Value (field) STB: Set Top Box More acronyms are defined in [ID-RAMS]. 2. Introduction Draft [ID-RAMS] proposes a method for fast channel change in multicast RTP session that employs setting up separate unicast burst transmissions to set top boxes that changes channel. The method should considerably reduce the channel switch latency experienced by the end user. There are a number of potential issues with the aforementioned method. o Peaky load pattern: Viewers of popular IPTV channels may display a synchronized behavior in their channel change pattern , for instance when a commercial break sets in or a popular TV show ends. o High load on the retransmission server: The retransmission server will sometimes be exposed to high load, also the load on the outgoing link from the retransmission server can be very high. This means that the retransmission server and the outgoing link typically needs to be over provisioned, something that may be costly for the implementer of the IPTV infrastructure. This draft explains how multiple rapid acquisition requests can be gathered up and served via a dedicated multicast channel and can be used as an improvement to the method described in [ID-RAMS]. The additional delay compared to a solely unicast based version depends on the gather up time which can be set quite low during low load conditions and set to higher values during high load conditions (giving graceful degradation). The benefit is that the peak load on the retransmission server is reduced considerably. Another method that is described is to setup multicast control channels that Johansson Expires December 11, 2010 [Page 3] Internet-Draft Extended RAMS June 2010 contains information about rapid acquisition multicast feeds that are active. Section 5 in [ID-RAMS] states "Rapid acquisition is an optimization of a system that must continue to work correctly whether or not the optimization is effective, or even fails due to lost control messages, congestion, or other problems". The method described in this draft promises to ensure that resource usage is optimized and thus helps to avoid e.g congestion. Furthermore section 6.4 [ID-RAMS] says "However, a higher rate for the burst also increases the chances for congestion-caused packet loss. Thus, as discussed in Section 5, there must be an upper bound on the extra bandwidth used by the burst". The method described in this draft minimizes the load on the RS as well as the outgoing link from it. 3. Description The proposed solution can serve as a complement to the solution outlined in [ID-RAMS]. During low load conditions the retransmission server (RS) will serve each RAMS-R request from an RTP_Rx in an STB (set-top box) with an individual unicast RTP burst as described in [ID-RAMS]. As the load increases the RS will gather up RAMS-R for the same channels over a defined time window (Td) and set up a multicast stream that contains the same contents as the unicast stream would have done. The time window that is used to gather up RAMS-R requests for the same channel is made dependent on the load on the RS. During fairly low load conditions the time window is made small (e.g Td=50ms), as load gets higher the time window increases, thus the degradation in channel switching performance will become graceful. 3.1. Message Flow The figure below displays how Extended RAMS would work. Johansson Expires December 11, 2010 [Page 4] Internet-Draft Extended RAMS June 2010 +--------+ +---------+ +--------+ +----------+ +----------+ | M.cast | | Re-TX | | | | RTP | | RTP | | Source | | Server | | Router | | Receiver | | Receiver | | | | (RS) | | | |(RTP_Rx-1)| |(RTP_Rx-2)| +--------+ +---------+ +--------+ +----------+ +----------+ | | | | | |- RTP M.cast------------------->| | | | | | | | |- RTP M.cast >| | | | | | | | | | |<''''''''' RTCP RAMS-R: Chl: A '| |----- | | | | | | |'(RTCP RAMS-I:Redirect Addr:X)'>| | | | |<~ SFGMP J. X~| | | | | | | | |<''''''''' RTCP RAMS-R: Chl: A'''''''''''' | Td | | | | | | |'(RTCP RAMS-I:Redirect Addr:X)''''''''''''>| | | |<~ SFGMP Join X~~~~~~~~~~| | | | | |----- | |'(RTCP RAMS-I:on Mcast Addr:X)'>| | | |'(RTCP RAMS-I:on Mcast Addr:X)''''''''''''>| | |RTP Burst on Multicast Addr:X.>| | | |..RTP Burst on Multicast Addr:X..........>| | | | | | | | | | | | | |<~ SFGMP J. A~| | | | |<~ SFGMP Join A~~~~~~~~~~| | | | | | |-- RTP Multicast ----------------------------->| | |--------RTP Multicast ----------------------------------->| | | | | | | |<'''''''''''''''' RTCP RAMS-T ''| | | |<'''''''''''''''''' RTCP RAMS-T '''''''''''| | | | | | | |<''''''''''''''''' (RTCP NACK)''| | | |<''''''''''''''''' (RTCP NACK)'''''''''''''| | | | | | | |..(Unicast Retransmissions) ...>| | | |..(Unicast Retransmissions) .... .........>| | | | | | | |<''''''''''''''''' (RTCP BYE) ''| | | |<''''''''''''''''' (RTCP BYE) '''''''''''''| | | | | | RTP_Rx-1 transmits a RAMS-R to RS, requesting rapid acquisition data Johansson Expires December 11, 2010 [Page 5] Internet-Draft Extended RAMS June 2010 for channel A, as RTP_Rx-1 is the first to request this data, a timer is started in order to wait for a given time span (Td) for other RAMS-R for the same channel from other RTP_Rx's. RS sends a RAMS-I to RTP_Rx-1 with instructions to listen in on a specified multicast address (X) and thus RS-1 makes an SFGMP Join to said multicast address. The response code in RAMS-I when ERAMS is used is a 3xx response code [Number TBD]. Later RTP_Rx-2 sends a RAMS-R to RS, requesting rapid acquisition data for channel A. RS sends a RAMS-I to RTP_Rx-2 with instructions to listen in on X (as defined above) and RS-2 also makes an SFGMP Join to the said multicast address When the timer (Td) is expired, RS will stream the requested data on multicast channel X. The data speed in the multicast channel is preferably higher than normal playout speed (e.g 120%). When sufficient data has been received via the multicast channel X, both RTP_Rx-1 and RTP_Rx-2 makes an SFGMP Join to multicast channel A. As Td is made dependent on the load on the RS this method allows for graceful degradation. A special case occurs when the timer expires and only one RTP_Rx has sent a request, this case is similar to the unicast streaming case already specified in [ID-RAMS]. At severe load conditions the RAMS-R requests will be either ignored or responded with a negative acknowledgement (error code 501), in which case the RTP_Rx's will not receive any rapid acquisition data. There are a few different ways to determine when a switch from the rapid acquisition channel to the normal multicast channel should be made: 1. A multicast control channel tells the RTP_Rx that it is time to switch or can give the RTP_Rx sufficient information necessary to make the switch 2. The RS informs the RTP_Rx about the synchronization point in a RAMS-I message. 3. A marker in the rapid acquisition media stream tells the RTP_Rx to make a switch 4. Count of frames, the RTP_Rx can itself decide to switch after receiving e.g 3 I-frames. In this case the RTP_Rx must know the Johansson Expires December 11, 2010 [Page 6] Internet-Draft Extended RAMS June 2010 size of the RS buffer to avoid a gap in the stream. This information can be provided for in the RAMS-I message. In certain cases (for instance if downlink bandwidth is limited) it is preferable that the rapid acquisition stream to a particular RTP_Rx is terminated (e.g by means of SFGMP Leave) before the normal multicast channel is joined. Depending on how the decision to switch is made there is a slight possibility that data will be missing, to alleviate this risk the normal multicast streams can be delayed a fraction of a second to allow for a certain switching time and a smooth transition from the rapid acquisition data to the normal multicast channel. Extended RAMS here has the benefit that the join and leave messages can be sent simultaneously or almost simultaneously and to the same endpoint. This reduces the risk of having parallel streams over the last mile interface with lower risk of congestion as a result. 3.2. Message 3.2.1. RAMS-R Message The Extended RAMS solution implements a new TLV field to the RAMS-R to indicate support for Extended RAMS 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=62 | Length=1 |6|4|A|S|R R R R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type Type number for message = 62 Flags: 6 : Supports IPv6 4 : Supports IPv4 A = Supports ASM S = Supports SSM R = reserved The new TLV field is included in a RAMS-R when the RTP_Rx supports Extended RAMS and prefers to use the mechanism. The field contains a few flags that can be combined. Johansson Expires December 11, 2010 [Page 7] Internet-Draft Extended RAMS June 2010 3.2.2. RAMS-I Message The Extended RAMS solution implements a new TLV field to the RAMS-I message 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=63 | Length |S|R R R R R R R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Multicast address to join in : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | port | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type number for message = 63 Flags: S : Address is a (S,G) address (SSM) R = reserved If S flag is specified the Source address is specified first, then the Group address The TLV field contains only one flag, namely the S-flag that indicates that the address is a source, group pair. Whether the address is an IPv4 or IPv6 address is inferred from the length field and the S-flag. [ Ed. note it is not certain that the S-flag is really needed, it may be sufficient to signal this in the session setup information instead]. The RAMS-I message MUST use the response code 3xx [number TBD] An RTP_Rx SHOULD use this TLV field in the RAMS-T if this TLV was included in a RAMS-I. The values of the TLV field should be the same as in the RAMS-I. This may help the RS to determine when to terminate the ERAMS flow completely. 3.3. Considerations 3.3.1. Different max Bitrates It is possible that the RTP_Rx that sends RAMS-R for a given channel also indicate different Max Receive Bitrate in their requests. A retransmission server that serves the RAMS-R has to adapt its transmission rate to the RAMS-R request with the lowest indicated Max Receive Bitrate. An option is to collect the RAMS-R in two or more groups, each group can then provide with different transmission Johansson Expires December 11, 2010 [Page 8] Internet-Draft Extended RAMS June 2010 bitrates. 3.3.2. Reaction to Packet Loss Packet losses may occur in the ERAMS transmission. In normal cases an RTP_Rx that detects packet losses can request retransmission from the retransmission server. However, as ERAMS is to be used in conditions where the load on the RS is high it is NOT RECOMMENDED to request retransmission as the chance that this retransmission request can be served is anyway minimal. If the packet loss is severe the RTP_Rx MAY also to send a RAMS-T prematurely. This may be helpful in resolving congestion situations. 3.3.3. RTP/RTCP Port Multiplexing A system that supports ERAMS SHOULD implement and use RTP/RTCP port multiplexing, this simplifies setup of ERAMS considerably as the number of multicast flows that are setup is half of that compared to the case when RTP/RTCP port multiplexing is not used. 3.4. Alternative Solutions Besides the methodology described above, another possibility is also that an RTP_Rx joins a multicast control channel which contains information about which multicast channel contains rapid acquisition data for a given channel. Because of the limited amount of data that is carried in this multicast control channel, reliable transmission techniques can possibly be used. 4. IANA Considerations The following contact information shall be used for all registrations in this document: Ingemar Johansson ingemar.s.johansson@ericsson.com Laboratoriegrand 11 971 28 Lulea Sweden Note to the RFC Editor: In the following, please replace "XXXX" with the number of this document prior to publication as an RFC. Johansson Expires December 11, 2010 [Page 9] Internet-Draft Extended RAMS June 2010 4.1. RAMS TLV Space Registry This document adds two TLV's to the TLV's already defined in [ID-RAMS]. Type Description Reference ---- -------------------------------------------------- ------------- 62 RAMS-R ERAMS Request [RFCXXXX] 63 RAMS-I ERAMS Response, RAMS-T ERAMS Tag [RFCXXXX] 4.2. RAMS Response Code Space Registry This document adds a response code to the response codes already defined in [ID-RAMS]. Code Description Reference ----- -------------------------------------------------- ------------- 3xx ERAMS redirect [RFCXXXX] 5. Security Considerations This draft does not pose any additional security issues than those listed in [ID-RAMS]. 6. Acknowledgements The author wish to thank Mats Cedervall, Victor Souza, Hareesh Puthalath, Thomas Lundqvist, Joacim Halen and Paul Higgs for help with this draft. 7. Normative References [ID-RAMS] IETF, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions, https://datatracker.ietf.org/doc/ draft-ietf-avt-rapid-acquisition-for-rtp/". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Johansson Expires December 11, 2010 [Page 10] Internet-Draft Extended RAMS June 2010 Author's Address Ingemar Johansson Ericsson AB Laboratoriegrand 11 SE-971 28 Lulea SWEDEN Phone: +46 73 0783289 Email: ingemar.s.johansson@ericsson.com Johansson Expires December 11, 2010 [Page 11]