Duplicating RTP Streams
draft-begen-avtcore-rtp-duplication-00

AVT                                                             A. Begen
Internet-Draft                                                     Cisco
Intended status:  Standards Track                             C. Perkins
Expires:  April 26, 2012                           University of Glasgow
                                                        October 24, 2011

                        Duplicating RTP Streams
                 draft-begen-avtcore-rtp-duplication-00

Abstract

   Packet loss is undesirable for real-time multimedia sessions, but it
   is not avoidable due to congestion or other unplanned network
   outages.  This is especially the case for IP multicast networks.  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.  This document explains how RTP
   streams can be duplicated without breaking RTP and RTP Control
   Protocol (RTCP) rules.

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 April 26, 2012.

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 & Perkins          Expires April 26, 2012                 [Page 1]
Internet-Draft               RTP Duplication                October 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.  Terminology and Requirements Notation . . . . . . . . . . . . . 3
   3.  Dual Streaming Use Cases  . . . . . . . . . . . . . . . . . . . 3
     3.1.  Temporal Redundancy . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Spatial Redundancy  . . . . . . . . . . . . . . . . . . . . 4
       3.2.1.  Using Separate Source Interfaces  . . . . . . . . . . . 4
       3.2.2.  Using Separate Destination Addresses and/or Ports . . . 5
     3.3.  Dual Streaming over a Single Path or Multiple Paths . . . . 5
   4.  Use of RTP and RTCP with Temporal Redundancy  . . . . . . . . . 6
     4.1.  RTCP Considerations . . . . . . . . . . . . . . . . . . . . 6
     4.2.  Signaling Considerations  . . . . . . . . . . . . . . . . . 6
   5.  Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . . 7
     5.1.  RTCP Considerations . . . . . . . . . . . . . . . . . . . . 7
     5.2.  Signaling Considerations  . . . . . . . . . . . . . . . . . 7
   6.  Use of RTP and RTCP with Temporal and Spatial Redundancy  . . . 8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Begen & Perkins          Expires April 26, 2012                 [Page 2]
Internet-Draft               RTP Duplication                October 2011

1.  Introduction

   RTP [RFC3550] transport is widely used today for delivering real-time
   multimedia streams.  Most of the applications also rely on IP
   multicast to reach many receivers efficiently.

   While the combination proves successful, there does exist a weakness.
   As [RFC2354] noted, packet loss is not avoidable.  This might be due
   to congestion, it might also be a result of an unplanned outage
   caused by a flapping link, link or interface failure, a software bug,
   or a maintenance person accidentally cutting the wrong fiber.  Since
   UDP does not provide any means for detecting loss and retransmitting
   packets, it leaves up to the RTP or the applications to detect and
   recover from the loss.  For retransmission-based recovery, one
   example is described in [RFC4588].

   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 of this technique have
   already been implemented and deployed today [IC2011].  However,
   duplication of RTP streams without breaking the RTP and RTCP
   functionality has not been documented properly.  This document
   explains how duplication can be achieved for RTP streams.

2.  Terminology and 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.  Dual Streaming Use Cases

   Dual streaming refers to a technique that involves transmitting two
   redundant (often RTP) streams of the same content, with each stream
   itself capable of supporting the playback when there is no packet
   loss.  Therefore, adding an additional stream provides a protection
   against packet loss.  The level of protection depends on how the
   packets are sent and transmitted inside the network.

   It is important to note that redundant streaming can easily be
   extended to support cases when more than two streams are desired.
   But triple, quadruple, or more, streaming is rarely used in practice.

Begen & Perkins          Expires April 26, 2012                 [Page 3]
Internet-Draft               RTP Duplication                October 2011

3.1.  Temporal Redundancy

   From a routing perspective, two streams are considered identical if
   their following two fields are the same since they will be both
   routed over the same path:

   o  IP Source Address

   o  IP Destination Address

   Two routing-plane identical RTP streams might carry the same payload
   but they could use different Synchronization Sources (SSRC) to
   differentiate the RTP packets belonging to each stream.  In the
   context of dual streaming, we assume that the source duplicates the
   RTP packets and put them into separate RTP streams each with a unique
   SSRC identifier.  All the redundant streams are transmitted in the
   same RTP session.

   For example, two redundant RTP streams can be sent to the same IP
   destination address and UDP destination port with a certain delay
   between them [I-D.begen-mmusic-temporal-interleaving].  The streams
   carry the same payload in their respective RTP packets with identical
   sequence numbers.  This allows the receiver (or any other node
   responsible for duplicate suppression) to identify and suppress the
   duplicate packets, and subsequently produce a hopefully loss-free and
   duplication-free output stream (called stream merging).

