draft-ietf-avtext-rtp-duplication-03.txt   draft-ietf-avtext-rtp-duplication-04.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: March 24, 2014 University of Glasgow Expires: April 05, 2014 University of Glasgow
September 20, 2013 October 02, 2013
Duplicating RTP Streams Duplicating RTP Streams
draft-ietf-avtext-rtp-duplication-03 draft-ietf-avtext-rtp-duplication-04
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 congestion, or other unplanned network outages. This is
especially true for IP multicast networks, where packet loss patterns especially true for IP multicast networks, where packet loss patterns
can vary greatly between receivers. One technique that can be used can vary greatly between receivers. One technique that can be used
to recover from packet loss without incurring unbounded delay for all to recover from packet loss without incurring unbounded delay for all
the receivers is to duplicate the packets and send them in separate the receivers is to duplicate the packets and send them in separate
redundant streams. This document explains how Real-time Transport redundant streams. This document explains how Real-time Transport
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 March 24, 2014. This Internet-Draft will expire on April 05, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . 3
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 . . . 4
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 5 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
4. Use of RTP and RTCP with Temporal Redundancy . . . . . . . . 6
4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6 4.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 6
4.2. Signaling Considerations . . . . . . . . . . . . . . . . 6 4.2. Signaling Considerations . . . . . . . . . . . . . . . . 6
5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 7 5. Use of RTP and RTCP with Spatial Redundancy . . . . . . . . . 8
5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 7 5.1. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8
5.2. Signaling Considerations . . . . . . . . . . . . . . . . 8 5.2. Signaling Considerations . . . . . . . . . . . . . . . . 8
6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 8 6. Use of RTP and RTCP with Temporal and Spatial Redundancy . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Congestion Control Considerations . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11
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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
person accidentally cutting the wrong fiber. Since UDP/IP flows do person accidentally cutting the wrong fiber. Since UDP/IP flows do
not provide any means for detecting loss and retransmitting packets, not provide any means for detecting loss and retransmitting packets,
it leaves up to the RTP layer and the applications to detect, and it leaves up to the RTP 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 One technique to recover from packet loss without incurring unbounded
delay for all the receivers is to duplicate the packets and send them delay for all the receivers is to duplicate the packets and send them
in separate redundant streams. Variations on this idea have been in separate redundant streams. Variations on this idea have been
implemented and deployed today [IC2011]. However, duplication of RTP implemented and deployed today [IC2011]. However, duplication of RTP
streams without breaking the RTP and RTCP functionality has not been streams without breaking the RTP and RTCP functionality has not been
documented properly. This document explains how duplication can be documented properly. This document discusses the most common use
achieved for RTP streams. 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 may also very predictable in its overheads. Alternative approaches, for
be suitable in some cases, for example retransmission-based recovery example, retransmission-based recovery [RFC4588] or Forward Error
[RFC4588] or Forward Error Correction [RFC6363]. Correction [RFC6363], may be suitable in some other cases.
2. Terminology and Requirements Notation 2. Terminology and Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Dual Streaming Use Cases 3. Dual Streaming Use Cases
skipping to change at page 3, line 40 skipping to change at page 3, line 44
redundant RTP streams (the original plus its duplicate) of the same redundant RTP streams (the original plus its duplicate) of the same
content, with each stream capable of supporting the playback when content, with each stream capable of supporting the playback when
there is no packet loss. Therefore, adding an additional RTP stream there is no packet loss. Therefore, adding an additional RTP stream
provides a protection against packet loss. The level of protection provides a protection against packet loss. The level of protection
depends on how the packets are sent and transmitted inside the depends on how the packets are sent and transmitted inside the
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. 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, since they will be
both routed over the same path: 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
the same IP destination address and UDP destination port with a the same IP destination address and UDP destination port with a
certain delay between them [I-D.ietf-mmusic-delayed-duplication]. certain delay between them [I-D.ietf-mmusic-delayed-duplication].
skipping to change at page 5, line 39 skipping to change at page 5, line 41
sort (e.g., RTP sequence numbers). sort (e.g., RTP sequence numbers).
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
One of the following conditions is REQUIRED to hold in applications
using this specification:
o The original and duplicate RTP streams are carried (with their own
SSRCs) in the same "m" line (There could be other RTP streams
listed in the same "m" line)
o The original and duplicate RTP streams are carried in separate "m"
lines and there is no other RTP stream listed in either "m" line.
When the original and duplicate RTP streams are carried in separate
"m" lines in an SDP description and if the SDP description has one or
more other RTP streams listed in either "m" line, duplication
grouping is not trivial and further 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 might also cause spatial
redundancy (which might introduce an additional delay due to the redundancy (which might introduce an additional delay due to the
delta between the path delays), and so is NOT RECOMMENDED unless the delta between the path delays), and so is NOT RECOMMENDED unless the
skipping to change at page 8, line 46 skipping to change at page 9, line 21
c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000 a=rtpmap:101 MP2T/90000
a=mid:S1b a=mid:S1b
6. Use of RTP and RTCP with Temporal and Spatial Redundancy 6. Use of RTP and RTCP with Temporal and Spatial Redundancy
This uses the same RTP/RTCP mechanisms from Sections Section 4 and This uses the same RTP/RTCP mechanisms from Sections Section 4 and
Section 5, plus a combination of both sets of signaling. Section 5, plus a combination of both sets of signaling.
7. Security Considerations 7. Congestion Control Considerations
Duplicating RTP streams has several considerations in the context of
congestion control. First of all, RTP duplication MUST NOT be used
in cases where the primary cause of packet loss is congestion since
duplication can make congestion only worse. Furthermore, RTP
duplication SHOULD NOT be used where there is a risk of congestion
upon duplicating an RTP stream. Duplication is RECOMMENDED only to
be used for protection against network outages due to a temporary
link or network element failure and where it is known that there is
sufficient network capacity to carry the duplicated traffic. The
capacity requirement constrains the use of duplication to managed
networks, and makes it unsuitable for use on unmanaged public
networks.
It is essential that the nodes responsible for the duplication and
de-duplication are aware of the original stream's requirements and
the available capacity inside the network. If there is an adaptation
capability for the original stream, these nodes have to assume the
same adaptation capability for the duplicated stream, too. For
example, if the source doubles the bitrate for the original stream,
the bitrate of the duplicate stream will also be doubled.
Depending on where de-duplication takes place, there could be
different scenarios. When the duplication and de-duplication takes
place inside the network before the ultimate end-points that will
consume the RTP media, the whole process is transparent to these end-
points. Thus, these end-points will apply any congestion control, if
applicable, on the de-duplicated RTP stream. This output stream will
have less losses than either of the original and duplicated stream,
and the end-point will make congestion control decisions accordingly.
However, if de-duplication takes place at the ultimate end-point,
this end-point MUST consider the aggregate of the original and
duplicated RTP stream in any congestion control it wants to apply.
The end-point will observe the losses in each stream separately, and
this information can be used to fine-tune the duplication process.
For example, the duplication interval can be adjusted based on the
duration of a common packet loss in both streams.
8. Security Considerations
The security considerations of [RFC3550], The security considerations of [RFC3550],
[I-D.ietf-mmusic-delayed-duplication], and [I-D.ietf-mmusic-delayed-duplication],
[I-D.ietf-mmusic-duplication-grouping] apply. [I-D.ietf-mmusic-duplication-grouping], and any RTP profiles and
payload formats in use apply.
Duplication can be performed end-to-end, with the media sender
generating a duplicate RTP stream, and the receiver(s) performing de-
duplication. In such cases, if the original media stream is to be
authenticated (e.g., using SRTP [RFC3711]) then the duplicate stream
also needs to be authenticated, and duplicate packets that fail the
authentication check need to be discarded.
Stream duplication and de-duplication can also be performed by in-
network middleboxes. Such middleboxes will need to rewrite the RTP
SSRC such that the RTP packets in the duplicate stream have a
different SSRC to the original stream, and will need to generate and
respond to RTCP packets corresponding to the duplicate stream. This
sort of in-network duplication service has the potential to act as an
amplifier for denial-of-service attacks if the attacker can cause
attack traffic to be duplicated. To prevent this, middleboxes
providing the duplication service need to authenticate the traffic to
be duplicated as being from a legitimate source, for example using
the secure RTP (SRTP) profile [RFC3711]. This requires the middlebox
to be part of the security context of the media session being
duplicated, so it has access to the necessary keying material for
authentication. To do this, the middlebox will need to be privy to
the session set-up signalling. Details of how that is done will
depend on the type of signalling used (SIP, RTSP, WebRTC, etc.), and
is not specified here.
Similarly, to prevent packet injection attacks, a de-duplication
middlebox needs to authenticate original and duplicate streams, and
ought not use non-authenticated packets that are received. Again,
this requires the middlebox to be part of the security context, and
have access to the appropriate signalling and keying material.
Stream de-duplication can be done by an in-network middlebox,
rewriting the SSRC as appropriate. If the Secure RTP (SRTP) profile
[RFC3711] is used to authenticate RTP packets, such rewriting is not
possible without breaking the authentication, unless the de-
duplication middlebox is trusted to re-authenticate the packets.
This would require additional signaling that is not specified here.
The use of the encryption features of SRTP does not affect stream de- The use of the encryption features of SRTP does not affect stream de-
duplication middleboxes, since the RTP headers are sent in the clear. duplication middleboxes, since the RTP headers are sent in the clear.
8. IANA Considerations 9. IANA Considerations
No IANA actions are required. No IANA actions are required.
9. Acknowledgments 10. Acknowledgments
Thanks to Magnus Westerlund for his suggestions. Thanks to Magnus Westerlund for his suggestions.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-mmusic-delayed-duplication] [I-D.ietf-mmusic-delayed-duplication]
Begen, A., Cai, Y., and H. Ou, "Delayed Duplication Begen, A., Cai, Y., and H. Ou, "Delayed Duplication
skipping to change at page 9, line 49 skipping to change at page 11, line 43
[I-D.ietf-mmusic-duplication-grouping] [I-D.ietf-mmusic-duplication-grouping]
Begen, A., Cai, Y., and H. Ou, "Duplication Grouping Begen, A., Cai, Y., and H. Ou, "Duplication Grouping
Semantics in the Session Description Protocol", draft- Semantics in the Session Description Protocol", draft-
ietf-mmusic-duplication-grouping-03 (work in progress), ietf-mmusic-duplication-grouping-03 (work in progress),
July 2013. July 2013.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
10.2. Informative References 11.2. Informative References
[RFC2354] Perkins, C. and O. Hodson, "Options for Repair of [RFC2354] Perkins, C. and O. Hodson, "Options for Repair of
Streaming Media", RFC 2354, June 1998. Streaming Media", RFC 2354, June 1998.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, October 2011. Correction (FEC) Framework", RFC 6363, October 2011.
skipping to change at line 457 skipping to change at page 12, line 29
Email: abegen@cisco.com Email: abegen@cisco.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
UK UK
Email: csp@csperkins.org Email: csp@csperkins.org
URI: http://orcid.org/0000-0002-3404-8964
 End of changes. 21 change blocks. 
36 lines changed or deleted 125 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/