--- 1/draft-ietf-mmusic-duplication-grouping-00.txt 2013-04-11 14:17:21.417656245 +0100 +++ 2/draft-ietf-mmusic-duplication-grouping-01.txt 2013-04-11 14:17:21.437656733 +0100 @@ -1,21 +1,21 @@ MMUSIC A. Begen Internet-Draft Cisco Intended status: Standards Track Y. Cai -Expires: April 6, 2013 Microsoft +Expires: September 21, 2013 Microsoft H. Ou Cisco - October 3, 2012 + March 20, 2013 Duplication Grouping Semantics in the Session Description Protocol - draft-ietf-mmusic-duplication-grouping-00 + draft-ietf-mmusic-duplication-grouping-01 Abstract Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping @@ -33,52 +33,52 @@ 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 April 6, 2013. + This Internet-Draft will expire on September 21, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 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 Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 3. Duplication Grouping . . . . . . . . . . . . . . . . . . . . . 3 3.1. "DUP" Grouping Semantics . . . . . . . . . . . . . . . . . 3 - 3.2. DUP Grouping for SSRC-Multiplexed RTP Streams . . . . . . . 4 + 3.2. Duplication Grouping for SSRC-Multiplexed RTP Streams . . . 4 3.3. SDP Offer/Answer Model Considerations . . . . . . . . . . . 4 4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Separate Source Addresses . . . . . . . . . . . . . . . . . 5 4.2. Separate Destination Addresses . . . . . . . . . . . . . . 5 4.3. Temporal Redundancy . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The Real-time Transport Protocol (RTP) [RFC3550] is widely used today for delivering IPTV traffic, and other real-time multimedia sessions. Many of these applications support very large numbers of receivers, @@ -93,24 +93,24 @@ person accidentally cutting the wrong fiber. Since UDP/IP flows do not provide any means for detecting loss and retransmitting packets, it leaves up to the RTP layer and the applications to detect, and recover from, packet loss. One technique to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. Variations on this idea have been implemented and deployed today [IC2011]. [I-D.ietf-avtext-rtp-duplication] explains how duplication can be - achieved for RTP streams without breaking the RTP and RTCP - functionality. In this document, we describe the semantics needed in - the Session Description Protocol (SDP) [RFC4566] to support this - technique. + achieved for RTP streams without breaking the RTP and RTP Control + Protocol (RTCP) functionality. In this document, we describe the + semantics needed in the Session Description Protocol (SDP) [RFC4566] + to support this technique. 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]. 3. Duplication Grouping @@ -118,45 +118,46 @@ Each "a=group" line is used to indicate an association relationship between the redundant streams. The streams included in one "a=group" line are called a Duplication Group. Using the framework in [RFC5888], this document defines "DUP" as the grouping semantics for redundant streams. The "a=group:DUP" semantics MUST be used to group the redundant streams except when the streams are specified in the same media - description, i.e., in the same "m" line (See Section 3.2). - - When the redundant streams are described in separate "m" lines and - the 'group' attribute is used to describe the redundancy relation, - the SSRCs for each redundant stream MUST be announced in the SDP - description using the 'ssrc' attribute [RFC5576]. According to - [I-D.ietf-avtext-rtp-duplication], the sender must also use the same - RTCP CNAME for both the main and redundant streams, and must include - an "a=ssrc:... srcname:..." attribute to correlate the flows. + description, i.e., in the same "m" line (See Section 3.2). In an + "a=group:DUP" line, the order of the listed redundant streams does + not strictly indicate the order of transmission, although it is + RECOMMENDED that the stream listed first is sent first, with the + other stream(s) being the (time-delayed) duplicate(s). -3.2. DUP Grouping for SSRC-Multiplexed RTP Streams +3.2. Duplication Grouping for SSRC-Multiplexed RTP Streams [RFC5576] defines an SDP media-level attribute, called 'ssrc-group', for grouping the RTP streams that are SSRC multiplexed and carried in the same RTP session. The grouping is based on the SSRC identifiers. Since SSRC-multiplexed RTP streams are defined in the same "m" line, the 'group' attribute cannot be used. - This section specifies how duplication is used with SSRC-multiplexed + This section explains how duplication is used with SSRC-multiplexed streams using the 'ssrc-group' attribute [RFC5576]. The semantics of "DUP" for the 'ssrc-group' attribute are the same as the one defined for the 'group' attribute except that the SSRC identifiers are used to designate the duplication grouping - associations: a=ssrc-group:DUP *(SP ssrc-id) [RFC5576]. + associations: a=ssrc-group:DUP *(SP ssrc-id) [RFC5576]. As above, + while in an "a=ssrc-group:DUP" line, the order of the listed + redundant streams does not necessarily indicate the order of + transmission, it is RECOMMENDED that the stream listed first is sent + first, with the other stream(s) being the (time-delayed) + duplicate(s). 3.3. SDP Offer/Answer Model Considerations When offering duplication grouping using SDP in an Offer/Answer model [RFC3264], the following considerations apply. A node that is receiving an offer from a sender may or may not understand line grouping. It is also possible that the node understands line grouping but it does not understand the "DUP" semantics. From the viewpoint of the sender of the offer, these @@ -188,82 +189,80 @@ o=ali 1122334455 1122334466 IN IP4 dup.example.com s=DUP Grouping Semantics t=0 0 m=video 30000 RTP/AVP 100 c=IN IP4 232.252.0.1/127 a=source-filter:incl IN IP4 232.252.0.1 198.51.100.1 198.51.100.2 a=rtpmap:100 MP2T/90000 a=ssrc:1000 cname:ch1@example.com a=ssrc:1010 cname:ch1@example.com a=ssrc-group:DUP 1000 1010 - a=mid:Group1 + a=mid:Ch1 Note that in actual use, SSRC values, which are random 32-bit numbers, can be much larger than the ones shown in this example. + Also note that this SDP description does not use the 'duplication- + delay' attribute (defined in [I-D.ietf-mmusic-delayed-duplication]) + since the sender does not apply any delay between the redundant + streams upon transmission. Alternatively, one could be more explicit + and insert an "a=duplication-delay:0" line before the "a=mid:Ch1" + line. 4.2. Separate Destination Addresses In this example, the redundant streams have different IP destination addresses. The example shows the same UDP port number and IP source - addresses, but either or both could have been different for the two - streams. + address for each stream, but either or both could have been different + for the two streams. v=0 o=ali 1122334455 1122334466 IN IP4 dup.example.com s=DUP Grouping Semantics t=0 0 a=group:DUP S1a S1b m=video 30000 RTP/AVP 100 c=IN IP4 233.252.0.1/127 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=rtpmap:100 MP2T/90000 - a=ssrc:1000 cname:ch1@example.com - a=ssrc:1000 srcname:45:a8:f4:19:b4:c3 a=mid:S1a m=video 30000 RTP/AVP 101 c=IN IP4 233.252.0.2/127 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 a=rtpmap:101 MP2T/90000 - a=ssrc:1010 cname:ch1@example.com - a=ssrc:1010 srcname:45:a8:f4:19:b4:c3 a=mid:S1b + Optionally, one could be more explicit and insert an "a=duplication- + delay:0" line before the first "m" line. + 4.3. Temporal Redundancy In this example, the redundant streams have the same IP source and - destination addresses but different UDP port numbers. Due to the - same source and destination addresses, the packets in both streams - will be routed over the same path. To provide resiliency against - packet loss, the duplicate of an original packet is transmitted 50 ms - later as indicated by the 'duplication-delay' attribute (defined in - [I-D.begen-mmusic-temporal-interleaving]). + destination addresses (i.e., they are transmitted in the same SSM + session). Due to the same source and destination addresses, the + packets in both streams will be routed over the same path. To + provide resiliency against packet loss, the duplicate of an original + packet is transmitted 50 ms later as indicated by the 'duplication- + delay' attribute (defined in [I-D.ietf-mmusic-delayed-duplication]). v=0 o=ali 1122334455 1122334466 IN IP4 dup.example.com - s=DUP Grouping Semantics + s=Delayed Duplication t=0 0 - a=group:DUP S1a S1b - a=duplication-delay:50 m=video 30000 RTP/AVP 100 c=IN IP4 233.252.0.1/127 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=rtpmap:100 MP2T/90000 - a=ssrc:1000 cname:ch1@example.com - a=ssrc:1000 srcname:45:a8:f4:19:b4:c3 - a=mid:S1a - m=video 40000 RTP/AVP 101 - c=IN IP4 233.252.0.1/127 - a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 - a=rtpmap:101 MP2T/90000 - a=ssrc:1010 cname:ch1@example.com - a=ssrc:1010 srcname:45:a8:f4:19:b4:c3 - a=mid:S1b + a=ssrc:1000 cname:ch1a@example.com + a=ssrc:1010 cname:ch1a@example.com + a=ssrc-group:DUP 1000 1010 + a=duplication-delay:50 + a=mid:Ch1 5. Security Considerations There is a weak threat for the receiver that the duplication grouping can be modified to indicate relationships that do not exist. Such attacks might result in failure of the duplication mechanisms, and/or mishandling of the media streams by the receivers. In order to avoid attacks of this sort, the SDP description needs to be integrity protected and provided with source authentication. This @@ -318,30 +316,30 @@ [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 8.2. Informative References - [I-D.begen-mmusic-temporal-interleaving] - Begen, A., Cai, Y., and H. Ou, "Delayed Duplication - Attribute in the Session Description Protocol", - draft-begen-mmusic-temporal-interleaving-04 (work in - progress), March 2012. - [I-D.ietf-avtext-rtp-duplication] Begen, A. and C. Perkins, "Duplicating RTP Streams", - draft-ietf-avtext-rtp-duplication-00 (work in progress), - July 2012. + draft-ietf-avtext-rtp-duplication-01 (work in progress), + December 2012. + + [I-D.ietf-mmusic-delayed-duplication] + Begen, A., Cai, Y., and H. Ou, "Delayed Duplication + Attribute in the Session Description Protocol", + draft-ietf-mmusic-delayed-duplication-00 (work in + progress), October 2012. [IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils, "Toward Lossless Video Transport (to appear in IEEE Internet Computing)", November 2011. [RFC2354] Perkins, C. and O. Hodson, "Options for Repair of Streaming Media", RFC 2354, June 1998. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.