3.2.  Spatial Redundancy

3.2.1.  Using Separate Source Interfaces

   An RTP source might have multiple network interfaces associated with
   it and it can send two redundant streams from two separate
   interfaces.  Such streams can be routed over diverse or identical
   paths depending on the routing algorithm inside the network.  At the
   receiving end, the node responsible for duplicate suppression can
   look into various RTP related fields to identify and suppress the
   duplicate packets.

   If source-specific multicast (SSM) transport is used to carry such
   redundant streams, there will be a separate SSM session for each
   redundant stream since the streams are sourced from different
   interfaces (i.e., IP addresses).  The receiving host has to join each
   SSM session separately.

Begen & Perkins          Expires April 26, 2012                 [Page 4]
Internet-Draft               RTP Duplication                October 2011

3.2.2.  Using Separate Destination Addresses and/or Ports

   An RTP source might send the redundant streams to separate IP
   destination addresses and/or UDP ports.

3.3.  Dual Streaming over a Single Path or Multiple Paths

   Having described the characteristics of the streams, one can reach
   the following conclusions:

   1.  When two routing-plane identical streams are used, the two
       streams will have identical IP headers.  This makes it
       impractical to forward the packets onto different paths.  In
       order to minimize packet loss, the packets belonging to one
       stream are often interleaved with packets belonging to the other,
       and with a delay, so that if there is a packet loss, such a delay
       would allow the same packet from the other stream to reach the
       receiver because the chances that the same packet is lost in
       transit again is often small.  This is what is also known as
       Time-shifted Redundancy, Temporal Redundancy or simply Delayed
       Duplication [I-D.begen-mmusic-temporal-interleaving] [IC2011].
       This approach can be used with all three types of dual streaming
       described in Section 3.1, Section 3.2.1 and Section 3.2.2.

   2.  If the two streams have different IP headers, an additional
       opportunity arises in that one is able to build a network, with
       physically diverse paths, to deliver the two streams concurrently
       to the intended receivers.  This reduces the delay when packet
       loss occurs and needs to be recovered.  Additionally, it also
       further reduces chances for packet loss.  An unrecoverable loss
       happens only when two network failures happen in such a way that
       the same packet is affected on both paths.  This is referred to
       as Spatial Diversity or Spatial Redundancy [IC2011].  The
       techniques used to build diverse paths are beyond the scope of
       this document.

       Note that spatial redundancy often offers less delay in
       recovering from packet loss provided that the forwarding delay of
       the network paths are more or less the same.  For both temporal
       and spatial redundancy approaches, packet misordering might still
       happen and needs to be handled using the RTP sequence numbers.

   To summarize, dual streaming allows an application and a network to
   work together to provide a near zero-loss transport with a bounded or
   minimum delay.  The additional advantage includes a predictable
   bandwidth overhead that is proportional to the minimum bandwidth
   needed for the multimedia session, but independent of the number of
   receivers experiencing a packet loss and requesting a retransmission.

Begen & Perkins          Expires April 26, 2012                 [Page 5]
Internet-Draft               RTP Duplication                October 2011

   For a survey and comparison of similar approaches, refer to [IC2011].

4.  Use of RTP and RTCP with Temporal Redundancy

   To achieve temporal redundancy, the main and redundant RTP streams
   are sent using the same source and destination IP addresses and ports
   (that is the 5-tuple of transport protocol, source and destination IP
   addresses, and source and destination transport ports is the same for
   both main and redundant RTP streams).  This is perhaps overly
   restrictive, but with the possible presence of network address and
   port translation (NAPT) devices, using anything other than an
   identical 5-tuple can also cause spatial redundancy.

   Since main and redundant RTP streams follow an identical path, they
   are part of the same RTP session.  Accordingly, the sender MUST
   choose a different SSRC for the redundant RTP stream than it chose
   for the main RTP stream, following the rules in [RFC3550] section 8.

4.1.  RTCP Considerations

   If RTCP is being sent for the main RTP stream, then the sender MUST
   also generate RTCP for the redundant RTP stream.  The RTCP for the
   redundant RTP stream is generated exactly as-if the redundant RTP
   stream were a regular media stream; the sender MUST NOT duplicate the
   RTCP packets sent for the main RTP stream.  The sender MUST use the
   same RTCP CNAME in the RTCP reports it sends for the main and
   redundant streams, so that the receiver can synchronize them.

   Both main and redundant streams, and their corresponding RTCP, will
   be received.  If RTCP is used, receivers MUST generate RTCP reports
   for both main and redundant streams in the usual way, treating them
   as entirely separate media streams.

   Editor's note:  The receiving node can also produce a new XR report
   to report on the (loss/delay/jitter/etc.) performance of the output
   stream after the stream merging process.  This is TBD.

