One document matched: draft-johansson-avt-mcast-based-rams-02.txt
Differences from draft-johansson-avt-mcast-based-rams-01.txt
Network Working Group I. Johansson
Internet-Draft Ericsson AB
Intended status: Standards Track March 8, 2010
Expires: September 9, 2010
Extended Rapid Acquisition of Multicast RTP Sessions (ERAMS)
draft-johansson-avt-mcast-based-rams-02
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 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.
Johansson Expires September 9, 2010 [Page 1]
Internet-Draft Extended RAMS March 2010
This Internet-Draft will expire on September 9, 2010.
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
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 BSD License.
Johansson Expires September 9, 2010 [Page 2]
Internet-Draft Extended RAMS March 2010
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Message . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. RAMS-R Message . . . . . . . . . . . . . . . . . . . . 8
3.2.2. RAMS-I Message . . . . . . . . . . . . . . . . . . . . 8
3.3. Considerations . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Different max Bitrates . . . . . . . . . . . . . . . . 9
3.3.2. Reaction to Packet Loss . . . . . . . . . . . . . . . 10
3.3.3. RTP/RTCP Port Multiplexing . . . . . . . . . . . . . . 10
3.4. Alternative Solutions . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
4.1. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 10
4.2. RAMS Response Code Space Registry . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Johansson Expires September 9, 2010 [Page 3]
Internet-Draft Extended RAMS March 2010
1. Definitions
This document uses the following acronyms and definitions frequently:
RR: Retransmission 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 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
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 September 9, 2010 [Page 4]
Internet-Draft Extended RAMS March 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 solutions
outlined in [ID-RAMS]. During low load conditions the retransmission
server (RS) will serve each RAMS-R request from an RR 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.
+--------+ +---------+ +--------+ +----------+ +----------+
| M.cast | | Re-TX | | | | RTP | | RTP |
| Source | | Server | | Router | | Receiver | | Receiver |
| | | (RS) | | | | (RR-1) | | (RR-2) |
+--------+ +---------+ +--------+ +----------+ +----------+
| | | | |
|- RTP M.cast------------------->| | |
| | | | |
|- RTP M.cast >| | | |
| | | | |
| |<''''''''' RTCP RAMS-R: Chl: A '| |-----
Johansson Expires September 9, 2010 [Page 5]
Internet-Draft Extended RAMS March 2010
| | | | |
| |'(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..........>|
| | | | |
| |<''''''''''''''''(RTCP RAMS-R)''| |
| |<''''''''''''''''(RTCP RAMS-R)''''''''''' '|
| | | | |
| |'' (RTCP RAMS-I) ''''''''''''''>| |
| |'' (RTCP RAMS-I) '''''''''''''''''''''''''>|
| | | | |
| | |<~ 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) '''''''''''''|
| | | | |
RR-1 transmits a RAMS-R to RS, requesting rapid acquisition data for
channel A, as RR-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 RR's. RS sends a RAMS-I to RR-1 with
instructions to listen in on a specified multicast address (X) and
thus RS-1 makes an SFGMP Join to said multicast address.
Johansson Expires September 9, 2010 [Page 6]
Internet-Draft Extended RAMS March 2010
The response code in RAMS-I when ERAMS is used is a 3xx response code
[Number TBD].
Later RR-2 sends a RAMS-R to RS, requesting rapid acquisition data
for channel A. RS sends a RAMS-I to RR-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 RR-1 and RR-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 RR 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 RR'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 RR that it is time to
switch or can give the RR sufficient information necessary to
make the switch
2. The RS informs the RR about the synchronization point in a RAMS-I
message.
3. A marker in the rapid acquisition media stream tells the RR to
make a switch
4. Count of frames, the RR can itself decide to switch after
receiving e.g 3 I-frames. In this case the RR must know the 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 it is preferable (for instance limited downlink
bandwidth) that the rapid acquisition stream to a particular RR 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
Johansson Expires September 9, 2010 [Page 7]
Internet-Draft Extended RAMS March 2010
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 RR supports
Extended RAMS and prefers to use the mechanism. The field contains a
few flags that can be combined. [ Ed. note it is not certain that
these flags are really needed, it may be sufficient to signal this in
the session setup instead].
3.2.2. RAMS-I Message
The Extended RAMS solution implements a new TLV field to the RAMS-I
message
Johansson Expires September 9, 2010 [Page 8]
Internet-Draft Extended RAMS March 2010
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 RR 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 RR 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
bitrates.
Johansson Expires September 9, 2010 [Page 9]
Internet-Draft Extended RAMS March 2010
3.3.2. Reaction to Packet Loss
Packet losses may occur in the ERAMS transmission. In normal cases
an RR 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 RR 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 RR 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.
4.1. RAMS TLV Space Registry
This document adds two TLV's to the TLV's already defined in
[ID-RAMS].
Johansson Expires September 9, 2010 [Page 10]
Internet-Draft Extended RAMS March 2010
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, http://tools.ietf.org/html/
draft-ietf-avt-rapid-acquisition-for-rtp-07".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Johansson Expires September 9, 2010 [Page 11]
Internet-Draft Extended RAMS March 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 September 9, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 09:51:43 |