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

Versions: (draft-begen-mmusic-temporal-interleaving) 00 01 02 03 RFC 7197

MMUSIC                                                          A. Begen
Internet-Draft                                                     Cisco
Intended status: Standards Track                                  Y. Cai
Expires: November 28, 2013                                     Microsoft
                                                                   H. Ou
                                                                   Cisco
                                                            May 27, 2013


   Delayed Duplication Attribute in the Session Description Protocol
                draft-ietf-mmusic-delayed-duplication-02

Abstract

   A straightforward approach to provide protection against packet
   losses due to network outages with a longest duration of T time units
   is to simply duplicate the original packets and send each copy
   separated in time by at least T time units.  This approach is
   commonly referred to as Time-shifted Redundancy, Temporal Redundancy
   or simply Delayed Duplication.  This document defines an attribute to
   indicate the presence of temporally redundant media streams and the
   duplication delay in the Session Description Protocol.

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 November 28, 2013.

Copyright Notice

   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



Begen, et al.          Expires November 28, 2013                [Page 1]

Internet-Draft    Delayed Duplication Attribute in SDP          May 2013


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
   3.  The 'duplication-delay' Attribute . . . . . . . . . . . . . .   3
   4.  SDP Examples  . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Registration of SDP Attributes  . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Consider that a media sender transmits an original source packet and
   transmits its duplicate after a certain delay following the original
   transmission.  If a network outage hits the original transmission,
   the expectation is that the second transmission arrives at the
   receiver.  Alternatively, the second transmission may be hit by an
   outage and gets dropped, and the original transmission completes
   successfully.  On the receiver side, both transmissions can also
   arrive and in that case, the receiver (or the node that does the
   duplicate suppression) needs to identify the duplicate packets and
   discard them appropriately, producing a duplicate-free stream.

   Delayed duplication can be used in a variety of multimedia
   applications where there is sufficient bandwidth for the duplicated
   traffic and the application can tolerate the introduced delay.
   However, it must be used with care since it might easily result in a
   new series of denial-of-service attacks.  Furthermore, delayed
   duplication must not be used in cases where the primary cause of
   packet loss is congestion, rather than a network outage due to a
   temporary link or network element failure.  Duplication can make
   congestion only worse.

   One particular use case for delayed duplication is to improve the
   reliability of real-time video feeds inside a core IP network
   [IC2011].  Compared to other popular redundancy approaches such as



Begen, et al.          Expires November 28, 2013                [Page 2]

Internet-Draft    Delayed Duplication Attribute in SDP          May 2013


   Forward Error Correction (FEC) [RFC6363] and redundant data encoding
   (e.g., [RFC2198]), delayed duplication is quite easy to implement
   since it does not require any special type of encoding or decoding.

   For duplicate suppression, the receiver has to be able to identify
   the identical packets.  This is straightforward for media packets
   that carry one or more unique identifiers such as the sequence number
   field in RTP header [RFC3550].  In non-RTP applications, the receiver
   can use unique sequence numbers if available or other alternative
   approaches to compare the incoming packets and discard the duplicate
   ones.

   In this specification, we are not concerned about how the sender
   should determine the duplication delay.  We are not concerned about
   how the receiver can suppress the duplicate packets and merge the
   incoming streams to produce a hopefully loss-free and duplication-
   free output stream (a process commonly called stream merging),
   either.  These considerations are out of the scope for this
   specification.  Rather, our goal is to introduce a new attribute for
   the Session Description Protocol (SDP) [RFC4566] to indicate that a
   media stream is to be duplicated and transmitted two or more times,
   and also to indicate the relative delay for each additional
   duplication.

   In practice, more than two redundant streams are unlikely to be used
   since the additional delay and increased overhead are not easily
   justified.  However, we define the new attribute in a general way so
   that it could be used with more than two redundant streams (i.e.,
   multiple duplications), if needed.  While the primary focus in this
   specification is the RTP-based transport, the new attribute is
   applicable to both RTP and non-RTP streams.  Details on duplicating
   RTP streams are presented in [I-D.ietf-avtext-rtp-duplication].

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.  The 'duplication-delay' Attribute

   The following ABNF [RFC5234] syntax formally describes the
   'duplication-delay' attribute:

   delaying-attribute     = "a=duplication-delay:" periods CRLF
   periods                = period *( SP period)
   period                 = 1*DIGIT ; in milliseconds



