draft-ietf-avtext-rtp-duplication-00.txt   draft-ietf-avtext-rtp-duplication-01.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: January 3, 2013 University of Glasgow Expires: July 3, 2013 University of Glasgow
July 2, 2012 December 30, 2012
Duplicating RTP Streams Duplicating RTP Streams
draft-ietf-avtext-rtp-duplication-00 draft-ietf-avtext-rtp-duplication-01
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 January 3, 2013. This Internet-Draft will expire on July 3, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 4, line 31 skipping to change at page 4, line 31
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 source duplicates the RTP packets and streaming, we assume that the source 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 and one redundant RTP stream can be sent to the For example, one main and one redundant RTP stream can be sent to the
same IP destination address and UDP destination port with a certain same IP destination address and UDP destination port with a certain
delay between them [I-D.begen-mmusic-temporal-interleaving]. The delay between them [I-D.ietf-mmusic-delayed-duplication]. The
streams carry the same payload in their respective RTP packets with streams carry the same payload in their respective RTP packets with
identical sequence numbers. This allows receivers (or other nodes identical sequence numbers. This allows receivers (or other nodes
responsible for gap filling and duplicate suppression) to identify responsible for gap filling and duplicate suppression) to identify
and suppress the duplicate packets, and subsequently produce a and suppress the duplicate packets, and subsequently produce a
hopefully loss-free and duplication-free output stream. This process hopefully loss-free and duplication-free output stream. This process
is called stream merging. is called stream merging.
3.2. Spatial Redundancy 3.2. Spatial Redundancy
An RTP source might be associated with multiple network interfaces, An RTP source might be associated with multiple network interfaces,
skipping to change at page 5, line 25 skipping to change at page 5, line 25
1. When two routing-plane identical streams are used, the two 1. When two routing-plane identical streams are used, the two
streams will have identical IP headers. This makes it streams will have identical IP headers. This makes it
impractical to forward the packets onto different paths. In impractical to forward the packets onto different paths. In
order to minimize packet loss, the packets belonging to one order to minimize packet loss, the packets belonging to one
stream are often interleaved with packets belonging to the other, 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 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 would allow the same packet from the other stream to reach the
receiver because the chances that the same packet is lost in receiver because the chances that the same packet is lost in
transit again is often small. This is what is also known as transit again is often small. This is what is also known as
Time-shifted Redundancy, Temporal Redundancy or simply Delayed Time-shifted Redundancy, Temporal Redundancy or simply Delayed
Duplication [I-D.begen-mmusic-temporal-interleaving] [IC2011]. Duplication [I-D.ietf-mmusic-delayed-duplication] [IC2011]. This
This approach can be used with both types of dual streaming, approach can be used with both types of dual streaming, described
described in Section 3.1 and Section 3.2. in 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 6, line 45 skipping to change at page 6, line 45
reports, will be received. If RTCP is used, receivers MUST generate reports, will be received. If RTCP is used, receivers MUST generate
RTCP reports for both main and redundant streams in the usual way, RTCP reports for both main and redundant streams in the usual way,
treating them as entirely separate media streams. treating them as entirely separate media streams.
4.2. Signaling Considerations 4.2. Signaling Considerations
Signaling is needed to allow the receiver to determine that an RTP Signaling is needed to allow the receiver to determine that an RTP
stream is a redundant copy of another, rather than a separate stream stream is a redundant copy of another, rather than a separate stream
that needs to be rendered in parallel. There are two parts to this: that needs to be rendered in parallel. There are two parts to this:
an SDP extension is needed in the offer/answer exchange to negotiate an SDP extension is needed in the offer/answer exchange to negotiate
support for temporal redundancy; and signalling is needed to indicate support for temporal redundancy; and signaling is needed to indicate
which stream is the duplicate (the latter can be done in-band using which stream is the duplicate (the latter can be done in-band using
an RTCP extension, or out-of-band by signalling the SSRCs used by the an RTCP extension, or out-of-band by signaling the SSRCs used by the
duplicate streams in SDP). duplicate streams in SDP).
We require out-of-band signalling for both features. The required We require out-of-band signaling for both features. The required SDP
SDP attribute to signal duplication in the SDP offer/answer exchange attribute to signal duplication in the SDP offer/answer exchange
('duplication-delay') is defined in ('duplication-delay') is defined in
[I-D.begen-mmusic-temporal-interleaving]. The required SDP grouping [I-D.ietf-mmusic-delayed-duplication]. The required SDP grouping
semantics are defined in [I-D.begen-mmusic-redundancy-grouping]. semantics are defined in [I-D.ietf-mmusic-duplication-grouping].
In the following SDP example, a video stream is duplicated, and the In the following SDP example, a video stream is duplicated, and the
main and redundant streams are transmitted in two separate SSRCs main and redundant streams are transmitted in two separate SSRCs
(1000 and 1010): (1000 and 1010):
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication s=Delayed Duplication
t=0 0 t=0 0
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
skipping to change at page 8, line 29 skipping to change at page 8, line 29
mapping trivial in most cases. mapping trivial in most cases.
Both main and redundant streams, and their corresponding RTCP, will Both main and redundant streams, and their corresponding RTCP, will
be received. If RTCP is used, receivers MUST generate RTCP reports be received. If RTCP is used, receivers MUST generate RTCP reports
for both main and redundant streams in the usual way, treating them for both main and redundant streams in the usual way, treating them
as entirely separate media streams. as entirely separate media streams.
5.2. Signaling Considerations 5.2. Signaling Considerations
The required SDP grouping semantics have been defined in The required SDP grouping semantics have been defined in
[I-D.begen-mmusic-redundancy-grouping]. In the following example, [I-D.ietf-mmusic-duplication-grouping]. In the following example,
the redundant streams have different IP destination addresses. The the redundant streams have different IP destination addresses. The
example shows the same UDP port number and IP source addresses, but example shows the same UDP port number and IP source addresses, but
either or both could have been different for the two streams. either or both could have been different for the two streams.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics s=DUP Grouping Semantics
t=0 0 t=0 0
a=group:DUP S1a S1b a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
skipping to change at page 9, line 33 skipping to change at page 9, line 33
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, plus a combination of both This uses the same RTP/RTCP mechanisms, plus a combination of both
sets of signaling. sets of signaling.
7. Security Considerations 7. Security Considerations
The security considerations of [RFC3550], The security considerations of [RFC3550],
[I-D.begen-mmusic-temporal-interleaving], and [I-D.ietf-mmusic-delayed-duplication], and
[I-D.begen-mmusic-redundancy-grouping] apply. [I-D.ietf-mmusic-duplication-grouping] apply.
If stream de-duplication is done by an in-network middlebox, rather If stream de-duplication is done by an in-network middlebox, rather
than by an end system, that middlebox can work if Secure RTP (SRTP) than by an end system, that middlebox can work if Secure RTP (SRTP)
encryption is used [RFC3711], since the RTP headers are in the clear. encryption is used [RFC3711], since the RTP headers are in the clear.
Doing so would break the authentication when the SSRC is rewritten, Doing so would break the authentication when the SSRC is rewritten,
unless the de-duplication middlebox were trusted to re-authenticate unless the de-duplication middlebox were trusted to re-authenticate
the packets. This would require additional signalling which is not the packets. This would require additional signaling which is not
specified here, since de-duplication in the receiver end system is specified here, since de-duplication in the receiver end system is
expected to be the more common use case. expected to be the more common use case.
8. IANA Considerations 8. IANA Considerations
No IANA actions are required. No IANA actions are required.
9. Acknowledgments 9. Acknowledgments
Thanks to Magnus Westerlund for his suggestions. Thanks to Magnus Westerlund for his suggestions.
skipping to change at page 10, line 20 skipping to change at page 10, line 20
10.1. Normative References 10.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.begen-mmusic-temporal-interleaving] [I-D.ietf-mmusic-delayed-duplication]
Begen, A., Cai, Y., and H. Ou, "Delayed Duplication Begen, A., Cai, Y., and H. Ou, "Delayed Duplication
Attribute in the Session Description Protocol", Attribute in the Session Description Protocol",
draft-begen-mmusic-temporal-interleaving-04 (work in draft-ietf-mmusic-delayed-duplication-00 (work in
progress), March 2012. progress), October 2012.
[I-D.begen-mmusic-redundancy-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", Semantics in the Session Description Protocol",
draft-begen-mmusic-redundancy-grouping-03 (work in draft-ietf-mmusic-duplication-grouping-00 (work in
progress), March 2012. progress), October 2012.
[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 10.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.
 End of changes. 16 change blocks. 
24 lines changed or deleted 24 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/