One document matched: draft-begen-mmusic-temporal-interleaving-02.txt
Differences from draft-begen-mmusic-temporal-interleaving-01.txt
MMUSIC A. Begen
Internet-Draft Y. Cai
Intended status: Standards Track H. Ou
Expires: December 14, 2011 Cisco
June 12, 2011
Delayed Duplication Attribute in the Session Description Protocol
draft-begen-mmusic-temporal-interleaving-02
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 Time-shifted Redundancy, Temporal Redundancy or simply Delayed
Duplication. This document defines an attribute to indicate the
presence of temporally redundant media streams and the duplication
delay 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 December 14, 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 December 14, 2011 [Page 1]
Internet-Draft Delayed Duplication Attribute in SDP June 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 'duplication-delay' Attribute . . . . . . . . . . . . . . . 4
4. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Performance Evaluation and Reporting . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Registration of SDP Attributes . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Begen, et al. Expires December 14, 2011 [Page 2]
Internet-Draft Delayed Duplication Attribute in SDP June 2011
1. Introduction
Consider that a media sender transmits an original source packet and
transmits its duplicate after a certain delay 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 packets and
discard them appropriately, producing a duplicate-free stream.
Delayed duplication can be used in a variety of multimedia
applications where there is sufficient bandwidth for the duplicated
traffic and the application can tolerate the introduced delay. 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]), delayed duplication 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]. In non-RTP applications, the receiver
can use unique sequence numbers if available or other 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 duplication delay. We are not concerned about
how the receiver can suppress the duplicate packets and merge the
incoming streams to produce a hopefully loss-free and duplication-
free output stream (called stream merging), either. These
considerations are out of the scope for this specification. Rather,
we introduce a new attribute for the Session Description Protocol
(SDP) [RFC4566] that indicates that the media stream is to be
duplicated and sent two or more times, and also indicates the
relative delay for each additional duplication.
In practice, more than two redundant streams 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.
While the primary focus in this specification is the RTP-based
transport, the new attribute is applicable to both RTP and non-RTP
Begen, et al. Expires December 14, 2011 [Page 3]
Internet-Draft Delayed Duplication Attribute in SDP June 2011
streams.
2. 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. The 'duplication-delay' Attribute
The following ABNF [RFC5234] syntax formally describes the
'duplication-delay' attribute:
delaying-attribute = "a=duplication-delay:" periods CRLF
periods = period *( ":" period)
period = 1*DIGIT ; in milliseconds
Figure 1: ABNF syntax for the 'interleaving-period' attribute
The 'duplication-delay' attribute is defined as both a media-level
and session-level attribute. It specifies the relative delay for
each duplication in milliseconds (ms). If used as a media-level
attribute, it MUST be used with the 'ssrc-group' attribute and "DUP"
grouping semantics as defined in
[I-D.begen-mmusic-redundancy-grouping]. If used as a session-level
attribute, it MUST be used with 'group' attribute and "DUP" grouping
semantics as defined in [I-D.begen-mmusic-redundancy-grouping].
4. SDP Examples
In the first example below, the multicast stream is duplicated with a
duplication delay of 100 ms. The streams have Synchronization
Sources (SSRC) of 1000 and 1010, and they are grouped together using
the 'ssrc-group' attribute defined in [RFC5576]. The "DUP" grouping
semantics is defined in [I-D.begen-mmusic-redundancy-grouping]. The
reason for using explicit grouping is that not all the media streams
in the same "m" line are necessarily duplicates of each other.
Begen, et al. Expires December 14, 2011 [Page 4]
Internet-Draft Delayed Duplication Attribute in SDP June 2011
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100 101
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=rtpmap:101 MP2T/90000
a=ssrc:1000 cname:ch1@example.com
a=ssrc:1010 cname:ch1@example.com
a=ssrc-group:DUP 1000 1010
a=duplication-delay:100
a=mid:Group1
Note that in actual use, SSRC values, which are random 32-bit
numbers, could be much larger than the ones shown in this example.
Also, note that before receiving an RTP packet for each stream, the
receiver cannot know which SSRC identifier is associated with which
payload type.
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.
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
m=video 30000 RTP/AVP 100 101 102
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=rtpmap:101 MP2T/90000
a=rtpmap:102 MP2T/90000
a=ssrc:1000 cname:ch1@example.com
a=ssrc:1010 cname:ch1@example.com
a=ssrc:1020 cname:ch1@example.com
a=ssrc-group:DUP 1000 1010 1020
a=duplication-delay:50:100
a=mid:Group1
In the third example below, the multicast UDP stream is duplicated
Begen, et al. Expires December 14, 2011 [Page 5]
Internet-Draft Delayed Duplication Attribute in SDP June 2011
with a duplication delay of 50 ms. Both redundant streams are sent
in the same source-specific multicast (SSM) session but they are sent
to different ports. The "DUP" grouping semantics
[I-D.begen-mmusic-redundancy-grouping] is used to describe the
redundany relation.
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=Delayed Duplication
t=0 0
a=group:DUP S1a S1b
a=duplication-delay:50
m=audio 30000 udp mp4
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=mid:S1a
m=audio 40000 udp mp4
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=mid:S1b
Editor's note: Verify the validity of the SDP description above.
5. Performance Evaluation and Reporting
Each duplicated stream has a separate (unique) SSRC identifier
[I-D.begen-mmusic-redundancy-grouping]. Thus, individual RTCP
receiver reports can be sent as usual for each of them from the
receiving node that suppresses the duplicate packets. This way, the
sender can be notified about the delivery performance of the
individual 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.
6. Security Considerations
The 'duplication-delay' 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 duplication delays and/or the number of redundant streams.
For example, if the malevolent third party increases the value of the
duplication delay, the receiver(s) will unnecessarily incur a longer
delay since they will have to wait for the entire period. Or, if the
Begen, et al. Expires December 14, 2011 [Page 6]
Internet-Draft Delayed Duplication Attribute in SDP June 2011
duplication delay 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.
7. IANA Considerations
The following contact information shall be used for all registrations
in this document:
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: duplication-delay
Long form: Duplication delay for temporally redundant
streams
Type of name: att-field
Type of attribute: Media or session level
Subject to charset: No
Purpose: Specifies the relative duplication delay(s) for
redundant stream(s)
Reference: [RFCXXXX]
Values: See [RFCXXXX]
Begen, et al. Expires December 14, 2011 [Page 7]
Internet-Draft Delayed Duplication Attribute in SDP June 2011
8. Acknowledgements
Authors would like to thank Colin Perkins for his suggestions and
review.
9. References
9.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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
[I-D.begen-mmusic-redundancy-grouping]
Begen, A., Cai, Y., and H. Ou, "Redundancy Grouping
Semantics in the Session Description Protocol",
draft-begen-mmusic-redundancy-grouping-00 (work in
progress), March 2011.
9.2. Informative References
[I-D.ietf-fecframe-framework]
Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework",
draft-ietf-fecframe-framework-15 (work in progress),
June 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
Begen, et al. Expires December 14, 2011 [Page 8]
Internet-Draft Delayed Duplication Attribute in SDP June 2011
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
Heidi Ou
Cisco
170 W. Tasman Dr.
San Jose, CA 95134
USA
Email: hou@cisco.com
Begen, et al. Expires December 14, 2011 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 06:17:46 |