draft-ietf-avtext-rtp-duplication-05.txt   draft-ietf-avtext-rtp-duplication-06.txt 
AVTEXT A. Begen AVTEXT A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track C. Perkins Intended status: Standards Track C. Perkins
Expires: August 11, 2014 University of Glasgow Expires: August 24, 2014 University of Glasgow
February 7, 2014 February 20, 2014
Duplicating RTP Streams Duplicating RTP Streams
draft-ietf-avtext-rtp-duplication-05 draft-ietf-avtext-rtp-duplication-06
Abstract Abstract
Packet loss is undesirable for real-time multimedia sessions, but can Packet loss is undesirable for real-time multimedia sessions, but can
occur due to congestion, or other unplanned network outages. This is occur due to a variety of reasons including unplanned network
especially true for IP multicast networks, where packet loss patterns outages. In unicast transmissions, recovering from such an outage
can vary greatly between receivers. One technique that can be used can be difficult depending on the outage duration due to the
to recover from packet loss without incurring unbounded delay for all potential large number of missing packets. In multicast
the receivers is to duplicate the packets and send them in separate transmissions, recovery is even more challenging as many receivers
redundant streams. This document explains how Real-time Transport could be impacted by the outage. One solution to this challenge
Protocol (RTP) streams can be duplicated without breaking RTP or RTP without incurring unbounded delay is to duplicate the packets and
Control Protocol (RTCP) rules. send them in separate redundant streams, provided that the underlying
network satisfies certain requirements. This document explains how
Real-time Transport Protocol (RTP) streams can be duplicated without
breaking RTP or RTP Control Protocol (RTCP) rules.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2014. This Internet-Draft will expire on August 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Requirements Notation . . . . . . . . . . . . 3 2. Terminology and Requirements Notation . . . . . . . . . . . . 3
3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . 3 3. Dual Streaming Use Cases . . . . . . . . . . . . . . . . . . 3
3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 3 3.1. Temporal Redundancy . . . . . . . . . . . . . . . . . . . 4
3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 4 3.2. Spatial Redundancy . . . . . . . . . . . . . . . . . . . 4
3.3. Dual Streaming over a Single Path or Multiple Paths . . . 4 3.3. Dual Streaming over a Single Path or Multiple Paths . . . 5
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 6 4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 6
4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6 4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6
4.2. Signaling Considerations . . . . . . . . . . . . . . . . 7 4.2. Signaling Considerations . . . . . . . . . . . . . . . . 7
5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 7 5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 8
5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8 5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8
5.2. Signaling Considerations . . . . . . . . . . . . . . . . 8 5.2. Signaling Considerations . . . . . . . . . . . . . . . . 9
6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 9 6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 9
7. Congestion Control Considerations . . . . . . . . . . . . . . 9 7. Congestion Control Considerations . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] is widely used today The Real-time Transport Protocol (RTP) [RFC3550] is widely used today
for delivering IPTV traffic, and other real-time multimedia sessions. for delivering IPTV traffic, and other real-time multimedia sessions.
Many of these applications support very large numbers of receivers, Many of these applications support very large numbers of receivers,
and rely on intra-domain UDP/IP multicast for efficient distribution and rely on intra-domain UDP/IP multicast for efficient distribution
of traffic within the network. of traffic within the network.
While this combination has proved successful, there does exist a While this combination has proved successful, there does exist a
weakness. As [RFC2354] noted, packet loss is not avoidable, even in weakness. As [RFC2354] noted, packet loss is not avoidable. This
a carefully managed network. This loss might be due to congestion, loss might be due to congestion; it might also be a result of an
it might also be a result of an unplanned outage caused by a flapping unplanned outage caused by a flapping link, link or interface
link, link or interface failure, a software bug, or a maintenance failure, a software bug, or a maintenance person accidentally cutting
person accidentally cutting the wrong fiber. Since UDP/IP flows do the wrong fiber. Since UDP/IP flows do not provide any means for
not provide any means for detecting loss and retransmitting packets, detecting loss and retransmitting packets, it is left up to the RTP
it leaves up to the RTP layer and the applications to detect, and layer and the applications to detect, and recover from, packet loss.
recover from, packet loss.
One technique to recover from packet loss without incurring unbounded In a carefully managed network, congestion should not normally
delay for all the receivers is to duplicate the packets and send them happen, however, network outages can still happen due to the reasons
in separate redundant streams. Variations on this idea have been listed above. In such a managed network, one technique to recover
implemented and deployed today [IC2011]. However, duplication of RTP from packet loss without incurring unbounded delay is to duplicate
streams without breaking the RTP and RTCP functionality has not been the packets and send them in separate redundant streams. As
documented properly. This document discusses the most common use described later in this document, the probability that two copies of
cases and explains how duplication can be achieved for RTP streams in the same packet are lost in cases of non-congestive packet loss is
such use cases to address the immediate market needs. In the future, quite small.
if there will be a different use case, which is not covered by this
document, a new specification that explains how RTP duplication Variations on this idea have been implemented and deployed today
should be done in such a scenario may be needed. [IC2011]. However, duplication of RTP streams without breaking the
RTP and RTCP functionality has not been documented properly. This
document discusses the most common use cases and explains how
duplication can be achieved for RTP streams in such use cases to
address the immediate market needs. In the future, if there will be
a different use case, which is not covered by this document, a new
specification that explains how RTP duplication should be done in
such a scenario may be needed.
Stream duplication offers a simple way to protect media flows from Stream duplication offers a simple way to protect media flows from
packet loss. It has a comparatively high bandwidth overhead, since packet loss. It has a comparatively high bandwidth overhead, since
everything is sent twice, but with a low processing overhead. It is everything is sent twice, but with a low processing overhead. It is
also very predictable in its overheads. Alternative approaches, for also very predictable in its overheads. Alternative approaches, for
example, retransmission-based recovery [RFC4588] or Forward Error example, retransmission-based recovery [RFC4588] or Forward Error
Correction [RFC6363], may be suitable in some other cases. Correction [RFC6363], may be suitable in some other cases.
2. Terminology and Requirements Notation 2. Terminology and Requirements Notation
skipping to change at page 3, line 49 skipping to change at page 4, line 13
network. network.
It is important to note that dual streaming can easily be extended to It is important to note that dual streaming can easily be extended to
support cases when more than two streams are desired. However, using support cases when more than two streams are desired. However, using
three or more streams is rare in practice, due to the high overhead three or more streams is rare in practice, due to the high overhead
that it incurs and the little additional protection it provides. that it incurs and the little additional protection it provides.
3.1. Temporal Redundancy 3.1. Temporal Redundancy
From a routing perspective, two streams are considered identical if From a routing perspective, two streams are considered identical if
the following two IP header fields are the same, since they will be the following two IP header fields are the same (in addition to the
both routed over the same path: transport ports), since they will be both routed over the same path:
o IP Source Address o IP Source Address
o IP Destination Address o IP Destination Address
Two routing-plane identical RTP streams might carry the same payload, Two routing-plane identical RTP streams might carry the same payload,
but can use different Synchronization Sources (SSRC) to differentiate but can use different Synchronization Sources (SSRC) to differentiate
the RTP packets belonging to each stream. In the context of dual RTP the RTP packets belonging to each stream. In the context of dual RTP
streaming, we assume that the sender duplicates the RTP packets and streaming, we assume that the sender duplicates the RTP packets and
sends them in separate RTP streams, each with a unique SSRC. All the sends them in separate RTP streams, each with a unique SSRC. All the
redundant streams are transmitted in the same RTP session. redundant streams are transmitted in the same RTP session.
For example, one main stream and its duplicate stream can be sent to For example, one main stream and its duplicate stream can be sent to
skipping to change at page 4, line 47 skipping to change at page 5, line 13
join each SSM session separately. join each SSM session separately.
Alternatively, destination host could also have multiple IP addresses Alternatively, destination host could also have multiple IP addresses
for an RTP source to send the redundant streams to. for an RTP source to send the redundant streams to.
3.3. Dual Streaming over a Single Path or Multiple Paths 3.3. Dual Streaming over a Single Path or Multiple Paths
Having described the characteristics of the streams, one can reach Having described the characteristics of the streams, one can reach
the following conclusions: the following conclusions:
1. When two routing-plane identical streams are used, the two 1. When two routing-plane identical streams are used, the flow
streams will have identical IP headers. This makes it labels will be the same. This makes it impractical to forward
impractical to forward the packets onto different paths. In the packets onto different paths. In order to minimize packet
order to minimize packet loss, the packets belonging to one loss, the packets belonging to one stream are often interleaved
stream are often interleaved with packets belonging to its with packets belonging to its duplicate stream, and with a delay,
duplicate stream, and with a delay, so that if there is a packet so that if there is a packet loss, such a delay would allow the
loss, such a delay would allow the same packet from the duplicate same packet from the duplicate stream to reach the receiver
stream to reach the receiver because the chances that the same because the chances that the same packet is lost in transit again
packet is lost in transit again is often small. This is what is is often small. This is what is also known as Time-shifted
also known as Time-shifted Redundancy, Temporal Redundancy or Redundancy, Temporal Redundancy or simply Delayed Duplication
simply Delayed Duplication [I-D.ietf-mmusic-delayed-duplication] [I-D.ietf-mmusic-delayed-duplication] [IC2011]. This approach
[IC2011]. This approach can be used with both types of dual can be used with both types of dual streaming, described in
streaming, described in Section 3.1 and Section 3.2. Section 3.1 and Section 3.2.
2. If the two streams have different IP headers, an additional 2. If the two streams have different IP headers, an additional
opportunity arises in that one is able to build a network, with opportunity arises in that one is able to build a network, with
physically diverse paths, to deliver the two streams concurrently physically diverse paths, to deliver the two streams concurrently
to the intended receivers. This reduces the delay when packet to the intended receivers. This reduces the delay when packet
loss occurs and needs to be recovered. Additionally, it also loss occurs and needs to be recovered. Additionally, it also
further reduces chances for packet loss. An unrecoverable loss further reduces chances for packet loss. An unrecoverable loss
happens only when two network failures happen in such a way that happens only when two network failures happen in such a way that
the same packet is affected on both paths. This is referred to the same packet is affected on both paths. This is referred to
as Spatial Diversity or Spatial Redundancy [IC2011]. The as Spatial Diversity or Spatial Redundancy [IC2011]. The
skipping to change at page 5, line 33 skipping to change at page 5, line 47
this document. this document.
Note that spatial redundancy often offers less delay in Note that spatial redundancy often offers less delay in
recovering from packet loss provided that the forwarding delay of recovering from packet loss provided that the forwarding delay of
the network paths are more or less the same (This is often made the network paths are more or less the same (This is often made
sure through careful network design). For both temporal and sure through careful network design). For both temporal and
spatial redundancy approaches, packet misordering might still spatial redundancy approaches, packet misordering might still
happen and needs to be handled using the sequence numbers of some happen and needs to be handled using the sequence numbers of some
sort (e.g., RTP sequence numbers). sort (e.g., RTP sequence numbers).
Temporal and spatial redundancy deal with different patterns of
packet loss. The former helps with transient loss (within the
duplication window), while the latter helps with longer-term packet
loss that affects only one of the two redundant paths.
To summarize, dual streaming allows an application and a network to To summarize, dual streaming allows an application and a network to
work together to provide a near zero-loss transport with a bounded or work together to provide a near zero-loss transport with a bounded or
minimum delay. The additional advantage includes a predictable minimum delay. The additional advantage includes a predictable
bandwidth overhead that is proportional to the minimum bandwidth bandwidth overhead that is proportional to the minimum bandwidth
needed for the multimedia session, but independent of the number of needed for the multimedia session, but independent of the number of
receivers experiencing a packet loss and requesting a retransmission. receivers experiencing a packet loss and requesting a retransmission.
For a survey and comparison of similar approaches, refer to [IC2011]. For a survey and comparison of similar approaches, refer to [IC2011].
3.4. Requirements 3.4. Requirements
skipping to change at page 6, line 18 skipping to change at page 6, line 38
either "m" line, duplication grouping is not trivial and further either "m" line, duplication grouping is not trivial and further
signaling will be needed, which is left for future standardization. signaling will be needed, which is left for future standardization.
4. Use of RTP and RTCP with Temporal Redundancy 4. Use of RTP and RTCP with Temporal Redundancy
To achieve temporal redundancy, the main and duplicate RTP streams To achieve temporal redundancy, the main and duplicate RTP streams
SHOULD be sent using the sample 5-tuple of transport protocol, source SHOULD be sent using the sample 5-tuple of transport protocol, source
and destination IP addresses, and source and destination transport and destination IP addresses, and source and destination transport
ports. Due to the possible presence of network address and port ports. Due to the possible presence of network address and port
translation (NAPT) devices, load balancers, or other middleboxes, use translation (NAPT) devices, load balancers, or other middleboxes, use
of anything other than an identical 5-tuple might also cause spatial of anything other than an identical 5-tuple and flow label might also
redundancy (which might introduce an additional delay due to the cause spatial redundancy (which might introduce an additional delay
delta between the path delays), and so is NOT RECOMMENDED unless the due to the delta between the path delays), and so is NOT RECOMMENDED
path is known to be free of such middleboxes. unless the path is known to be free of such middleboxes.
Since the main and duplicate RTP streams follow an identical path, Since the main and duplicate RTP streams follow an identical path,
they are part of the same RTP session. Accordingly, the sender MUST they are part of the same RTP session. Accordingly, the sender MUST
choose a different SSRC for the duplicate RTP stream than it chose choose a different SSRC for the duplicate RTP stream than it chose
for the main RTP stream, following the rules in [RFC3550] Section 8. for the main RTP stream, following the rules in [RFC3550] Section 8.
4.1. RTCP Considerations 4.1. RTCP Considerations
If RTCP is being sent for the main RTP stream, then the sender MUST If RTCP is being sent for the main RTP stream, then the sender MUST
also generate RTCP for the duplicate RTP stream. The RTCP for the also generate RTCP for the duplicate RTP stream. The RTCP for the
skipping to change at page 7, line 39 skipping to change at page 8, line 19
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1a@example.com a=ssrc:1000 cname:ch1a@example.com
a=ssrc:1010 cname:ch1a@example.com a=ssrc:1010 cname:ch1a@example.com
a=ssrc-group:DUP 1000 1010 a=ssrc-group:DUP 1000 1010
a=duplication-delay:50 a=duplication-delay:50
a=mid:Ch1 a=mid:Ch1
As specified in Section 3.2 of [RFC7104], it is advisable that the Section 3.2 of [RFC7104] states that it is advisable that the SSRC
SSRC listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is sent
sent first, with the other SSRC (i.e., SSRC of 1010) being the time- first, with the other SSRC (i.e., SSRC of 1010) being the time-
delayed duplicate. This is not critical, however, and a receiving delayed duplicate. This is not critical, however, and a receiving
host should size its playout buffer based on the 'duplication-delay' host should size its playout buffer based on the 'duplication-delay'
attribute, and play the stream that arrives first in preference, with attribute, and play the stream that arrives first in preference, with
the other stream acting as a repair stream, irrespective of the order the other stream acting as a repair stream, irrespective of the order
in which they are signaled. in which they are signaled.
5. Use of RTP and RTCP with Spatial Redundancy 5. Use of RTP and RTCP with Spatial Redundancy
When using spatial redundancy, the duplicate RTP stream is sent using Assuming the network is structured appropriately, when using spatial
a different source and/or destination address/port pair. This will redundancy, the duplicate RTP stream is sent using a different source
be a separate RTP session to the session conveying the main RTP and/or destination address/port pair. This will be a separate RTP
stream. Thus, the SSRCs used for the main and duplicate streams MUST session to the session conveying the main RTP stream. Thus, the
be chosen randomly, following the rules in Section 8 of [RFC3550]. SSRCs used for the main and duplicate streams MUST be chosen
randomly, following the rules in Section 8 of [RFC3550].
Accordingly, they will almost certainly not match each other. The Accordingly, they will almost certainly not match each other. The
sender MUST, however, use the same RTCP CNAME for both the main and sender MUST, however, use the same RTCP CNAME for both the main and
duplicate streams. An "a=group:DUP" line or "a=ssrc-group:DUP" line duplicate streams. An "a=group:DUP" line or "a=ssrc-group:DUP" line
is used to indicate duplication. is used to indicate duplication.
5.1. RTCP Considerations 5.1. RTCP Considerations
If RTCP is being sent for the main RTP stream, then the sender MUST If RTCP is being sent for the main RTP stream, then the sender MUST
also generate RTCP for the duplicate RTP stream. The RTCP for the also generate RTCP for the duplicate RTP stream. The RTCP for the
duplicate RTP stream is generated exactly as-if the duplicate RTP duplicate RTP stream is generated exactly as-if the duplicate RTP
skipping to change at page 9, line 35 skipping to change at page 10, line 5
7. Congestion Control Considerations 7. Congestion Control Considerations
Duplicating RTP streams has several considerations in the context of Duplicating RTP streams has several considerations in the context of
congestion control. First of all, RTP duplication MUST NOT be used congestion control. First of all, RTP duplication MUST NOT be used
in cases where the primary cause of packet loss is congestion since in cases where the primary cause of packet loss is congestion since
duplication can make congestion only worse. Furthermore, RTP duplication can make congestion only worse. Furthermore, RTP
duplication SHOULD NOT be used where there is a risk of congestion duplication SHOULD NOT be used where there is a risk of congestion
upon duplicating an RTP stream. Duplication is RECOMMENDED only to upon duplicating an RTP stream. Duplication is RECOMMENDED only to
be used for protection against network outages due to a temporary be used for protection against network outages due to a temporary
link or network element failure and where it is known that there is link or network element failure and where it is known (e.g., through
sufficient network capacity to carry the duplicated traffic. The explicit operator configuration) that there is sufficient network
capacity requirement constrains the use of duplication to managed capacity to carry the duplicated traffic. The capacity requirement
networks, and makes it unsuitable for use on unmanaged public constrains the use of duplication to managed networks, and makes it
networks. unsuitable for use on unmanaged public networks.
It is essential that the nodes responsible for the duplication and It is essential that the nodes responsible for the duplication and
de-duplication are aware of the original stream's requirements and de-duplication are aware of the original stream's requirements and
the available capacity inside the network. If there is an adaptation the available capacity inside the network. If there is an adaptation
capability for the original stream, these nodes have to assume the capability for the original stream, these nodes have to assume the
same adaptation capability for the duplicated stream, too. For same adaptation capability for the duplicated stream, too. For
example, if the source doubles the bitrate for the original stream, example, if the source doubles the bitrate for the original stream,
the bitrate of the duplicate stream will also be doubled. the bitrate of the duplicate stream will also be doubled.
Depending on where de-duplication takes place, there could be Depending on where de-duplication takes place, there could be
 End of changes. 19 change blocks. 
69 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/