One document matched: draft-wang-avt-rtp-improved-rams-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 08:44:02 |