Begen, et al.          Expires November 28, 2013                [Page 3]

Internet-Draft    Delayed Duplication Attribute in SDP          May 2013


        Figure 1: ABNF syntax for the 'duplication-delay' attribute

   The 'duplication-delay' attribute is defined as both a media-level
   and session-level attribute.  It specifies the relative delay with
   respect to the previous stream for each duplication in milliseconds
   (ms) at the time of transmission.  The following rules apply:

   o  If used as a media-level attribute, it MUST be used with the
      'ssrc-group' attribute and "DUP" grouping semantics as defined in
      [I-D.ietf-mmusic-duplication-grouping].  When used as a media-
      level attribute, the relative delay value(s) it specifies SHALL
      apply to every Synchronization Source (SSRC)-based duplication
      grouping in the same media description.  In other words, one
      cannot specify different duplication delay values to different
      duplication groups in the same media description.

   o  If used as a session-level attribute, it MUST be used with 'group'
      attribute and "DUP" grouping semantics as defined in
      [I-D.ietf-mmusic-duplication-grouping].  When used as a session-
      level attribute, the relative delay value(s) it specifies SHALL
      apply to every duplication grouping in the same SDP description.
      In other words, one cannot specify different duplication delay
      values to different duplication groups in the same SDP
      description.  If one needs to specify different duplication delay
      values for different duplication groups, then one MUST use
      different SDP descriptions for each or MUST use the 'duplication-
      delay' attribute at media level.  In that case, the 'duplication-
      delay' attribute MUST NOT be used at the session level.

   o  For offer/answer model considerations, refer to
      [I-D.ietf-mmusic-duplication-grouping].

4.  SDP Examples

   In the first example below, the multicast stream consists of two RTP
   streams, each duplicated once, resulting in two sets of two-stream
   groups.  The same duplication delay of 100 ms is applied to each
   grouping.  The first set's streams have SSRCs of 1000 and 1010 and
   the second set's streams have SSRCs of 1020 and 1030.

        v=0
        o=ali 1122334455 1122334466 IN IP4 dup.example.com
        s=Delayed Duplication
        t=0 0
        m=video 30000 RTP/AVP 100 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:100 MP2T/90000



Begen, et al.          Expires November 28, 2013                [Page 4]

Internet-Draft    Delayed Duplication Attribute in SDP          May 2013


        a=ssrc:1000 cname:ch1a@example.com
        a=ssrc:1010 cname:ch1a@example.com
        a=ssrc-group:DUP 1000 1010
        a=rtpmap:101 MP2T/90000
        a=ssrc:1020 cname:ch1b@example.com
        a=ssrc:1030 cname:ch1b@example.com
        a=ssrc-group:DUP 1020 1030
        a=duplication-delay:100
        a=mid:Ch1



   Note that in actual use, SSRC values, which are random 32-bit
   numbers, could be much larger than the ones shown in this example.

   In the second example below, the multicast stream is duplicated
   twice.  50 ms after the original transmission, the first duplicate is
   transmitted and 100 ms after that, the second duplicate is
   transmitted.  In other words, the same packet is transmitted three
   times over a period of 150 ms.

        v=0
        o=ali 1122334455 1122334466 IN IP4 dup.example.com
        s=Delayed Duplication
        t=0 0
        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:ch1c@example.com
        a=ssrc:1010 cname:ch1c@example.com
        a=ssrc:1020 cname:ch1c@example.com
        a=ssrc-group:DUP 1000 1010 1020
        a=duplication-delay:50 100
        a=mid:Ch1



   In the third example below, the multicast UDP stream is duplicated
   with a duplication delay of 50 ms.  Redundant streams are sent in
   separate source-specific multicast (SSM) sessions so the receiving
   host has to join both SSM sessions if it wants to receive both
   streams.

     v=0
     o=ali 1122334455 1122334466 IN IP4 dup.example.com
     s=Delayed Duplication
     t=0 0



Begen, et al.          Expires November 28, 2013                [Page 5]

Internet-Draft    Delayed Duplication Attribute in SDP          May 2013


     a=group:DUP S1a S1b
     a=duplication-delay:50
     m=audio 30000 udp mp4
     c=IN IP4 233.252.0.1/127
     a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
     a=mid:S1a
     m=audio 40000 udp mp4
     c=IN IP4 233.252.0.2/127
     a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
     a=mid:S1b


