One document matched: draft-johansson-avt-mcast-based-rams-00.txt
Network Working Group I. Johansson
Internet-Draft Ericsson AB
Intended status: Standards Track Apr 8, 2009
Expires: October 10, 2009
Multicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-johansson-avt-mcast-based-rams-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 October 10, 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 proposes an improvement to the unicast based Rapid
Acquisition for Multicast based Streaming discussed in [ID-Versteeg].
The outline of the improvement is to gather up Rapid Acquisition
Johansson Expires October 10, 2009 [Page 1]
Internet-Draft Multicast-Based RAMS Apr 2009
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-Versteeg].
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Informative References . . . . . . . . . . . . . . . . . . 6
6.2. Normative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Johansson Expires October 10, 2009 [Page 2]
Internet-Draft Multicast-Based RAMS Apr 2009
1. Introduction
Draft [ID-Versteeg] 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. Draft
[ID-Peilin] proposes an extension to this draft that essentially adds
elements to make it possible to adjust the transmission rate of the
unicast stream.
The methods should considerably reduce the channel switch latency as
experienced by the end user.
There are a number of potential issues with the aforementioned
methods.
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
needs to be vastly 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 methods described earlier. 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
contains information about rapid acquisition multicast feeds that are
active.
2. Description
The proposed solution can serve as a complement to the solutions
outlined in [ID-Versteeg] and [ID-Peilin]. During low load
conditions the retransmission server (RS) will serve each RAMS-R
request with an individual unicast RTP burst. 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
Johansson Expires October 10, 2009 [Page 3]
Internet-Draft Multicast-Based RAMS Apr 2009
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.
The figure below displays how this would work, the figures is
somewhat simplified, for instance IGMP Leave is left out.
RR-1 RR-2 RS
| | |
|--RAMS-R, ch X-------------------------------------->| -
|<-RAMS-I m-cast 225.0.1.1----------------------------| |
|--IGMP Join 225.0.1.1------------------------------->| |
| |--RAMS-R, ch X ---------->| |
| |<-RAMS-I m-cast 225.0.1.1-| Td
| |--IGMP Join 225.0.1.1---->| |
| | | |
| | | |
|<-------------------------|<-Stream buf on 225.0.1.1-| -
| | |
| |-IGMP Join m-cast ch X--------->
|---------------------------------IGMP Join m-cast ch X---->
RR-1 transmits a RAMS-R to RS, requesting rapid acquisition data for
channel X, as RR-1 is the first to request this data, a timer is
started in order to wait for a given timespan (Td) for other RAMS-R
for the same channel from other RR's. RS sends a RAMS-I to RR-1 with
instructions to listen in on 225.0.1.1 and thus RS-1 makes an IGMP
Join to said multicast address.
Later RR-2 sends a RAMS-R to RS, requesting rapid acquisition data
for channel X. RS sends a RAMS-I to RR-2 with instructions to listen
in on 225.0.1.1 and RS-2 also makes an IGMP Join to the said
multicast address
When the timer is expired, RS will stream the requested data on
multicast channel 225.0.1.1 the data speed in the multicast channel
can be either normal speed or a speed that is higher than normal (e.g
120%).
When sufficient data has been received via the multicast channel,
both RR-1 and RR-2 makes an IGMP Join to multicast channel X.
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 STB has sent a request, this case is similar to the
Johansson Expires October 10, 2009 [Page 4]
Internet-Draft Multicast-Based RAMS Apr 2009
unicast streaming case.
At severe load conditions the RAMS-R requests will be either ignored
or responded with a negative acknowledgement, in which case the RR's
will not receive any rapid acquisition data.
Besides the methodology described above, another possibility is also
that an STB 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.
There are a few different ways to determine when a switch from the
rapid acquisition channel to the normal multicast channel:
1. A marker in the rapid acquisition media stream tells the STB to
make a switch
2. A multicast control channel tells the STB that it is time to
switch or can give the STB sufficient information necessary to
make the switch
3. End of rapid acquisition media stream, indicated by an explicit
End-Of-Stream symbol
4. Count of frames, the STB can itself decide to switch after
receiving e.g 3 I-frames
In certain cases it is preferable (for instance limited downlink
bandwidth) that the rapid acquisition stream to a particular STB is
terminated (e.g by means of IGMP 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.
3. IANA Considerations
T.B.D
4. Security Considerations
T.B.D
Johansson Expires October 10, 2009 [Page 5]
Internet-Draft Multicast-Based RAMS Apr 2009
5. Acknowledgements
The author wish to thank Mats Cedervall and Victor Souza for help
with this draft.
6. References
6.1. Informative References
[ID-Peilin]
IETF, "Extensions to RTCP for Rapid Synchronization, http:
//tools.ietf.org/id/draft-peilin-avt-rtp-burst-01.txt".
[ID-Versteeg]
IETF, "Unicast-Based Rapid Acquisition of Multicast RTP
Sessions, http://tools.ietf.org/id/
draft-versteeg-avt-rapid-synchronization-for-rtp-02.txt".
6.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
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 October 10, 2009 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 08:28:20 |