MMUSIC                                                          A. Begen
Internet-Draft                                                    Y. Cai
Intended status:  Standards Track                                  H. Ou
Expires:  September 13, 2011                                       Cisco
                                                          March 12, 2011


  Temporal Interleaving Attribute in the Session Description Protocol
              draft-begen-mmusic-temporal-interleaving-01

Abstract

   A straightforward approach to provide protection against network
   outages (or packet losses) 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 Temporal Redundancy or Temporal Interleaving.  This document
   defines an attribute to indicate the presence of temporally redundant
   media streams and the interleaving period 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 September 13, 2011.

Copyright Notice

   Copyright (c) 2011 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



Begen, et al.          Expires September 13, 2011               [Page 1]

 
Internet-Draft   Temporal Interleaving Attribute in SDP       March 2011


   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 . . . . . . . . . . . . . . . . . . . . . 4
   3.  The 'interleaving-period' Attribute . . . . . . . . . . . . . . 4
   4.  SDP Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Performance Evaluation and Reporting  . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
     7.1.  Registration of SDP Attributes  . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7































Begen, et al.          Expires September 13, 2011               [Page 2]

 
Internet-Draft   Temporal Interleaving Attribute in SDP       March 2011


.  Introduction

   Consider that a media sender transmits an original source packet and
   transmits its duplicate after an interleaving period 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 or 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 packet(s) and
   discard them appropriately, producing a duplication-free stream.

   Temporal interleaving can be used in a variety of multimedia
   applications where there is sufficient bandwidth for the duplicated
   traffic and the application can tolerate the delay caused by
   interleaving.  One particular use case is to improve the reliability
   of real-time video feeds inside a core IP network [IC2011].  Compared
   to other popular redundancy approaches such as Forward Error
   Correction (FEC) [I-D.ietf-fecframe-framework] and redundant data
   encoding (e.g., [RFC2198]), temporal interleaving 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].  The receiver can also use 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 interleaving period or how the receiver can
   suppress the duplicate packets.  Rather, we introduce a new attribute
   for the Session Description Protocol (SDP) [RFC4566] that indicates
   that the media stream is to be sent two or more times using the
   interleaving approach and also indicates the interleaving period for
   each additional duplication.

   In practice, more than two redundant streams for temporal
   interleaving 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 if needed.  The new attribute is
   applicable to both RTP and non-RTP streams.






Begen, et al.          Expires September 13, 2011               [Page 3]

 
Internet-Draft   Temporal Interleaving Attribute in SDP       March 2011


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


.  The 'interleaving-period' Attribute

   The following ABNF [RFC5234] syntax formally describes the
   'interleaving-period' attribute:


       interleaving-attribute = "a=interleaving-period:" periods CRLF
       periods                = period *( ":" period)
       period                 = 1*DIGIT ; in milliseconds

       Figure 1: ABNF syntax for the 'interleaving-period' attribute

   The 'interleaving-period' attribute is defined as both a media-level
   and session-level attribute.  It specifies the interleaving duration
   in milliseconds (ms).


.  SDP Examples

   In the example below, the multicast stream is duplicated with an
   interleaving period of 100 ms.


        v=0
        o=ali 1122334455 1122334466 IN IP4 red.example.com
        s=Temporal Interleaving
        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=interleaving-period:100
        a=mid:S1

   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.




Begen, et al.          Expires September 13, 2011               [Page 4]

 
Internet-Draft   Temporal Interleaving Attribute in SDP       March 2011


        v=0
        o=ali 1122334455 1122334466 IN IP4 red.example.com
        s=Temporal Interleaving
        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=interleaving-period:50:100
        a=mid:S2


.  Performance Evaluation and Reporting

   Editor's note:  This section should discuss how the receiver should
   prepare the RTCP receiver reports or whether a new XR report is
   needed.


.  Security Considerations

   The 'interleaving-period' 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 interleaving periods and/or the number of redundant
   streams.  For example, if the malevolent third party increases the
   value of the interleaving period, the receiver(s) will unnecessarily
   incur a longer delay since they will have to wait for the entire
   interleaving period.  Or, if the interleaving period 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.


.  IANA Considerations

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



Begen, et al.          Expires September 13, 2011               [Page 5]

 
Internet-Draft   Temporal Interleaving Attribute in SDP       March 2011


   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.

7.1.  Registration of SDP Attributes

   This document registers a new attribute name in SDP.


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


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

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

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

   [I-D.ietf-fecframe-framework]
              Watson, M., Begen, A., and V. Roca, "Forward Error
              Correction (FEC) Framework",
              draft-ietf-fecframe-framework-14 (work in progress),



Begen, et al.          Expires September 13, 2011               [Page 6]

 
Internet-Draft   Temporal Interleaving Attribute in SDP       March 2011


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

   [IC2011]   Evans, J., Begen, A., Greengrass, J., and C. Filsfils,
              "Towards Lossless Video Transport (in submission to IEEE
              Internet Computing)", 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

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

   Email:  abegen@cisco.com


   Yiqun Cai
   Cisco
   170 W. Tasman Dr.
   San Jose, CA  95134
   USA

   Email:  ycai@cisco.com









Begen, et al.          Expires September 13, 2011               [Page 7]

 
Internet-Draft   Temporal Interleaving Attribute in SDP       March 2011


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

   Email:  hou@cisco.com












































Begen, et al.          Expires September 13, 2011               [Page 8]