One document matched: draft-begen-mmusic-redundancy-grouping-02.txt
Differences from draft-begen-mmusic-redundancy-grouping-01.txt
MMUSIC A. Begen
Internet-Draft Y. Cai
Intended status: Standards Track H. Ou
Expires: April 12, 2012 Cisco
October 10, 2011
Duplication Grouping Semantics in the Session Description Protocol
draft-begen-mmusic-redundancy-grouping-02
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 defines the semantics
for grouping redundant streams in the Session Description Protocol
(SDP). The semantics defined in this document are to be used with
the SDP Grouping Framework [RFC5888]. SSRC-level (Synchronization
Source) grouping semantics are also defined in this document for RTP
streams using SSRC multiplexing.
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 12, 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
Begen, et al. Expires April 12, 2012 [Page 1]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
(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
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 . . . . . . . . . . . . . . . . . . . . 3
3. Dual Streaming . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. (Routing-Plane) Identical Streams . . . . . . . . . . . . 4
3.2. Using Separate Source Interfaces . . . . . . . . . . . . . 5
3.3. Using Separate Destination Addresses and/or Ports . . . . 5
3.4. Dual Streaming over a Single Path or Multiple Paths . . . 5
4. Duplication Grouping . . . . . . . . . . . . . . . . . . . . . 6
4.1. "DUP" Grouping Semantics . . . . . . . . . . . . . . . . . 6
4.2. DUP Grouping for SSRC-Multiplexed RTP Streams . . . . . . 7
4.3. SDP Offer/Answer Model Considerations . . . . . . . . . . 7
5. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Separate Source Interfaces . . . . . . . . . . . . . . . . 8
5.2. Separate Destination Addresses . . . . . . . . . . . . . . 8
5.3. Delayed Duplication . . . . . . . . . . . . . . . . . . . 9
6. Performance Evaluation and Reporting . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Begen, et al. Expires April 12, 2012 [Page 2]
Internet-Draft Duplication Grouping Semantics in SDP 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].
In this document, we describe a technique that involves transmitting
redundant streams to overcome packet loss. Variations of this
technique have already been implemented and deployed today [IC2011].
We also describe the semantics needed in the Session Description
Protocol (SDP) [RFC4566] to support this technique.
A work-in-progress draft specification [I-D.singh-avtcore-mprtp]
proposes changes to the RTP protocol so that a single RTP session can
benefit from using multiple paths between two endpoints (to increase
the aggregated throughput and improve reliability). While we also
discuss spatial diversity in this document, we use diverse paths
solely for sending redundant streams. For our purposes, we do not
require changes in the RTP protocol.
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. Dual Streaming
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.
Begen, et al. Expires April 12, 2012 [Page 3]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
It is important to note that the technique and specification
described by this document 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.
3.1. (Routing-Plane) Identical Streams
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).
In such a scenario (where the RTP streams are routing-plane identical
and share the same UDP destination port), there will be only one "m"
line in the SDP description regardless of how many redundant streams
are generated. Thus, the SDP Grouping Framework [RFC5888] cannot be
used to indicate the grouping for the redundant streams. Instead,
the 'ssrc-group' attribute [RFC5576] with new semantics has to be
used to describe the redundancy relation (See Section 4.2).
If the two routing-plane identical RTP streams were sent to different
UDP destination ports, there would have been two "m" lines in the SDP
description and in this case, the 'group' attribute [RFC5888] with
new semantics would have to be used to describe the redundancy
relation (See Section 4.1).
Begen, et al. Expires April 12, 2012 [Page 4]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
3.2. 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 via Internet Group Management Protocol (IGMP)
version 3 [RFC3376] or the Multicast Listener Discovery Protocol
(MLD) version 2 [RFC3810]. Note that despite being transmitted in
separate SSM sessions, there is still only one RTP session and the
redundant streams still have to use unique SSRC identifiers.
3.3. Using Separate Destination Addresses and/or Ports
An RTP source might send the redundant streams to separate IP
destination addresses and/or UDP ports. In this case, there will be
multiple "m" lines in the SDP description and the 'group' attribute
[RFC5888] with new semantics will be used to describe the redundancy
relation.
3.4. 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 and Section 3.3.
Begen, et al. Expires April 12, 2012 [Page 5]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
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.
For a survey and comparison of similar approaches, refer to [IC2011].
4. Duplication Grouping
4.1. "DUP" Grouping Semantics
Each "a=group" line is used to indicate an association relationship
between the redundant streams. The streams included in one "a=group"
line are called a Duplication Group.
Using the framework in [RFC5888], this document defines "DUP" as the
grouping semantics for redundant streams.
The "a=group:DUP" semantics MUST be used to group the redundant
streams except when the streams are specified in the same media
description, i.e., in the same "m" line (See Section 4.2).
The SSRC identifiers for the RTP streams that are carried in the same
RTP session MUST be unique per [RFC3550]. Thus, each redundant RTP
stream MUST have its own unique SSRC identifier. This way, dual
streaming does not break RTCP reporting. When the redundant streams
are described in separate "m" lines and the 'group' attribute is used
to describe the redundancy relation, the SSRCs for each redundant
Begen, et al. Expires April 12, 2012 [Page 6]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
stream MUST be announced in the SDP description using the 'ssrc'
attribute [RFC5576].
4.2. DUP Grouping for SSRC-Multiplexed RTP Streams
[RFC5576] defines an SDP media-level attribute, called 'ssrc-group',
for grouping the RTP streams that are SSRC multiplexed and carried in
the same RTP session. The grouping is based on the SSRC identifiers.
Since SSRC-multiplexed RTP streams are defined in the same "m" line,
the 'group' attribute cannot be used.
This section specifies how duplication is used with SSRC-multiplexed
streams using the 'ssrc-group' attribute [RFC5576].
The semantics of "DUP" for the 'ssrc-group' attribute are the same as
the one defined for the 'group' attribute except that the SSRC
identifiers are used to designate the duplication grouping
associations: a=ssrc-group:DUP *(SP ssrc-id) [RFC5576].
4.3. SDP Offer/Answer Model Considerations
When offering duplication grouping using SDP in an Offer/Answer model
[RFC3264], the following considerations apply.
A node that is receiving an offer from a sender may or may not
understand line grouping. It is also possible that the node
understands line grouping but it does not understand the "DUP"
semantics. From the viewpoint of the sender of the offer, these
cases are indistinguishable.
When a node is offered a session with the "DUP" grouping semantics
but it does not support line grouping or the duplication grouping
semantics, as per [RFC5888], the node responds to the offer either
(1) with an answer that ignores the grouping attribute or (2) with a
refusal to the request (e.g., 488 Not Acceptable Here or 606 Not
Acceptable in SIP).
In the first case, the original sender of the offer must send a new
offer without any duplication grouping. In the second case, if the
sender of the offer still wishes to establish the session, it should
retry the request with an offer without the duplication grouping.
This behavior is specified in [RFC5888].
5. SDP Examples
Begen, et al. Expires April 12, 2012 [Page 7]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
5.1. Separate Source Interfaces
In this example, the redundant streams use the same IP destination
address (232.252.0.1) but they are sourced from different addresses
(198.51.100.1 and 198.51.100.2). Thus, the receiving host needs to
join both SSM sessions separately.
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
m=video 30000 RTP/AVP 100
c=IN IP4 232.252.0.1/127
a=source-filter:incl IN IP4 232.252.0.1 198.51.100.1 198.51.100.2
a=rtpmap:100 MP2T/90000
a=ssrc:1000 cname:ch1@example.com
a=ssrc:1010 cname:ch1@example.com
a=ssrc-group:DUP 1000 1010
a=mid:Group1
Note that in actual use, SSRC values, which are random 32-bit
numbers, can be much larger than the ones shown in this example.
5.2. Separate Destination Addresses
In this example, the redundant streams have different IP destination
addresses. The example shows the same UDP port number and IP source
addresses, but either or both could have been different for the two
streams.
Begen, et al. Expires April 12, 2012 [Page 8]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
m=video 30000 RTP/AVP 100
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=ssrc:1000 cname:ch1@example.com
a=mid:S1a
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:101 MP2T/90000
a=ssrc:1010 cname:ch1@example.com
a=mid:S1b
Editor's note: What if there are multiple streams per "m" line but
grouping has to take place across "m" lines? Could we implicitly use
the CNAMEs to infer the redundancy relation (note that 'ssrc-group'
attribute is media-level only)?
5.3. Delayed Duplication
In this example, the redundant streams have the same IP source and
destination addresses but different UDP port numbers. Due to the
same source and destination addresses, the packets in both streams
will be routed over the same path. To provide resiliency against
packet loss, the duplicate of an original packet is transmitted 50 ms
later as indicated by the 'duplication-delay' attribute (defined in
[I-D.begen-mmusic-temporal-interleaving]).
Begen, et al. Expires April 12, 2012 [Page 9]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
v=0
o=ali 1122334455 1122334466 IN IP4 dup.example.com
s=DUP Grouping Semantics
t=0 0
a=group:DUP S1a S1b
a=duplication-delay:50
m=video 30000 RTP/AVP 100
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=ssrc:1000 cname:ch1@example.com
a=mid:S1a
m=video 40000 RTP/AVP 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:101 MP2T/90000
a=ssrc:1010 cname:ch1@example.com
a=mid:S1b
6. Performance Evaluation and Reporting
Each duplicated stream has a separate (unique) SSRC identifier.
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. This is TBD.
7. Security Considerations
There is a weak threat for the receiver that the duplication grouping
can be modified to indicate relationships that do not exist. Such
attacks might result in failure of the duplication mechanisms, and/or
mishandling of the media streams by the receivers.
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 the 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.
Begen, et al. Expires April 12, 2012 [Page 10]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
8. IANA Considerations
This document registers the following semantics with IANA in
Semantics for the 'group' SDP Attribute under SDP Parameters:
Note to the RFC Editor: In the following registrations, please
replace "XXXX" with the number of this document prior to publication
as an RFC.
Semantics Token Reference
------------------------------------- ------ ---------
Duplication DUP [RFCXXXX]
This document also registers the following semantics with IANA in
Semantics for the 'ssrc-group' SDP Attribute under SDP Parameters:
Token Semantics Reference
------- ----------------------------- ---------
DUP Duplication [RFCXXXX]
9. Acknowledgments
The authors would like to thank Colin Perkins, Bill Ver Steeg, Dave
Oran and Toerless Eckert for their inputs and suggestions.
10. References
10.1. Normative References
[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-02 (work in
progress), June 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
Begen, et al. Expires April 12, 2012 [Page 11]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
3", RFC 3376, October 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
10.2. Informative References
[I-D.singh-avtcore-mprtp]
Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L.
Eggert, "Multipath RTP (MPRTP)",
draft-singh-avtcore-mprtp-02 (work in progress),
July 2011.
[IC2011] Evans, J., Begen, A., Greengrass, J., and C. Filsfils,
"Toward Lossless Video Transport (to appear in IEEE
Internet Computing)", November 2011.
[RFC2354] Perkins, C. and O. Hodson, "Options for Repair of
Streaming Media", RFC 2354, June 1998.
[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.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[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
Begen, et al. Expires April 12, 2012 [Page 12]
Internet-Draft Duplication Grouping Semantics in SDP October 2011
Specification", RFC 5751, January 2010.
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 April 12, 2012 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 04:30:11 |