[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-begen-avtext-rams-scenarios) 00 01 02 03 04 05 RFC 6659

AVTEXT                                                          A. Begen
Internet-Draft                                                     Cisco
Intended status:  Informational                            June 10, 2011
Expires:  December 12, 2011


  Considerations and Guidelines for Deploying the Rapid Acquisition of
                  Multicast RTP Sessions (RAMS) Method
                  draft-ietf-avtext-rams-scenarios-00

Abstract

   The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a
   method based on RTP and RTP Control Protocol (RTCP) that enables an
   RTP receiver to rapidly acquire and start consuming the RTP 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 rate.  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 session appropriately.  This document
   provides example scenarios and offers guidelines.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on December 12, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Begen                   Expires December 12, 2011               [Page 1]

Internet-Draft               Deploying RAMS                    June 2011


   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 Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   3.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Example Scenarios  . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Scenario #1: Two Multicast Groups  . . . . . . . . . . . .  4
     4.2.  Scenario #2: One Multicast Group . . . . . . . . . . . . .  5
     4.3.  Scenario #3: SSRC Multiplexing . . . . . . . . . . . . . .  6
     4.4.  Scenario #4: Payload-Type Multiplexing . . . . . . . . . .  7
   5.  Feedback Target and SSRC Signaling Issues  . . . . . . . . . .  7
   6.  FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . .  7
     6.1.  Scenario #1  . . . . . . . . . . . . . . . . . . . . . . .  8
     6.2.  Scenario #2  . . . . . . . . . . . . . . . . . . . . . . .  9
     6.3.  Scenario #3  . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11


















Begen                   Expires December 12, 2011               [Page 2]

Internet-Draft               Deploying RAMS                    June 2011


1.  Introduction

   The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a
   method based on RTP and RTP Control Protocol (RTCP) that enables an
   RTP receiver to rapidly acquire and start 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].

   The RAMS specification [I-D.ietf-avt-rapid-acquisition-for-rtp] has
   provisions for concurrently acquiring multiple streams inside a
   multicast RTP session.  However, the specification has mostly focused
   on the simplest case, which is when the RTP receiver acquires only
   one multicast stream at a time, to explain the protocol details.

   There are certain deployment models 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 several multicast RTP sessions.  In
   scenarios where multiple RAMS sessions will be simultaneously run by
   an RTP receiver, they need to be coordinated.  In this document, we
   present scenarios from real-life deployments and provide guidelines.


2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   Editor's note:  I am inclined not use any 2119 keyword in this
   document and remove this section altogether.


3.  Background

   In the following discussion, 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 (that has audio and video
   multiplexed together) 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



Begen                   Expires December 12, 2011               [Page 3]

Internet-Draft               Deploying RAMS                    June 2011


   (destination) multicast group and there can be only one feedback
   target per SSM session [RFC5760].  So, if the RTP streams are
   distributed by different sources or over different multicast groups,
   they are considered different SSM sessions.  While different SSM
   sessions can normally share the same feedback target address and/or
   port, RAMS requires each unique feedback target (i.e., the
   combination of address and port) to be associated with at most one
   RTP session (See Section 6.2 of
   [I-D.ietf-avt-rapid-acquisition-for-rtp]).

   Two or more multicast RTP streams can be transmitted in the same RTP
   session (i.e., in a single UDP flow).  This is called Synchronization
   Source (SSRC) multiplexing.  In this case, (de)multiplexing is done
   at the SSRC level.  Alternatively, the 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.

   Generally, two different media streams with different clock rates are
   suggested to use different SSRCs or to be carried in different RTP
   sessions to avoid complications in RTCP reports.  Some of the fields
   in RAMS messages might depend on the clock rate.  Thus, in a single
   RTP session, RTP streams carrying payloads with different clock rates
   need to 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 remaining sections, only the relevant portions of the SDP
   descriptions [RFC4566] will be provided.  For an example of a full
   SDP description, refer to Section 8.3 of
   [I-D.ietf-avt-rapid-acquisition-for-rtp].


4.  Example Scenarios

4.1.  Scenario #1: Two Multicast Groups

   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 sessions carry the primary
   video stream and its associated FEC stream, respectively.

   We run an individual RAMS session for each of these RTP streams that
   we want to rapidly acquire.  These RAMS sessions can be run in
   parallel.  If they are, the RTP receiver needs to pay attention to
   using the shared bandwidth appropriately among the two unicast
   bursts.  As explained earlier, there has to be a different feedback
   target for these two SSM sessions.



Begen                   Expires December 12, 2011               [Page 4]

Internet-Draft               Deploying RAMS                    June 2011


        a=group:FEC-FR Channel1_Video Channel1_FEC
        m=video 40000 RTP/AVPF 96
        c=IN IP4 233.252.0.1/127
        a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
        a=rtcp:41000 IN IP4 192.0.2.1
        a=ssrc:1 cname:ch1_video@example.com
        a=mid:Channel1_Video
        m=application 40000 RTP/AVPF 97
        c=IN IP4 233.252.0.2/127
        a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
        a=rtcp:42000 IN IP4 192.0.2.1
        a=ssrc:2 cname:ch1_fec@example.com
        a=mid:Channel1_FEC

   Note that the multicast destination ports in the above SDP do not
   matter, and they could be the same or different.  The "FEC-FR"
   grouping semantics are defined in [RFC5956].

4.2.  Scenario #2: One Multicast Group

   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 (Note that the RAMS request
   sent by an RTP receiver could indicate the desire to acquire all or a
   subset or one of the available RTP streams in an SSM session).
   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.


















Begen                   Expires December 12, 2011               [Page 5]

