AVT A. Begen
Internet-Draft Cisco Systems
Intended status: Informational October 1, 2009
Expires: April 4, 2010
Considerations for RAMS Scenarios
draft-begen-avt-rams-scenarios-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 April 4, 2010.
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
The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a
method based on RTP and RTCP protocol family that enables an RTP
receiver to rapidly acquire and start usefully consuming the RTP
Begen Expires April 4, 2010 [Page 1]
Internet-Draft Considerations for RAMS Scenarios October 2009
multicast data. Upon a request from the RTP receiver, an auxiliary
unicast RTP retransmission session is set up between a retransmission
server and the RTP receiver, over which the reference information
about the new multicast stream the RTP receiver is about to join is
transmitted at an accelerated pace. This often precedes, but may
also accompany, the multicast stream itself. When there is only one
multicast stream to be acquired, the RAMS solution works in a
straightforward manner. However, when there are two or more
multicast streams to be acquired from the same or different multicast
RTP sessions, care should be taken to configure each RAMS
appropriately. This document provides example scenarios and make
practical recommendations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Illustrative Scenarios . . . . . . . . . . . . . . . . . . . . 4
4.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Scenario #4 . . . . . . . . . . . . . . . . . . . . . . . 6
5. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 6
6. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7
6.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Begen Expires April 4, 2010 [Page 2]
Internet-Draft Considerations for RAMS Scenarios October 2009
1. Introduction
The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a
method based on RTP and RTCP protocol family that enables an RTP
receiver to rapidly acquire and start usefully consuming the RTP
multicast data. Through an auxiliary unicast RTP retransmission
session [RFC4588], the RTP receiver receives a reference information
about the new multicast stream it is about to join. This often
precedes, but may also accompany, the multicast stream itself. The
RAMS solution is documented in detail in
[I-D.ietf-avt-rapid-acquisition-for-rtp].
To focus on the protocol details, the RAMS specification
[I-D.ietf-avt-rapid-acquisition-for-rtp] has only considered the
simplest case, which is that the RTP receiver acquires only one
multicast stream at a time. However, there are many applications
where a multicast RTP session may have two or more multicast streams
associated with it. There are also cases, where an RTP receiver may
be interested in acquiring one or more multicast streams from
multiple multicast RTP sessions. In scenarios where multiple RAMS
sessions will be simultaneously run by the RTP receiver, care should
be taken to coordinate them. In this document, we provide scenarios
from real-life deployments and make recommendations.
2. Requirements Notation
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 [RFC2119].
3. Background
In the following, we assume that there are two RTP streams (1 and 2)
that are somehow associated with each other. These could be audio
and video elementary streams for the same TV channel, or they could
be an MPEG2-TS stream and its Forward Error Correction (FEC) stream.
It is important to note that a source-specific multicast (SSM)
session is defined by its (distribution) source address and
(destination) multicast group and there can be only one feedback
target per SSM session [I-D.ietf-avt-rtcpssm]. So, if the RTP
streams are distributed by different sources or over different
multicast groups, they have to be in different SSM sessions.
Different SSM sessions may share the same feedback target address
and/or port.
Begen Expires April 4, 2010 [Page 3]
Internet-Draft Considerations for RAMS Scenarios October 2009
Different multicast RTP streams can be transmitted in the same RTP
session (i.e., in a single UDP flow). This is called SSRC
multiplexing. In this case, (de)multiplexing is done at the SSRC
level. Alternatively, different multicast RTP streams can be
transmitted in different RTP sessions (i.e., in different UDP flows),
which is called session multiplexing. In practice, there are
different deployment models for each multiplexing scheme.
It is also important to note that two different media streams with
different clock rates should use different SSRCs or RTP sessions to
avoid complications in RTCP reports. Some of the fields in RAMS
messages depend on the clock rate. Thus, in a single RTP session,
RTP streams carrying payloads with different clock rates should have
different SSRCs. Since RTP streams in the same RTP session but with
different SSRCs do not share the sequence numbering, each stream
needs to be acquired individually.
In the following, only the relevant portions of the SDP descriptions
[RFC4566] will be provided.
4. Illustrative Scenarios
4.1. Scenario #1
This is the scenario for session multiplexing where RTP streams 1 and
2 are transmitted over different multicast groups. A practical use
case is where the first and second SSM session carries the primary
video stream and its associated FEC stream, respectively.
We run an individual RAMS session for each RTP stream that we want to
rapidly acquire. These RAMS sessions MAY run in parallel. If they
are, the RTP receiver needs to pay attention to using the shared
bandwidth appropriately among different RAMS sessions. Note that
there may be different feedback targets for these two SSM sessions.
If that is the case, RTP streams 1 and 2 may have the same SSRC
value. However, if both SSM sessions use the same transport address
(IP address and port) for their feedback targets (as shown in the SDP
below), the SSRCs of the RTP streams 1 and 2 MUST be different from
each other to avoid any ambiguity in the RAMS requests.
Begen Expires April 4, 2010 [Page 4]
Internet-Draft Considerations for RAMS Scenarios October 2009
a=group:FEC-XR RTP1 RTP2
m=video 40000 RTP/AVP 96
c=IN IP4 233.252.0.1/127
a=rtcp:41001 IN IP4 192.0.2.1
a=ssrc:1 cname:rtp1@example.com
a=mid:RTP1
m=application 40000 RTP/AVP 97
c=IN IP4 233.252.0.2/127
a=rtcp:41001 IN IP4 192.0.2.1
a=ssrc:2 cname:rtp2@example.com
a=mid:RTP2
Note that the destination ports in the above SDP do not matter, and
they could be the same or different.
4.2. Scenario #2
This is the scenario for session multiplexing where RTP streams 1 and
2 are transmitted over the same multicast group with different
destination ports. A practical use case is where the SSM session
carries the primary video and audio streams, each destined to a
different port.
Similar to scenario #1, we run individual RAMS sessions for each RTP
stream that we want to rapidly acquire. Compared to the previous
scenario, the only difference is that in this case the join times for
both streams need to be coordinated as they are on the same multicast
session.
m=video 40000 RTP/AVP 96
c=IN IP4 233.252.0.1/127
a=rtcp:41001 IN IP4 192.0.2.1
a=ssrc:1 cname:rtp1@example.com
a=mid:RTP1
m=audio 40001 RTP/AVP 97
c=IN IP4 233.252.0.1/127
a=rtcp:41001 IN IP4 192.0.2.1
a=ssrc:2 cname:rtp2@example.com
a=mid:RTP2
Note that the destination ports in the above SDP MUST be distinct per
[I-D.ietf-mmusic-rfc3388bis].
If RTP streams 1 and 2 share the same distribution source, then there
is only one SSM session, which means that there can be only one
feedback target. This requires RTP streams 1 and 2 to have their own
unique SSRC values (as shown in the SDP above). If RTP streams 1 and
2 do not share the same distribution source, meaning that their
Begen Expires April 4, 2010 [Page 5]
Internet-Draft Considerations for RAMS Scenarios October 2009
respective SSM sessions may use different feedback target transport
addresses, then their SSRC values do not have to be different from
each other.
4.3. Scenario #3
This is the scenario for SSRC multiplexing where both RTP streams are
transmitted over the same multicast group to the same destination
port. This is a less practical scenario but it could be used where
the SSM session carries the primary video and audio streams, destined
to the same port.
Similar to scenario #2, we run individual RAMS sessions and the join
time needs to be coordinated. In this case, there is only one
distribution source and the destination multicast address is shared.
Thus, there is only one SSM session and one feedback target.
m=video 40000 RTP/AVP 96 97
c=IN IP4 233.252.0.1/127
a=rtcp:41001 IN IP4 192.0.2.1
a=ssrc:1 cname:rtp1@example.com
a=ssrc:2 cname:rtp2@example.com
a=mid:Channel1
4.4. Scenario #4
This is the scenario for payload-type multiplexing.
In this case, instead of two, we have only one RTP stream (and one
RTP session) carrying both payload types (e.g., media payload and its
FEC data). While this scheme is permissible per [RFC3550], it has
several drawbacks. For example, RTP packets carrying different
payload formats will share the same sequence numbering space, and the
retransmission and RAMS operations will not be able to be applied
based on the payload type. For other drawbacks and details, see
Section 5.2 of [RFC3550].
5. Feedback Target and SSRC Signaling Issues
The RAMS protocol uses the common packet format from [RFC4585], which
has a field to signal the media source SSRC. Thus, currently we
require the RAMS Request messages to have this field properly filled.
The SSRCs for the RTP streams can be signaled out-of-band in the SDP,
or could be learned from the RTP packets once the transmission
starts. In our scenario, the latter cannot be used.
Signaling the media source SSRC value will help the feedback target
Begen Expires April 4, 2010 [Page 6]
Internet-Draft Considerations for RAMS Scenarios October 2009
correctly identify the RTP stream to be acquired. If a feedback
target is serving multiple SSM sessions on a particular port, all the
RTP streams in these SSM sessions MUST have a unique SSRC value.
Otherwise, the feedback target cannot discern the incoming RTCP
feedback messages.
If there are no provisions to assign unique SSRC values to the RTP
streams in a deployment, the feedback target transport addresses MUST
be assigned appropriately. Unique feedback target addresses can be
used without any issues if the deployment only covers scenario #1.
Using unique feedback target transport addresses may or may not be
sufficient in scenario #2. In scenario #3, there is one feedback
target. Thus, SSRCs must be unique among the RTP streams that a
particular feedback target (IP address and port) is responsible for.
6. FEC during RAMS and Bandwidth Issues
Suppose that RTP stream 1 denotes the primary video stream that has a
bitrate of 10 Mbps and RTP stream 2 denotes the FEC stream that has a
bitrate of 1 Mbps. Also assume that the RTP receiver knows that it
can receive data at a maximum bitrate of 22 Mbps. SDP can specify
the bitrate ("b=" line in Kbps) of each media session (per "m="
line).
6.1. Scenario #1
This is the scenario for session multiplexing where RTP streams 1 and
2 are transmitted over different multicast groups.
This is the preferred deployment model for FEC. Having FEC in a
different multicast group provides flexibility for both RTP receivers
that are not FEC capable or the ones that are not willing to receive
FEC during the RAMS session.
Begen Expires April 4, 2010 [Page 7]
Internet-Draft Considerations for RAMS Scenarios October 2009
a=group:FEC-XR RTP1 RTP2
m=video 40000 RTP/AVP 96
c=IN IP4 233.252.0.1/127
a=rtpmap:96 MP2T/90000
b=TIAS:10000
a=mid:RTP1
m=application 40000 RTP/AVP 97
c=IN IP4 233.252.0.2/127
a=rtpmap:97 1d-interleaved-parityfec/90000
b=TIAS:1000
a=mid:RTP2
If the RTP receiver does not want to receive FEC until the
acquisition of the primary video stream is completed, the total
available bandwidth can be used for faster acquisition of the primary
video stream. In this case, the RTP receiver may request a Max
Receive Bitrate of 22 Mbps in the RAMS Request message. Once RAMS
has been completed, the RTP receiver MAY join the FEC multicast
session, if desired.
If the RTP receiver wants to rapidly acquire both primary and FEC
streams, it needs to allocate the total bandwidth among the two RAMS
sessions and indicate individual Max Receive Bitrate values in each
respective RAMS Request message. Since less bandwidth will be used
to acquire the primary video stream, the acquisition of the primary
video session will take a longer time on the average.
While the RTP receiver can update the Max Receive Bitrate values
during the course of the RAMS session, this approach is more error-
prone due to the possibility of losing the update messages.
6.2. Scenario #2
This is the scenario for session multiplexing where RTP streams 1 and
2 are transmitted over the same multicast group with different
destination ports.
a=group:FEC-XR RTP1 RTP2
m=video 40000 RTP/AVP 96
c=IN IP4 233.252.0.1/127
a=rtpmap:96 MP2T/90000
b=TIAS:10000
a=mid:RTP1
m=application 40001 RTP/AVP 97
c=IN IP4 233.252.0.1/127
a=rtpmap:97 1d-interleaved-parityfec/90000
b=TIAS:1000
a=mid:RTP2
Begen Expires April 4, 2010 [Page 8]
Internet-Draft Considerations for RAMS Scenarios October 2009
Similar to scenario #1, the RTP receiver can first ask for RAMS for
the primary video stream at the full receive bitrate. But, upon the
multicast join, the available bandwidth for the burst drops to 11
Mbps instead of 12 Mbps. Regardless of whether FEC is desired or not
by the RTP receiver, its bitrate needs to be taken into account once
the RTP receiver joins the multicast.
If the RTP receiver wants to rapidly acquire both primary and FEC
streams, the same conditions explained for scenario #1 apply. The
only difference from scenario #1 is that here the join time is the
same for both the primary video and FEC streams.
6.3. Scenario #3
This is the scenario for SSRC multiplexing where both RTP streams are
transmitted over the same multicast group to the same destination
port.
m=video 40000 RTP/AVP 96 97
c=IN IP4 233.252.0.1/127
a=rtpmap:96 MP2T/90000
a=rtpmap:97 1d-interleaved-parityfec/90000
b=TIAS:11000
a=mid:Channel1
This is similar to scenario #2. However, since we cannot explicitly
specify the bitrates for the primary and FEC streams, the RTP
receiver may request to rapidly acquire both streams in parallel. In
this case, two separate RAMS Request messages have to be sent by the
RTP receiver to the feedback target.
Note that based on the "a=fmtp" line for the FEC stream, it may be
possible to infer the bitrate of this FEC stream and set the Max
Receive Bitrate value accordingly.
7. Security Considerations
TBD.
8. IANA Considerations
There are no IANA considerations in this document.
9. References
Begen Expires April 4, 2010 [Page 9]
Internet-Draft Considerations for RAMS Scenarios October 2009
9.1. Normative 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-03 (work in
progress), September 2009.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[I-D.ietf-avt-rtcpssm]
Schooler, E., Ott, J., and J. Chesterfield, "RTCP
Extensions for Single-Source Multicast Sessions with
Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in
progress), March 2009.
9.2. Informative References
[I-D.ietf-mmusic-rfc3388bis]
Camarillo, G., "The SDP (Session Description Protocol)
Grouping Framework", draft-ietf-mmusic-rfc3388bis-03 (work
in progress), July 2009.
Begen Expires April 4, 2010 [Page 10]
Internet-Draft Considerations for RAMS Scenarios October 2009
Author's Address
Ali Begen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: abegen@cisco.com
Begen Expires April 4, 2010 [Page 11]