AVTEXT A. Begen Internet-Draft Cisco Intended status: Informational April 18, 2012 Expires: October 20, 2012 Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method draft-ietf-avtext-rams-scenarios-04 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 discusses how the RAMS solution could be used in such scenarios. 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 October 20, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Begen Expires October 20, 2012 [Page 1] Internet-Draft RAMS Considerations April 2012 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Scenario #1: Two Multicast Groups . . . . . . . . . . . . 4 3.2. Scenario #2: One Multicast Group . . . . . . . . . . . . . 5 3.3. Scenario #3: SSRC Multiplexing . . . . . . . . . . . . . . 6 3.4. Scenario #4: Payload-Type Multiplexing . . . . . . . . . . 7 4. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 7 5. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7 5.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Begen Expires October 20, 2012 [Page 2] Internet-Draft RAMS Considerations April 2012 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 [RFC6285]. The RAMS specification [RFC6285] has provisions for concurrently acquiring multiple streams inside a multicast RTP session. However, the RAMS specification does not discuss scenarios where an RTP receiver makes use of the RAMS method to rapidly acquire multiple and associated multicast streams in parallel, or where different RTP sessions are part of the same source-specific multicast (SSM) session. The example presented in Section 8.3 of [RFC6285] addresses only the simple case of an RTP receiver rapidly acquiring only one multicast stream to explain the protocol details. There are certain deployment models where a multicast RTP session might have two or more multicast streams associated with it. There are also cases, where an RTP receiver might be interested in acquiring one or more multicast streams from several multicast RTP sessions. In scenarios where multiple RAMS sessions, each initiated with an individual RAMS Request message to a different feedback target, will be simultaneously run by an RTP receiver, they need to be coordinated. In this document, we present scenarios from real- life deployments and discuss how the RAMS solution could be used in such scenarios. 2. 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. An SSM session is defined by its (distribution) source address and (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 Begen Expires October 20, 2012 [Page 3] Internet-Draft RAMS Considerations April 2012 combination of address and port) to be associated with at most one RTP session (See Section 6.2 of [RFC6285]). Two or more multicast RTP streams can be transmitted in the same RTP session (e.g., 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 (e.g., 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 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 [RFC6285]. 3. Example Scenarios 3.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. Each requires a separate RAMS Request message to be sent. 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 October 20, 2012 [Page 4] Internet-Draft RAMS Considerations April 2012 v=0 o=ali 1122334455 1122334466 IN IP4 rams.example.com s=RAMS Scenarios t=0 0 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]. 3.2. Scenario #2: One Multicast Group Here 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. The RAMS Request message sent by an RTP receiver to the feedback target could indicate the desire to acquire all or a subset or one of the available RTP streams. Thus, both the primary video and audio streams can be acquired rapidly in parallel. Or, the RTP receiver can acquire only the primary video or audio stream, if desired, by indicating the specific SSRC in the request. 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 delivered in the same multicast session. Begen Expires October 20, 2012 [Page 5] Internet-Draft RAMS Considerations April 2012 v=0 o=ali 1122334455 1122334466 IN IP4 rams.example.com s=RAMS Scenarios t=0 0 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 "m" lines 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. 3.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, both the primary video and audio streams can be acquired rapidly in parallel. Or, the RTP receiver can acquire only the primary video or audio stream, if desired, by indicating the specific SSRC in the request. 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 October 20, 2012 [Page 6] Internet-Draft RAMS Considerations April 2012 v=0 o=ali 1122334455 1122334466 IN IP4 rams.example.com s=RAMS Scenarios t=0 0 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 3.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 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]. 4. 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, this is not an easy requirement to satisfy. Thus, RAMS specification forbids to have more than one RTP session to be associated with a specific feedback target on a specific port. 5. 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 associated 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 Begen Expires October 20, 2012 [Page 7] Internet-Draft RAMS Considerations April 2012 can specify the bitrate ("b=" line in Kbps) of each media session (per "m" line). 5.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 [RFC6363]. Having FEC in a different multicast group provides two flexibility points: RTP receivers that are not FEC capable can receive the primary video stream without FEC, and RTP receivers that are FEC capable can decide to not receive FEC during the rapid acquisition (but still start receiving the FEC stream after the acquisition of the primary video stream has been completed). v=0 o=ali 1122334455 1122334466 IN IP4 rams.example.com s=RAMS Scenarios t=0 0 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 for the primary video stream. 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 Begen Expires October 20, 2012 [Page 8] Internet-Draft RAMS Considerations April 2012 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. 5.2. Scenario #2 Here RTP streams 1 (primary video) and 2 (FEC) are transmitted over the same multicast group with different destination ports. This is not a preferred deployment model. v=0 o=ali 1122334455 1122334466 IN IP4 rams.example.com s=RAMS Scenarios t=0 0 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 The RAMS Request message sent by an RTP receiver to the feedback target could indicate the desire to acquire all or a subset or one of the available RTP streams. Thus, both the primary video and FEC streams can be acquired rapidly in parallel sharing the same available bandwidth. Or, the RTP receiver can acquire only the primary video stream by indicating its specific SSRC in the request. In this case, the RTP receiver can first acquire 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 Begen Expires October 20, 2012 [Page 9] Internet-Draft RAMS Considerations April 2012 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. 5.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. v=0 o=ali 1122334455 1122334466 IN IP4 rams.example.com s=RAMS Scenarios t=0 0 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 b=TIAS:11000 a=mid:Channel1 Similar to scenario #2, both the primary video and audio streams can be acquired rapidly in parallel. Or, the RTP receiver can acquire only the primary video stream, if desired, by indicating its specific SSRC in the request. 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. 6. Security Considerations There are no security considerations in this document. 7. IANA Considerations There are no IANA considerations in this document. Begen Expires October 20, 2012 [Page 10] Internet-Draft RAMS Considerations April 2012 8. Acknowledgments I would like to thank various individuals in the AVTEXT and MMUSIC WGs, and my friends at Cisco for their comments and feedback. 9. References 9.1. Normative References [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 2011. 9.2. Informative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [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. [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. [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011. Begen Expires October 20, 2012 [Page 11] Internet-Draft RAMS Considerations April 2012 Author's Address Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada Email: abegen@cisco.com Begen Expires October 20, 2012 [Page 12]