Internet-Draft               Deploying RAMS                    June 2011


        m=video 40000 RTP/AVPF 96
        c=IN IP4 233.252.0.1/127
        a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
        a=rtcp:41000 IN IP4 192.0.2.1
        a=ssrc:1 cname:ch1_video@example.com
        a=mid:Channel1_Video
        m=audio 40001 RTP/AVPF 97
        c=IN IP4 233.252.0.1/127
        a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
        a=rtcp:41000 IN IP4 192.0.2.1
        a=ssrc:2 cname:ch1_audio@example.com
        a=mid:Channel1_Audio

   Note that the destination ports in the above SDP need to be distinct
   per [RFC5888].

   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 (as shown in the SDP description above).  This
   requires RTP streams 1 and 2 to have their own unique SSRC values
   (also as shown in the SDP description above).  If RTP streams 1 and 2
   do not share the same distribution source, meaning that their
   respective SSM sessions can use different feedback target transport
   addresses, then their SSRC values do not have to be different from
   each other.

4.3.  Scenario #3: SSRC Multiplexing

   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 both the primary video and audio stream,
   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 always one SSM session and one feedback target.













Begen                   Expires December 12, 2011               [Page 6]

Internet-Draft               Deploying RAMS                    June 2011


        m=video 40000 RTP/AVPF 96 97
        c=IN IP4 233.252.0.1/127
        a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
        a=rtcp:41000 IN IP4 192.0.2.1
        a=ssrc:1 cname:ch1_video@example.com
        a=ssrc:2 cname:ch1_audio@example.com
        a=mid:Channel1

4.4.  Scenario #4: Payload-Type Multiplexing

   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 sender SSRC.  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 RAMS, the
   latter cannot be used.

   Signaling the media sender SSRC value helps the feedback target
   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 are supposed to have a unique SSRC
   value.  However, since this is not an easy requirement to satisfy,
   RAMS specification forbids to have more than one RTP session to be
   associated with a specific feedback target.


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).





Begen                   Expires December 12, 2011               [Page 7]

Internet-Draft               Deploying RAMS                    June 2011


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 not only the RTP
   receivers that are not FEC capable but also the ones that are FEC
   capable but are not willing to receive FEC during the rapid
   acquisition.


        a=group:FEC-FR Channel1_Video Channel1_FEC
        m=video 40000 RTP/AVPF 96
        c=IN IP4 233.252.0.1/127
        a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
        a=rtcp:41000 IN IP4 192.0.2.1
        a=rtpmap:96 MP2T/90000
        b=TIAS:10000
        a=ssrc:1 cname:ch1_video@example.com
        a=mid:Channel1_Video
        m=application 40000 RTP/AVPF 97
        c=IN IP4 233.252.0.2/127
        a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
        a=rtcp:42000 IN IP4 192.0.2.1
        a=rtpmap:97 1d-interleaved-parityfec/90000
        b=TIAS:1000
        a=ssrc:2 cname:ch1_fec@example.com
        a=mid:Channel1_FEC

   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 can request a Max
   Receive Bitrate of 22 Mbps in the RAMS Request message.  Once RAMS
   has been completed, the RTP receiver can 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.



Begen                   Expires December 12, 2011               [Page 8]

Internet-Draft               Deploying RAMS                    June 2011


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-FR Channel1_Video Channel1_FEC
        m=video 40000 RTP/AVPF 96
        c=IN IP4 233.252.0.1/127
        a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
        a=rtcp:41000 IN IP4 192.0.2.1
        a=rtpmap:96 MP2T/90000
        b=TIAS:10000
        a=ssrc:1 cname:ch1_video@example.com
        a=mid:Channel1_Video
        m=application 40001 RTP/AVPF 97
        c=IN IP4 233.252.0.1/127
        a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
        a=rtcp:41000 IN IP4 192.0.2.1
        a=rtpmap:97 1d-interleaved-parityfec/90000
        b=TIAS:1000
        a=ssrc:2 cname:ch1_fec@example.com
        a=mid:Channel1_FEC

   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 SSM session.

   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.









Begen                   Expires December 12, 2011               [Page 9]

Internet-Draft               Deploying RAMS                    June 2011


        m=video 40000 RTP/AVPF 96 97
        c=IN IP4 233.252.0.1/127
        a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
        a=rtcp:41000 IN IP4 192.0.2.1
        a=rtpmap:96 MP2T/90000
        a=rtpmap:97 1d-interleaved-parityfec/90000
        a=fmtp:97 L=10; D=10; repair-window=200000
        a=ssrc:1 cname:ch1_video@example.com
        a=ssrc:2 cname:ch1_fec@example.com
        a=mid:Channel1
        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 can 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 could be
   possible to infer the bitrate of this FEC stream and set the Max
   Receive Bitrate value accordingly.


7.  Security Considerations

   There are no security considerations in this document.


8.  IANA Considerations

   There are no IANA considerations in this document.


9.  Acknowledgments

   I would like to thank various individuals in the AVTEXT and MMUSIC
   WGs, and my friends at Cisco for their comments and feedback.


10.  References

10.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-17 (work in



Begen                   Expires December 12, 2011              [Page 10]

Internet-Draft               Deploying RAMS                    June 2011


              progress), November 2010.

   [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.

   [RFC5760]  Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
              Protocol (RTCP) Extensions for Single-Source Multicast
              Sessions with Unicast Feedback", RFC 5760, February 2010.

10.2.  Informative References

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

   [RFC5956]  Begen, A., "Forward Error Correction Grouping Semantics in
              the Session Description Protocol", RFC 5956,
              September 2010.


Author's Address

   Ali Begen
   Cisco
   181 Bay Street
   Toronto, ON  M5J 2T3
   Canada

   Email:  abegen@cisco.com







Begen                   Expires December 12, 2011              [Page 11]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/