Audio/Video Transport WG Y.-K. Wang Internet Draft J. Dai Intended status: Standards track J. Feng Expires: January 2010 Huawei Technologies July 6, 2009 Improved Rapid Acquisition of Multicast Sessions draft-wang-avt-rtp-improved-rams-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 6, 2010. Wang, Dai & Feng Expires January 6, 2010 [Page 1] Internet-Draft Improved RAMS July 2009 Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes an improvement to unicast based rapid acquisition of multicast RTP sessions (RAMS) described in [I- D.ietf-avt-rapid-acquisition-for-rtp]. The improved method allows a receiver to simultaneously request a unicast burst stream and join the multicast group, and then select one of the two streams to be first processed. Table of Contents 1. Introduction..................................................2 2. Conventions...................................................5 3. Improved Rapid Acquisition of Multicast RTP Sessions..........6 4. Security Considerations.......................................8 5. IANA Considerations...........................................8 6. Acknowledgements..............................................8 7. References....................................................9 8. Authors' Addresses............................................9 1. Introduction The basic idea of unicast based rapid acquisition of multicast RTP sessions (RAMS) in [I-D.ietf-avt-rapid-acquisition-for-rtp] is as follows. Instead of joining the multicast group, the receiver first requests a unicast stream, which is transmitted at a rate faster than the multicast stream rate. The unicast stream starts from a random access point, which contains the so-called Reference Wang, Dai & Feng Expires January 6, 2010 [Page 2] Internet-Draft Improved RAMS July 2009 Information (RI) or the start of the RI, and thus can be processed without waiting for the next random access point, and consequently the delay for acquisition of the multicast stream is reduced. This method is effective in reducing channel switching and tune-in delay in multicast applications, such as IPTV. Another important benefit of RAMS is that significantly improved coding efficiency for video streams is possible. In conventional multicast applications, video streams must be encoded with frequent random access points, e.g. per 0.5 to 1 second, to allow new receivers to tune-in or existing users to switch from another multicast session. Random access points typically contain intra- coded pictures, for which the compression efficiency is significantly, e.g., several to ten times, lower than inter-coded pictures. Therefore, the less the random access points, the higher the coding efficiency. When RAMS is in use, random access period length no longer affects the tune-in or channel switching delay. This means that the video random access point frequency can be significantly reduced, which means significantly improved compression efficiency. Nevertheless, RAMS has the following constraints: o At some point, if the receiver directly joins the multicast group, the received multicast stream may start exactly at a random access point or at a point that is very close to the next random access point. In this case, the use of the RAMS method actually increases the acquisition delay. Unfortunately, the receiver has no means to know how far the next random access point in the multicast stream is before it joins the multicast group, otherwise it could choose to either use RAMS or directly join the multicast group, whichever is better. o The request for the unicast burst stream may be lost. Even if the request is retransmitted and finally received, the acquisition delay gets increased. Wang, Dai & Feng Expires January 6, 2010 [Page 3] Internet-Draft Improved RAMS July 2009 o Part or all of the RI may be lost. Again, the lost information could be retransmitted, which increases the acquisition delay. If the RI or part of it gets finally lost in any case, the received data in the unicast burst stream cannot be processed until the next random access point. In this case, the acquisition delay would also be lower if the receiver had chosen to directly join the multicast group without trying to request the unicast burst stream. Unfortunately, there is no way for the receiver to know what loss could happen before the occurrence of the loss. To solve the above problems, this document proposes an improved RAMS method, wherein the receiver simultaneously requests the unicast burst stream and joins the multicast group. When both the unicast burst stream and the multicast stream are transmitted to the receiver, the downlink bandwidth needed is at least twice as high as the media rate (including the overhead due to network protocol headers). Different than the original RAMS method in [I- D.ietf-avt-rapid-acquisition-for-rtp], herein the unicast burst stream does not need to be transmitted at a rate higher than the media rate, though a higher rate can still be used if possible. The proposed scheme is rationalized based on the following observations. Wang, Dai & Feng Expires January 6, 2010 [Page 4] Internet-Draft Improved RAMS July 2009 o A user who has a certain network accessing bandwidth can typically upgrade the access bandwidth without upgrade of the network accessing equipment. This means that the network access equipment can typically support higher bandwidth. On the other hand it may not be a major issue for the network provider to send data to the user at a bandwidth higher than the single stream to the user, unless there is limitation on the data sent by the network provider. In the context of unicast based rapid acquisition of multicast streams, as the data of the unicast burst stream is just a copy of the multicast stream, there is no additional cost for the data itself (as content) if both streams are obtained. Therefore, it is feasible both technically and economically (maybe at some added cost) for the user to simultaneously receive the unicast burst stream and the multicast stream. In particular, as the acquisition process involving receiving both streams is short, in the magnitude of a few seconds, it is likely that network providers, which in many cases are also content providers and services providers, are willing to allow the momentary use of higher bandwidth than usual, either freely to users (i.e. users still pay for the usual bandwidth) or under a new contract that explicitly covers such momentary uses of higher bandwidth. Their reasoning will be to supply better user experience when they compete with other delivery technologies. o In a digital home with multiple TVs and possibly other connected equipments such as PCs, more than one TV program on different TVs may be watched simultaneously in addition to other network uses under one network accessing contact. In such a common scenario, the bandwidth available can easily be as at least twice high as the media rate. Note that there will still be cases wherein available bandwidth is not enough for transmission of both the unicast burst stream and the multicast stream simultaneously. Therefore, it should still be allowed for receivers to switch between the proposed improved method, the original RAMS method, and the conventional method (i.e. directly joining the multicast group). 2. Conventions 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]. Wang, Dai & Feng Expires January 6, 2010 [Page 5] Internet-Draft Improved RAMS July 2009 3. Improved Rapid Acquisition of Multicast RTP Sessions The improved RAMS method is described by the following steps (referring to Figure 1, based on the same terminology in [I-D.ietf- avt-rapid-acquisition-for-rtp]): 1) Request: RR sends an RAMS-R message to the RS to request for the unicast burst session of the new multicast RTP session, and an SFGMP (i.e. IGMP or MLD) Join message to the Router to join the new multicast session. Preferably, the RAMS-R and SFGMP Join messages are sent simultaneously. However, the RAMS-R and SFGMP Join messages can also be sent at different temporal locations but should be reasonably close to each other, and there is no restriction to the temporal order of sending the two messages. 2) Response: RS receives the RAMS-R message and decides whether to accept it or not. RS sends one or more RAMS-Information (RAMS-I) messages to the receiver. If the request is accepted by RS, it starts sending the unicast burst stream. The unicast burst can be sent to receiver either after or together with RAMS-I message. At the same time or at a slightly different time, the multicast stream starts to flow to RR from the Multicast Source. 3) Updated Request or Updated Response: RR MAY send updated RAMS-R messages to RS. RS MAY send updated RAMS-I messages to RR. Wang, Dai & Feng Expires January 6, 2010 [Page 6] Internet-Draft Improved RAMS July 2009 +-----------+ +----------------+ +----------+ +------------+ | Multicast | | Retransmission | | | | RTP | | Source | | Server | | Router | | Receiver | | | | (RS) | | | | (RR) | +-----------+ +----------------+ +----------+ +------------+ | | | | |-- RTP Multicast ------------------->| | |-- RTP Multicast ->| | | | | |<~ SFGMP Join ~~| | |<'''''''''''''''''' RTCP RAMS-R ''| | | | | | |'' (RTCP RAMS-I) ''''''''''''''''>| | | | | | |.. Unicast RTP Burst ............>| |-- RTP Multicast ------------------------------------>| | | | | | |<''''''''''''''''''(RTCP RAMS-R)''| | | | | | |'' (RTCP RAMS-I) ''''''''''''''''>| | | | | | |<'''''''''''''''''' RTCP RAMS-T ''| | | | | | |<''''''''''''''''''' (RTCP NACK)''| | | | | | |.. (Unicast Retransmissions) ....>| | | | | | |<''''''''''''''''''' (RTCP BYE) ''| | | | | '''> Unicast RTCP Messages ~~~> SFGMP Messages ...> Unicast RTP Flow ---> Multicast RTP Flow Figure 1 Flow of the improved RAMS method Wang, Dai & Feng Expires January 6, 2010 [Page 7] Internet-Draft Improved RAMS July 2009 4) Process: For the received unicast stream and the received multicast stream, the one that can be processed first is chosen. A stream can only be processed from a correctly received random access point. If both the received unicast stream and the received multicast stream contain correctly received random access points, then either can be chosen. If the multicast stream is chosen, then the unicast stream is terminated immediately. In this case, all received packets of the multicast stream are processed (depacketized and decoded). Otherwise (i.e. the unicast stream is chosen), the unicast stream is terminated when it catches the beginning of the received multicast stream, i.e. after the packet in the unicast stream having OSN equal to SNm-1 is received, where OSN stands for Original Sequence Number as defined in [I-D.ietf-avt-rapid- acquisition-for-rtp], SNm is the Sequence Number (SN) of the first packet in the received multicast stream. In this case, all received packets of the unicast stream having OSN equal to or greater than SNm are discarded, and other received packets of the unicast stream and all received packets of the multicast stream are processed. 5) Terminate: In the above step, the unicast stream is terminated by sending an RAMS-T message to RS. To terminate the unicast stream immediately, RR sends an RAMS-T message without an RTP sequence number. To instruct RS to terminate the unicast stream after catching the multicast stream, RR SHALL include in the RAMS-T message the sequence number of the first received RTP packet in the received multicast stream. When RR is receiving the unicast stream, and if RR becomes no longer interested in the multicast stream, RR sends an RTCP BYE message to RS to terminate the RTP retransmission session (which contains both the unicast burst stream as well as the retransmission stream for lost packets). 4. Security Considerations TBD. 5. IANA Considerations TBD. 6. Acknowledgements TBD. Wang, Dai & Feng Expires January 6, 2010 [Page 8] Internet-Draft Improved RAMS July 2009 This document was prepared using 2-Word-v2.0.template.dot. 7. References [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-01 (work in progress), June 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8. Authors' Addresses Ye-Kui Wang Huawei Technologies Co., Ltd. 400 Somerset Corp Blvd, Suite 602 Bridgewater, NJ 08807 USA Phone: +1-908-541-3518 EMail: yekuiwang@huawei.com Jinliang Dai Huawei Technologies Co., Ltd. BuildingNO.17, Zpark Hai-Dian District, Beijing P. R. China Phone: +86-10-82829100 EMail: daijinliang@huawei.com Jiangping Feng Huawei Technologies Co., Ltd. BuildingNO.17, Zpark Hai-Dian District, Beijing P. R. China Phone: +86-10-82829092 EMail: fengjiangping@huawei.com Wang, Dai & Feng Expires January 6, 2010 [Page 9]