Network Working Group G. Babonneau
Internet-Draft X. Marjou
Intended status: Standards Track E. Stephan
Expires: January 6, 2011 France Telecom Orange
july 5, 2010
SSRC Multiplexing for Unicast and Multicast RTP Sessions
draft-babonneau-avt-ssrc-mux-for-port-mapping-00
Abstract
[RFC4588] documents two methods to multiplex RTP sessions: session-
multiplexing and SSRC-multiplexing. This document specifies the
SSRC-multiplexing for RTP sessions.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 January 6, 2011.
Copyright Notice
Copyright (c) 2010 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
Babonneau, et al. Expires January 6, 2011 [Page 1]
Internet-Draft SSRC Multiplexing july 2010
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Babonneau, et al. Expires January 6, 2011 [Page 2]
Internet-Draft SSRC Multiplexing july 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. SSRC multiplexing . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SSRC-multiplexing for RET . . . . . . . . . . . . . . . . . 6
4.2. SSRC-multiplexing for RAMS . . . . . . . . . . . . . . . . 7
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Babonneau, et al. Expires January 6, 2011 [Page 3]
Internet-Draft SSRC Multiplexing july 2010
1. Introduction
[RFC4588] documents two methods to multiplex RTP sessions: Session-
multiplexing and SSRC-multiplexing.
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] and
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] currently specify the use of
the first method: sessions multiplexing. This document specifies the
second method: SSRC multiplexing method. The main motivation being
the acceleration of real time services like fast retransmission (RET)
and rapid multicast source acquisition (RAMS) in presence of NAT.
Section 1 develops the motivation. Section 2 specifies the SSRC
multiplexing for RET and RAMS. Section 3 discusses the solution.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119
[RFC2119].
The following terms are given to avoid misunderstanding between
[I-D.ietf-avt-ports-for-ucast-mcast-rtp], [RFC4588] and [RFC5760]
Terminology.
session-multiplexing: [RFC4588]specifies Session-multiplexing as a
scheme by which the original stream and the associated retransmission
stream are sent into two different RTP sessions.
SSRC-multiplexing: [RFC4588]specifies SSRC-multiplexing as a scheme
by which the original stream and the retransmission stream are sent
in the same RTP session with different SSRC values.
source1: The initial source (e.g. multicast source) of content is
named 'source1' in this document. source1 is sometime named 'Media
sender'.
source2: The additional source (e.g. RAMS and RET server) of content
to multiplex with the initial source is named 'source2' in this
document. Source2 is sometime named 'Distribution Source'.
Retransmission (RET): [RFC4588] specifies Retransmission request as a
means by which an RTP receiver is able to request the retransmission
of the original packet. Usually, an RTCP FB NACK packet as specified
in[RFC4588]is used as retransmission request for lost packets.
Rapid multicast source acquisition (RAMS):
Babonneau, et al. Expires January 6, 2011 [Page 4]
Internet-Draft SSRC Multiplexing july 2010
[I-D.ietf-avt-rapid-acquisition-for-rtp]specifies the RTCP FB RAMS
request based on [RFC4588] is used to request for the burst of
packets of the new channel.
3. Motivation
The delay to switch from one TV channel to another is much longer on
IP multicast than on broadcast network because on IP networks the
receiver does not receive all the channels simultaneously. The loss
of IP packets multicasted over IP networks decreases the quality of
the video received because it introduces blockyness.
RAMS [draft-ietf-avt-rapid-acquisition-for-rtp-10] defines a method
that reduces the acquisition delay when a receiver switch among
different multicast session, such as video broadcasts. RET [RFC4588]
defines an RTP retransmission method that repairs packet losses
between an RTP sender and a receiver.
SSRC multiplexing is part of this effort. The motivation for this
draft is to specify a method that reduces the number of packets
exchanged and the processing time to improve and guarantee RAMS and
RET performance.
Briefly saying, SSRC multiplexing is based on the sharing of the same
transport parameters by a request/response procedure like RET or
RAMS, each direction having its own SSRC identifier: The RTCP request
initiates the NAT binding for downloading the RTP content. As the 2
directions share the NAT binding there is not port mapping need.
Per design RET and RAMS must improve the QoE of the multicast video
session considered. The usage of RET must reduce the blockyness.
The usage of RAMS must reduce the zapping duration. Both rely on the
ability of the server 'source2' to send the data requested in real
time over RTP. Delaying the response must be avoided because it
reduces the improvement of the QoE intrinsically expected.
Additional processing must be avoided because it introduces non
deterministic delay which may jeopardize the initial objective.
SSRC-multiplexing reduces the processing duration in the server and
in the terminal. It reduces the processing in the server. It
reduces the processing and simplifies the logic in the terminal: the
response arrives naturally on the port which sent the request.
Furthermore, the real time request/response approach of the SSRC-
multiplexing guarantees the aliveness of the NAT binding.
Babonneau, et al. Expires January 6, 2011 [Page 5]
Internet-Draft SSRC Multiplexing july 2010
4. SSRC multiplexing
This section specifies SSRC-multiplexing for RET and RAMS. According
to [RFC4588], when ssrc-multiplexed is selected, each RTP session has
its own SSRC, so that RTCP messages can distinguish them whatever RTP
sessions are multicast or unicast.
4.1. SSRC-multiplexing for RET
This section specifies SSRC-multiplexing for RET.
In the figure below SSRC multiplexing occurs because the new RTP
session created by source2 to send the missing packets shares the
transport parameters (addresses, port) of the session which requests
the packets retransmission. Consequently the streams corresponding
to the 2 SSRCs share the natural NAT binding. The RTCP upstream
opens the NAT for the RTP download stream.
source1 source2 NAT Receiver
| | | |
| RTP multicast SSRC_ChA | |
1 |--------.------>| | |
| \----------------X---------------->|--------->|
| | packets loss | |
| | | |
| | | |
| RTCP FB NACK Port2 SSRC_B, SSRC_ChA | |
2 | |<==========================|<=========|
| | | |
| | | |
| | RTP Port2 SSRC_C | |
3 | |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~>|
| | | |
Figure 1: SSRC-multiplexing for RET
Step 1: source1 sends RTP packets with SSRC_ChA that identifies the
video session. Source2 receives the packets. Receiver detects
several lost of packets.
Step 2: The receiver requests a fast retransmission (RET) of the
packets not received, it sends a RTCP FB NACK message in a session
identified by a SSRC chosen by itself. This message identifies the
packets of channel A requested.
Step 3: source2 sends the retransmission packet with the same ports
and IP addresses than the RTCP FB message received. The flow of
retransmitted packet is identified by a new SSRC SSRC_C.
Babonneau, et al. Expires January 6, 2011 [Page 6]
Internet-Draft SSRC Multiplexing july 2010
4.2. SSRC-multiplexing for RAMS
This section specifies SSRC-multiplexing for RAMS.
In the figure below SSRC multiplexing occurs because the new RTP
session created by source2 to send the burst of channel B content
reuses the transport parameters (addresses, port) of the RTCP
request: SSRC_B and SSRC_C are multiplexed over the same transport
session.
source1 source2 NAT Receiver
| | | |
| RTP multicastA SSRC_ChA | |
1 |--------.------>| | |
| \--------------------------------->|--------->|
| | | |
| RTP multicastB SSRC_ChB | |
|--------------->| | |
| | | |
| | | |
| RTCP RAMS Port2 SSRC_B, SSRC_ChB | |
2 | |<==========================|<=========|
| | | |
| | | |
| | RTP Port2 SSRC_C | |
3 | |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~>|
| | | |
Figure 2: SSRC-multiplexing for RAMS
Step 1: Source1 sends RTP packets of Channel A in a session
identified with SSRC_ChA.
Step 2: when the user switches to channel B, its terminal sends a
RTCP RAMS request in a session identified by a SSRC choosen locally,
SSRC_B. The RAMS request includes the identifier of the new channel
selected, the SSRC of Channel_B.
Step 3: source2 sends the retransmission packet with the same ports
and IP addresses than the RTCP RAMS request received. The flow of
retransmited packet is identified by a new SSRC SSRC_C choosen
locally by source2.
After receiving the RAMS content the terminal switches to the regular
source of Channel B content, source1.
Babonneau, et al. Expires January 6, 2011 [Page 7]
Internet-Draft SSRC Multiplexing july 2010
5. Discussion
Keep Alive:
The adding of extra signaling and processing does not benefit of NAT
binding naturally created by the request . One consequence is the
need of additional messages to maintain the session open on the NAT.
In other term the bootstrap of the session may be so long that the
NAT has closed the session before the RET or the RAMS traffic is sent
by the server source2.
Performance:
RET and RAMS were introduced to improve the QoE of multicast video
sessions. RET is designed to reduce the blockyness. RAMS is
designed to reduce the zapping duration. Both rely on the ability of
the server 'source2' to send the data requested in real time over
RTP. The adding of extra signaling and processing delays the
response and consequently reduces the improvement of the QoE
intrisically expected. SSRC-multiplexing reduces the processing
duration in the server and in the terminal. It reduces the
processing in the server. It reduces the processing and simplifies
the logic in the terminal: the response arrives naturally on the port
which sent the request without additional processing.
Scalability:
The adding of extra signaling and processing like Keeplive and NAT
binding management adds non deterministic processing duration and
resource comsumption in the server source2. This prevent any
optimization of the deployment of RET and RAMS services.
NAT binding management:
NAT binding maps the local transport parameters on the public
transport parameters. It must be performed for each service request
to capture any change of local transport parameters. The adding of
extra signaling and processing during the binding must be avoided at
this step to keep the delay of response as low as possible.
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Babonneau, et al. Expires January 6, 2011 [Page 8]
Internet-Draft SSRC Multiplexing july 2010
7. Security Considerations
The scope of application of the SSRC multiplexing specified in this
document is limited to the cases of there is a NAT on the path.
8. Acknowledgements
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.
9.2. Informative References
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions",
draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in
progress), May 2010.
[I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-10 (work in
progress), May 2010.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
Appendix A. An Appendix
Babonneau, et al. Expires January 6, 2011 [Page 9]
Internet-Draft SSRC Multiplexing july 2010
Authors' Addresses
Gerard Babonneau
France Telecom Orange
4, rue du Clos Courtel
Cesson Sevigne 35510
France
Email: gerard.babonneau@orange-ftgroup.com
Xavier Marjou
France Telecom Orange
2, avenue Pierre Marzin
Lannion 22307
France
Email: xavier.marjou@orange-ftgroup.com
Stephan Emile
France Telecom Orange
2 avenue Pierre Marzin
Lannion F-22307
France
Email: emile.stephan@orange-ftgroup.com
Babonneau, et al. Expires January 6, 2011 [Page 10]