4.2.  Signaling Considerations

   Signaling is needed to allow the receiver to determine that an RTP
   stream is a redundant copy of another, rather than a separate stream
   that needs to be rendered in parallel.  We need an SDP attribute to
   ensure that the receiver supports temporal redundancy, plus a new
   RTCP SDES item to indicate that this is a redundant stream that
   should not be directly rendered.

   Editor's notes:

Begen & Perkins          Expires April 26, 2012                 [Page 6]
Internet-Draft               RTP Duplication                October 2011

   o  How should we correlate the duplicate streams?  Grouping is
      straightforward when streams are SSRC-muxed but what if there are
      non-duplicated RTP streams in the same session?  Maybe also use
      Magnus' srcname proposal?

   The required SDP grouping semantics and SDP attribute have been
   defined in [I-D.begen-mmusic-redundancy-grouping] and
   [I-D.begen-mmusic-temporal-interleaving], respectively.

5.  Use of RTP and RTCP with Spatial Redundancy

   When using spatial redundancy, the redundant RTP stream is sent on
   using a different source and/or destination address/port pair.  This
   will be a separate RTP session to the session conveying the main RTP
   stream.

   SSRC for the redundant stream chosen randomly, following the rules in
   Section 8 of [RFC3550] and will almost certainly not match that of
   the main RTP stream.  Sender MUST use the same RTCP CNAME for both
   main and redundant streams, in their separate sessions.  Also the
   sender uses the new SDES item to indicate that this is a redundant
   stream.  This is how the receiver can correlate the flows (can use
   srcname if appropriate).

5.1.  RTCP Considerations

   If RTCP is being sent for the main RTP stream, then the sender MUST
   also generate RTCP for the redundant RTP stream.  The RTCP for the
   redundant RTP stream is generated exactly as-if the redundant RTP
   stream were a regular media stream; the sender MUST NOT duplicate the
   RTCP packets sent for the main RTP stream.  The sender MUST use the
   same RTCP CNAME in the RTCP reports it sends for the main and
   redundant streams, so that the receiver can synchronize them.

   Both main and redundant streams, and their corresponding RTCP, will
   be received.  If RTCP is used, receivers MUST generate RTCP reports
   for both main and redundant streams in the usual way, treating them
   as entirely separate media streams.

   Editor's note:  The receiving node can also produce a new XR report
   to report on the (loss/delay/jitter/etc.) performance of the output
   stream after the stream merging process.  This is TBD.

5.2.  Signaling Considerations

   The required SDP grouping semantics and SDP attribute have been
   defined in [I-D.begen-mmusic-redundancy-grouping] and

Begen & Perkins          Expires April 26, 2012                 [Page 7]
Internet-Draft               RTP Duplication                October 2011

   [I-D.begen-mmusic-temporal-interleaving], respectively.

6.  Use of RTP and RTCP with Temporal and Spatial Redundancy

   Editor's note:  Nothing new here.  This should use the same RTP/RTCP
   mechanisms, plus a combination of both sets of signaling.

7.  Security Considerations

   The security considerations of [RFC3550] apply to this memo.

   Additional security considerations are TBC.

   Editor's note:  Email from csp.  For the stream de-duplication
   device:  it seems that this would work with SRTP encryption
   [RFC3711], since the headers are in the clear, but would break the
   authentication when the SSRC is rewritten.  You could just re-
   authenticate the packets, and avoid re-encryption, with appropriate
   signaling of who authenticates the packets.

8.  IANA Considerations

   TBC.

9.  Acknowledgments

   Thanks to Magnus Westerlund for his suggestions.

10.  References

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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-03 (work in

Begen & Perkins          Expires April 26, 2012                 [Page 8]
Internet-Draft               RTP Duplication                October 2011

              progress), October 2011.

   [I-D.begen-mmusic-redundancy-grouping]
              Begen, A., Cai, Y., and H. Ou, "Duplication Grouping
              Semantics in the Session Description Protocol",
              draft-begen-mmusic-redundancy-grouping-02 (work in
              progress), October 2011.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

10.2.  Informative References

   [RFC2354]  Perkins, C. and O. Hodson, "Options for Repair of
              Streaming Media", RFC 2354, June 1998.

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006.

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

Authors' Addresses

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

   Email:  abegen@cisco.com

   Colin Perkins
   University of Glasgow
   School of Computing Science
   Glasgow,   G12 8QQ
   UK

   Email:  csp@csperkins.org

Begen & Perkins          Expires April 26, 2012                 [Page 9]