5.  Security Considerations

   The 'duplication-delay' attribute is not believed to introduce any
   significant security risk to multimedia applications.  A malevolent
   third party could use this attribute to misguide the receiver(s)
   about the duplication delays and/or the number of redundant streams.
   For example, if the malevolent third party increases the value of the
   duplication delay, the receiver(s) will unnecessarily incur a longer
   delay since they will have to wait for the entire period.  Or, if the
   duplication delay is reduced by the malevolent third party, the
   receiver(s) might not wait long enough for the duplicated
   transmission and incur unnecessary packet losses.  However, these
   require intercepting and rewriting the packets carrying the SDP
   description; and if an interceptor can do that, many more attacks are
   also possible.

   In order to avoid attacks of this sort, the SDP description needs to
   be integrity protected and provided with source authentication.  This
   can, for example, be achieved on an end-to-end basis using S/MIME
   [RFC5652] [RFC5751] when SDP is used in a signaling packet using MIME
   types (application/sdp).  Alternatively, HTTPS [RFC2818] or the
   authentication method in the Session Announcement Protocol (SAP)
   [RFC2974] could be used as well.

   Another security risk is due to possible software misconfiguration or
   a software bug where a large number of duplicates could be
   unwillingly signaled in the 'duplication-delay' attribute.
   Similarly, an attacker can use this attribute to start a denial-of-
   service attack by signaling and sending too many duplicated streams.
   In applications where this attribute is to be used, it is a good
   practice to put a hard limit both on the number of duplicate streams
   and the total delay introduced due to duplication regardless of what
   the SDP description specifies.

6.  IANA Considerations




Begen, et al.          Expires November 28, 2013                [Page 6]

Internet-Draft    Delayed Duplication Attribute in SDP          May 2013


   The following contact information shall be used for all registrations
   in this document:

   Ali Begen
   abegen@cisco.com



   Note to the RFC Editor: In the following, replace "XXXX" with the
   number of this document prior to publication as an RFC.

6.1.  Registration of SDP Attributes

   This document registers a new attribute name in SDP.

     SDP Attribute ("att-field"):
     Attribute name:     duplication-delay
     Long form:          Duplication delay for temporally redundant
                         streams
     Type of name:       att-field
     Type of attribute:  Media or session level
     Subject to charset: No
     Purpose:            Specifies the relative duplication delay(s) for
                         redundant stream(s)
     Reference:          [RFCXXXX]
     Values:             See [RFCXXXX]


7.  Acknowledgements

   Authors would like to thank Colin Perkins and Paul Kyzivat for their
   suggestions and reviews.

8.  References

8.1.  Normative References

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

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.





Begen, et al.          Expires November 28, 2013                [Page 7]

Internet-Draft    Delayed Duplication Attribute in SDP          May 2013


   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [I-D.ietf-mmusic-duplication-grouping]
              Begen, A., Cai, Y., and H. Ou, "Duplication Grouping
              Semantics in the Session Description Protocol", draft-
              ietf-mmusic-duplication-grouping-01 (work in progress),
              March 2013.

8.2.  Informative References

   [RFC6363]  Watson, M., Begen, A., and V. Roca, "Forward Error
              Correction (FEC) Framework", RFC 6363, October 2011.

   [RFC2198]  Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
              Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
              Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
              September 1997.

   [I-D.ietf-avtext-rtp-duplication]
              Begen, A. and C. Perkins, "Duplicating RTP Streams",
              draft-ietf-avtext-rtp-duplication-01 (work in progress),
              December 2012.

   [IC2011]   Evans, J., Begen, A., Greengrass, J., and C. Filsfils,
              "Toward Lossless Video Transport (to appear in IEEE
              Internet Computing)", November 2011.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, October 2000.

Authors' Addresses










Begen, et al.          Expires November 28, 2013                [Page 8]

Internet-Draft    Delayed Duplication Attribute in SDP          May 2013


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

   Email: abegen@cisco.com


   Yiqun Cai
   Microsoft
   1065 La Avenida
   Mountain View, CA  94043
   USA

   Email: yiqunc@microsoft.com


   Heidi Ou
   Cisco
   170 W. Tasman Dr.
   San Jose, CA  95134
   USA

   Email: hou@cisco.com

























Begen, et al.          Expires November 28, 2013                [Page 9]


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