AVT B. VerSteeg
Internet-Draft A. Begen
Intended status: Standards Track Cisco Systems
Expires: September 10, 2009 T. VanCaenegem
Alcatel-Lucent
Z. Vax
Microsoft Corporation
March 9, 2009
Unicast-Based Rapid Synchronization with RTP Multicast Sessions
draft-versteeg-avt-rapid-synchronization-for-rtp-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009.
Copyright Notice
VerSteeg, et al. Expires September 10, 2009 [Page 1]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
When a receiver joins a multicast session, it may need to acquire and
parse certain Reference Information before it can process any data
sent in the multicast session. Depending on the join time, length of
the Reference Information repetition interval, size of the Reference
Information as well as the application and transport properties, the
time lag before a receiver can usefully consume the multicast data,
which we refer to as the synchronization delay, varies and may be
large. This is an undesirable phenomenon for receivers that
frequently switch among different multicast sessions, such as video
broadcasts. In this document, we describe a method using the
existing RTP and RTCP protocol machinery that reduces the
synchronization delay. In this method, an auxiliary unicast RTP
session carrying the Reference Information to the receiver precedes/
accompanies the multicast flow. This unicast flow may be transmitted
at a faster than natural rate to further accelerate the
synchronization. The motivating use case for this capability is
multicast applications that carry real-time compressed audio and
video. However, the proposed method can also be used in other types
of multicast applications where the synchronization delay is long
enough to be a problem.
VerSteeg, et al. Expires September 10, 2009 [Page 2]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Streams . . . . . . . . . . . . 7
5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Synchronization . . . . . . . . 9
6. Rapid Multicast Synchronization . . . . . . . . . . . . . . . 11
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 18
6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 18
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 19
7.1. RMS Request . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. RMS Information . . . . . . . . . . . . . . . . . . . . . 21
7.3. RMS Termination . . . . . . . . . . . . . . . . . . . . . 23
8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 24
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 27
10. Known Implementations . . . . . . . . . . . . . . . . . . . . 27
10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 27
10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 27
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 27
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
13.1. Registration of SDP Attribute Values . . . . . . . . . . . 28
13.2. Registration of FMT Values . . . . . . . . . . . . . . . . 28
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 29
15.1. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 29
15.2. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 29
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Normative References . . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
VerSteeg, et al. Expires September 10, 2009 [Page 3]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
1. Introduction
Most multicast flows carry a stream of inter-related data. Certain
information must first be acquired by the receivers to start
processing any data sent in the multicast session. This document
refers to this information as Reference Information. The Reference
Information is conventionally sent periodically in the multicast
session and usually consists of items such as a description of the
schema for the rest of the data, references to which data to process
for the receivers, encryption information including keys, as well as
any other information required to process the data in the multicast
flow.
Real-time multicast applications require the receivers to buffer
data. The receiver may have to buffer data to smooth out the network
jitter, to allow loss-repair methods such as Forward Error Correction
and retransmission to recover the missing packets, and to satisfy the
data processing requirements of the application layer.
When a receiver joins a multicast session, it has no control over
what point in the flow is currently being transmitted. Sometimes the
receiver may join the session right before the Reference Information
is sent in the session. In this case, the required waiting time is
usually minimal. Similarly, the receiver may also join the session
right after the Reference Information has been transmitted. In this
case the receiver has to wait for the Reference Information to appear
again in the stream before it can start processing any multicast
data. In some other cases, the Reference Information is not
contiguous in the flow but dispersed over a large period, which
forces the receiver to wait for all of the Reference Information to
arrive before starting to process the rest of the data.
The net effect of waiting for the Reference Information and waiting
for various buffers to fill up is that the receivers may experience
significantly large delays in data processing. In this document, we
refer to the difference between the time a receiver joins the
multicast session and the time the receiver acquires all the
necessary Reference Information as the Synchronization Delay. The
synchronization delay may not be the same for different receivers; it
usually varies depending on the join time, length of the Reference
Information repetition interval, size of the Reference Information as
well as the application and transport properties.
The varying nature of the synchronization delay adversely affects the
receivers that frequently switch among multicast sessions. In this
specification, we address this problem for RTP-based multicast
applications and describe a method that uses the fundamental tools
offered by the existing RTP and RTCP protocols [RFC3550]. In this
VerSteeg, et al. Expires September 10, 2009 [Page 4]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
method, either the multicast source (or the distribution source in a
single-source multicast (SSM) session) retains Reference Information
for a period after transmission, or an intermediary network element
joins the multicast session and continuously caches the Reference
Information as it is sent in the session and acts as a feedback
target (See [I-D.ietf-avt-rtcpssm])for the session. When a receiver
wishes to join the same multicast session, instead of simply issuing
an Internet Group Management Protocol (IGMP) [RFC3376] Join message,
it sends a request to the feedback target address for the session
asking for the Reference Information. The feedback target starts a
unicast retransmission RTP session and sends the Reference
Information to the receiver over that session. If there is spare
bandwidth, the feedback target may also burst the Reference
Information at a faster than natural rate. As soon as the receiver
acquires the Reference Information, it can join the multicast group
and start processing the multicast data. This method potentially
reduces the synchronization delay. We refer to this method as
Unicast-based Rapid Synchronization with RTP Multicast Sessions. A
simplified network diagram showing the rapid synchronization method
through an intermediary network element is depicted in Figure 1.
+-------------------+
+--->| Intermediary |
| ...| Network Element |
| : +-------------------+
| :
| v
+-----------+ +----------+ +----------+
| Multicast | | Router |---------->| Joining |
| Source |------->| |..........>| RTP |
+-----------+ +----------+ | Receiver |
| +----------+
|
| +----------+
+---------------->| Existing |
| RTP |
| Receiver |
+----------+
...> Unicast RTP Flow
---> Multicast RTP Flow
Figure 1: Rapid synchronization through an intermediary network
element
A primary design goal in this solution is to use the existing tools
in the RTP protocol family. This improves the versatility of the
VerSteeg, et al. Expires September 10, 2009 [Page 5]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
existing implementations, and promotes faster deployment and better
interoperability. To this effect, we use the unicast retransmission
support of RTP [RFC4588] and the capabilities of RTCP to handle the
signaling needed to accomplish the synchronization. The packet(s)
carrying the Reference Information are sent by the feedback target in
the auxiliary unicast session for rapid synchronization. These are
constructed as retransmission packets that would have been sent in a
unicast RTP session to recover the missing packets at a receiver that
has never received any packet. In fact, a single RTP session MAY be
used for both rapid synchronization and retransmission-based loss
repair. Furthermore, the session can be used to simultaneously
provide unicast burst traffic for the rapid synchronization and
repair packets requested by the receiver when it detects lost burst
packets or lost RTP packets from the primary multicast stream (in the
case it is receiving both streams at the same time). The
conventional RTCP feedback message that requests the retransmission
of the missing packets [RFC4585] indicates their sequence numbers.
However, upon joining a new session the receiver has never received a
packet and thus, does not know the sequence numbers. Instead, the
receiver sends a newly defined RTCP feedback message to request the
Reference Information needed to rapidly synchronize with the primary
multicast session. It is also worth noting that in order to issue
the initial RTCP message to the feedback target, the SSRC of the
session to be joined must be known prior to any packet reception, and
hence, needs to be signaled out-of-band (or in-band). In a Session
Description Protocol (SDP) description, the SSRC MUST be signaled
through the 'ssrc' attribute [I-D.ietf-avt-rtcpssm]
In the rest of this specification, we have the following outline: In
Section 4, we describe the delay components in generic multicast
applications. Section 5 presents an overview of the protocol design
considerations for rapid synchronization. We provide the protocol
details of the rapid multicast synchronization method in Section 6
and Section 7. Section 8 and Section 9 discuss the SDP signaling
issues with examples and NAT-related issues, respectively.
Note that Section 3 provides a list of the definitions frequently
used in this document.
2. Requirements Notation
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 [RFC2119].
VerSteeg, et al. Expires September 10, 2009 [Page 6]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
3. Definitions
This document uses the following acronyms and definitions frequently:
Media Session: Media session as defined in [RFC3550].
Primary Multicast Stream: The one-to-many RTP stream of single-
source multicast (SSM) RTP packets to which an RTP receiver joins at
a random point in time.
Feedback Target: (Unicast RTCP) Feedback target as defined in
[I-D.ietf-avt-rtcpssm].
Retransmission Packet: Retransmission packet as defined in
[RFC4588].
Burst (Stream): A unicast stream of RTP packets associated with the
primary multicast stream. The burst stream is typically transmitted
at an accelerated rate.
Retransmission Server (RS): The RTP/RTCP endpoint generating the
burst stream that can be triggered and controlled by messages defined
in this document.
Media and Reference Information: Media and reference information is
a media stream containing the media content and its metadata,
sufficient to reconstruct and use the content in the context of a
specific application. The meaning, format and the size of this
information are specific to the application and are out of scope of
this document.
Maximal Burst Bandwidth: The peak absolute bitrate for the unicast
burst stream. This is supplied by the RTP receiver, based on its
understanding of the access network capacity, its own ability to
process burst packets, and other factors.
4. Elements of Delay in Multicast Streams
In an any-source (ASM) or a single-source (SSM) multicast delivery
system, there are three major elements that contribute to the overall
synchronization delay when a receiver switches from one multicast
session to another one. These are:
o Multicast switching delay
o Reference Information latency
VerSteeg, et al. Expires September 10, 2009 [Page 7]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
o Buffering delays
Multicast switching delay is the delay that is experienced to leave
the current multicast session (if any) and join the new multicast
session. In typical systems, the multicast join and leave operations
are handled by a group management protocol. For example, the
receivers and routers participating in a multicast session may use
the Internet Group Management Protocol (IGMP) [RFC3376]. In
[RFC3376], when a receiver wants to join a multicast session, it
sends an IGMP Join message to its upstream router and the routing
infrastructure sets up the multicast forwarding state to deliver the
packets of the multicast session to the new receiver. Depending on
the proximity of the upstream router, the current state of the
multicast tree, the load on the system and the protocol
implementation, the join times vary. Current systems provide join
latencies usually less than 200 milliseconds (ms). If the receiver
had been participating in another multicast session before joining
the new session, it needs to send an IGMP Leave message to its
upstream router to leave the session. In IGMP version 3 [RFC3376] ,
the leave times are usually smaller than the join times, however, it
is possible that the Leave and Join messages may get lost, in which
case the multicast switching delay inevitably increases.
Reference Information latency is the time it takes the receiver to
acquire the Reference Information. It is highly dependent on the
proximity of the actual time the receiver joined the session to the
next time the Reference Information will be sent to the receivers in
the session, whether the Reference Information is sent contiguously
or not, and the size of the Reference Information. For some
multicast flows, there is a little or no interdependency in the data,
in which case the Reference Information latency will be nil or
negligible. For other multicast flows, there is a high degree of
interdependency. One example of interest is the multicast flows that
carry compressed audio/video. For these flows, the Reference
Information latency may become quite large and be a major contributor
to the overall delay.
The buffering component of the overall synchronization delay is
driven by the way the application layer processes the payload. In
many multicast applications, an unreliable transport protocol such as
UDP [RFC0768] is often used to transmit the data packets, and the
reliability, if needed, is usually addressed through other means such
as Forward Error Correction and retransmission
[I-D.ietf-rmt-pi-norm-revised]. These loss-repair methods require
buffering at the receiver side to function properly. In many
applications, it is also often necessary to de-jitter the incoming
data packets before feeding them to the application. The de-
jittering process also increases the buffering delays. Besides these
VerSteeg, et al. Expires September 10, 2009 [Page 8]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
network-related buffering delays, there are also specific buffering
needs that are required by the individual applications. For example,
MPEG decoders require a significant amount of content to be available
in the decoder buffers prior to starting to decode the content.
5. Protocol Design Considerations and Their Effect on Resource
Management for Rapid Synchronization
Rapid synchronization is an optimization of a system that must
continue to work correctly whether or not the optimization is
effective, or even fails due to lost control messages, congestion, or
other problems. This is fundamental to the overall design
requirements surrounding the protocol definition and to the resource
management schemes to be employed together with the protocol (e.g.,
QoS machinery, server load management, etc). In particular, the
system needs operate within a number of constraints.
o First, a rapid synchronization operation must fail gracefully.
The user experience must, except perhaps in pathological
circumstances, be not significantly worse for trying and failing
to complete rapid synchronization compared to simply joining the
multicast session.
o Second, providing the rapid synchronization optimizations must not
cause collateral damage to either the multicast session being
joined, or other multicast sessions sharing resources with the
rapid synchronization operation. In particular, the rapid
synchronization operation must avoid self-interference with the
multicast session that may be simultaneously being received by
other hosts. In addition, it must also avoid interference with
other multicast sessions sharing the same network resources.
These properties are possible, but difficult to achieve.
One challenge is the existence of multiple bandwidth bottlenecks
between the receiver and the server(s) in the network providing the
rapid synchronization service. In commercial IPTV deployments, for
example, bottlenecks are often present in the aggregation network
connecting the IPTV servers to the network edge, the access links
(e.g., DSL, DOCSIS) and in the home network of the subscribers. Some
of these links may serve only a single subscriber, limiting
congestion impact to the traffic of only that subscriber, but others
can be shared links carrying multicast sessions of many subscribers.
A second challenge is that for some uses (e.g., high-bitrate video)
the burst bandwidth is high while the flow duration of the burst is
short. This is because the purpose of the burst is to allow the
receiver to join the multicast quickly and thereby limit the overall
VerSteeg, et al. Expires September 10, 2009 [Page 9]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
resources consumed by the burst. Such high-bitrate, short-duration
flows are not amenable to conventional admission control techniques.
For example, per-flow signaled admission control techniques such as
RSVP have too much latency and control channel overhead to be a good
fit for rapid multicast synchronization. Similarly, using a TCP (or
TCP-like) approach with a 3-way handshake and slow-start to avoid
inducing congestion would defeat the purpose of attempting rapid
synchronization in the first place by introducing many RTTs of delay.
These observations lead to certain unavoidable requirements and goals
for a rapid multicast synchronization protocol. These are:
o The protocol must be designed to allow a deterministic upper bound
on the extra bandwidth used (compared to just joining the
multicast group). A reasonable size bound is e*B, where B is the
"nominal" bandwidth of the multicast flow, and e is an "excess-
bandwidth" coefficient The total duration of the burst must have a
reasonable bound; long bursts devolve to the bandwidth profile of
multi-unicast for the whole system.
o The scheme should minimize (or better eliminate) the overlap of
the burst and the multicast flow. This minimizes the window
during which congestion could be induced on a bottleneck link
compared to just carrying the multicast or unicast packets alone.
o The scheme must minimize (or better eliminate) any gap between the
unicast burst and multicast flow which has to be repaired later,
or in the absence of repair, will result in loss being experienced
by the application.
In addition to the above, there are some other protocol design issues
to be considered. First, there is at least one RTT of "slop" in the
control loop. In starting a rapid multicast synchronization burst,
this manifests as the time between the client requesting the burst
and the burst description (and possibly the first burst packets)
arriving at the receiver. For managing and terminating the burst,
there are two possible approaches for the control loop: The receiver
can adapt to the burst as received, converge based on observation and
explicitly terminate the burst with a second control loop exchange
(which takes a minimum of one RTT, just as starting the burst does).
Alternatively, the server generating the burst can pre-compute the
burst parameters based on the information in the initial request and
tell the receiver the burst duration.
The protocol described in the next section allows either method of
controlling the rapid multicast synchronization burst.
VerSteeg, et al. Expires September 10, 2009 [Page 10]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
6. Rapid Multicast Synchronization
We start this section with an overview of the rapid multicast
synchronization (RMS) method.
6.1. Overview
[I-D.ietf-avt-rtcpssm] specifies an extension to the RTP Control
Protocol (RTCP) to use unicast feedback in an SSM session. It
defines an architecture that introduces the concept of Distribution
Source, which - in an SSM context - distributes RTP data and
redistributes RTCP information to all receivers. This RTCP
information is retrieved from the Feedback Target, to which RTCP
unicast feedback traffic is sent. The Feedback Target MAY be
implemented in one or more entities different from the Distribution
Source, and different RTP receivers MAY use different Feedback
Targets.
This document builds further on these concepts to reduce the
synchronization time when an RTP receiver wants to join a multicast
session at a random point in time by introducing the concept of the
Burst Source and new RTCP feedback messages. The Burst Source has a
cache where the most recent RTP packets from the SSM distribution are
continuously stored. When an RTP receiver wants to receive an SSM
RTP stream, prior to joining the SSM session, it will first request
an RTP burst from the Burst Source. In this burst, the packets are
formatted as RTP retransmission packets [RFC4588] and the data
carried in these packets allow the RTP receiver to synchronize
quickly with the SSM session.
Using an accelerated rate (as compared to the rate of the primary
multicast stream) for the RTP burst implies that at a certain point
in time, the payload transmitted in the RTP burst is going to be the
same as the payload multicast in the SSM session, i.e., the unicast
burst will catch up with the primary multicast stream. At this
point, the RTP receiver no longer needs to receive the unicast RTP
burst and can join the SSM session. This method is referred to as
the Rapid Multicast Synchronization (RMS) method.
This document proposes extensions to [RFC4585] for an RTP receiver to
request an RTP burst as well as for additional control messaging that
can be leveraged during the synchronization process.
6.2. Message Flows
Figure 2 shows the main entities involved in rapid multicast
synchronization:
VerSteeg, et al. Expires September 10, 2009 [Page 11]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
o Multicast Source
o Feedback Target (FT)
o Burst Source
o Retransmission Source
o RTP Receiver (RR)
+----------------------------------------------+
| Retransmission Server |
| (RS) |
| +----------+ +--------+ +----------------+ |
| | Feedback | | Burst | | Retransmission | |
| | Target | | Source | | Source | |
| +----------+ +--------+ +----------------+ |
+----------------------------------------------+
^ ^ :
| ' :
| ' :
| ' :
+-----------+ +----------+ +----------+
| | | |'''''''''''>| |
| Multicast |------->| Router |...........>| RTP |
| Source | | |<~~~~~~~~~~~| Receiver |
| | | |----------->| (RR) |
+-----------+ +----------+ +----------+
'''> Unicast RTCP Messages
~~~> IGMP Messages
...> Unicast RTP Flow
---> Multicast RTP Flow
Figure 2: Flow diagram for unicast-based rapid synchronization
A Retransmission Source can equally act as a Burst Source. The
Retransmission Source can also incorporate the Feedback Target
([I-D.ietf-avt-rtcpssm] permits the feedback target to be a
retransmission server, since it is a logical function to which RRs
send their unicast feedback), and we will use the term Retransmission
Server (RS) in the remainder of the document to refer to a single
physical entity comprising these three entities. Note that the same
method (with the identical message flows) would also apply in a
scenario where rapid synchronization is performed by a feedback
target co-located with the media source.
VerSteeg, et al. Expires September 10, 2009 [Page 12]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
As the RTP burst packets are formatted as RTP retransmission packets
[RFC4585], the unicast RTP burst and RTP retransmissions MAY be
provided in one and the same RTP (retransmission) session.
The RTP burst is triggered by the RTCP feedback message defined in
this document, whereas an RTP retransmission is triggered by an RTCP
NACK message defined in [RFC4585]. Pending on RMS practices, there
may be a gap between the end of the burst stream and the reception of
the primary multicast stream because of the imperfections in the
switch-over. RR can make use of the RTCP NACK message to request a
retransmission for the missing packets in the gap.
Editor's note: As stated in the text, FT, Burst Source and
Retransmission Source are logical entities. For efficiency and
simplicity, they MAY be implemented by a single physical
Retransmission Server (RS). In a number of places throughout this
document we assume (and explicitly state so) that all three are
implemented by the same physical entity and therefore share the same
IP address and the port number. The authors look to the AVT
community for recommendations on whether this is sufficient or the
mechanism has to explicitly address other topologies where FT, Burst
Source and Retransmission Source are not co-located.
Figure 3 depicts an example of messaging flow for rapid
synchronization. The RTCP feedback messages are explained below.
Note that the messages indicated in parentheses may or may not be
present during rapid synchronization.
VerSteeg, et al. Expires September 10, 2009 [Page 13]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
+-----------+ +----------------+ +----------+ +------------+
| Multicast | | Retransmission | | | | RTP |
| Source | | Server | | Router | | Receiver |
| | | (RS) | | | | (RR) |
+-----------+ +----------------+ +----------+ +------------+
| | | |
|-- RTP Multicast ------------------->| |
| | | |
|-- RTP Multicast ->| | |
| | | |
| |<''''''''''''''''''' RTCP RMR-R ''|
| | | |
| | | |
| |'' (RTCP RMS-I) '''''''''''''''''>|
| | | |
| | | |
| |.. Unicast RTP Burst ............>|
| | | |
| | | |
| |'' (RTCP RMS-I) '''''''''''''''''>|
| | | |
| | | |
| | |<~~ IGMP Join ~~|
| | | |
| | | |
|-- RTP Multicast ------------------------------------>|
| | | |
| | | |
| |<''''''''''''''''''' RTCP RMR-T ''|
| | | |
| | | |
| |<''''''''''''''''''' (RTCP NACK)''|
| | | |
| | | |
| |.. (Unicast Retransmissions) ....>|
| | | |
| | | |
| |<''''''''''''''''''''' RTCP BYE ''|
| | | |
| | | |
| | | |
'''> Unicast RTCP Messages
~~~> IGMP Messages
...> Unicast RTP Flow
---> Multicast RTP Flow
VerSteeg, et al. Expires September 10, 2009 [Page 14]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
Figure 3: Message flows for unicast-based rapid synchronization
This document defines the expected behaviors of RS and RR. It is
instructive to have independently operating implementations on RS and
RR that request the burst, describe the burst, start the burst, join
the multicast stream and stop the burst. These implementations send
messages to each other, but there MUST be provisions for the cases
where the control messages get lost or are not being delivered to
their destinations.
The following steps describe rapid synchronization in detail:
1. Request: RR sends a rapid synchronization request for the new
multicast RTP session to the feedback target address of that
session. The request contains the SSRC of RR and the SSRC of the
media source. This RTCP feedback message is defined as Rapid
Multicast Synchronization Request (RMS-R) message and MAY contain
parameters, which may constrain the burst, such as the bandwidth
limit. Other parameters may be related to the amount of
buffering capacity available at RR, which may be used by RS to
prepare a rapid synchronization burst that conforms with RR's
requirements.
Before joining the primary multicast session, a new joining RR
learns the addresses associated with the new multicast session
(addresses for the multicast source, group and retransmission
server) by out-of-band means (See for Section 8 details). Also
note that since no RTP packets have been received yet for this
session, the SSRC must be obtained out-of-band or in-band. See
Section 8 for details.
2. Response: RS receives the RMS-R message and decides whether to
accept it or not. RS MUST send an (at least one) RMS-Information
(RMS-I) message to RR. The first RMS-I message MAY precede the
burst or it may be sent during the burst. Additional RMS-I
messages may be sent during the burst. The join-time information
(for the new multicast session) MUST be populated in at least one
of the RMS-I messages.
Note that RS learns the IP address and port information for RR
from the RMS-R message it received. (This description glosses
over the NAT details. Refer to Section 9 for a discussion of
NAT-related issues.)
If RS cannot provide a rapid synchronization service, RS rejects
the request and informs RR immediately via an RMS-I message. If
RR receives a message indicating that its rapid synchronization
request has been denied, it abandons the rapid synchronization
VerSteeg, et al. Expires September 10, 2009 [Page 15]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
attempt and MAY immediately join the multicast session by sending
an IGMP Join message [RFC3376] to its upstream multicast router
for the new multicast session.
If RS accepts the request, it sends an RMS-I message to RR
(before commencing the burst or during the burst) that comprises
fields that can be used to describe the burst that will be sent
by RS (e.g., the bitrate and the size of the burst). There may
also be optional payload-specific information that RS chooses to
send to RR. Such an example is discussed in
[I-D.begen-avt-rtp-mpeg2ts-preamble] for transmitting the
payload-specific information for MPEG2 Transport Streams. The
burst duration may be calculated by RS, and its value may be
updated by messages received from RR.
3. Updated Responses: RS may send more than one RMS-I messages,
e.g., to update the burst bitrate information when the bitrate is
adapted and/or to signal RR in real time to join the SSM session.
For redundancy purposes, an RMS-I message MAY also be sent
multiple times. RR may depend on RS to learn the join-time for
the SSM session. The join-time can be conveyed by the first
RMS-I message, or it can be sent/revised in later RMS-I messages.
If RS is not capable of determining the join-time in the first
RMS-I message, it will have to send another RMS-I message later.
4. SSM Join: In principal, RR can join the primary multicast
session any time during or after the end of the RTP burst via an
IGMP Join message [RFC3376]. However, there may be missing
packets if RR joins the SSM session too early or too late. For
example, if RR starts receiving the primary multicast stream
while it is still receiving the RTP burst at a high excess
bitrate, this may result in an increased risk of packet loss.
Or, if RR joins the SSM session some time after the RTP burst is
finished, there may be a gap between burst and multicast data (a
number of RTP packets may be missing). In both cases, RR MAY
issue retransmissions requests [RFC4585] to fill the gap.
Yet, there are cases where the remaining available bandwidth may
limit the number of retransmissions that can be provided within a
certain time period, causing the retransmission data to arrive
too late at RR (from application layer point of view). To cope
with such cases, the RMS-I message allows RS to signal explicitly
when RR should join the SSM session. Alternatively, RS may pre-
compute the burst duration and the time RR should join the SSM
session. This information may be conveyed in the RMS-I message
and can be updated in subsequent RMS-I messages. RR may use the
information from the most recent RMS-I message, or it may use a
locally calculated join-time.
VerSteeg, et al. Expires September 10, 2009 [Page 16]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
5. Multicast Receive: After joining the SSM session, RR starts
receiving the multicast RTP flow.
6. Terminate: RS may know when it needs to stop the unicast burst
based on the burst parameters, or RR may explicitly let RS know
the sequence number of the first RTP packet it received from the
multicast session, or RR may request RS to terminate the burst
immediately.
RR SHALL use the RMS-Termination (RMS-T) message when it wishes
to provide information to RS regarding the cessation of the
burst. RR can choose to send the RMS-T message before or after
it starts receiving the multicast data. In the latter case, RR
SHALL include the sequence number of the first RTP packet
received in the SSM session in the RMS-T message, and RS SHOULD
terminate the burst after it sends the RTP burst packet whose OSN
field in the RTP retransmission payload header matches this
number minus one.
If RR wants to stop the burst prior to receiving the multicast
data, it sends an empty RMS-T message (i.e., without an RTP
sequence number).
Note that regardless of whether RS knows when to stop the burst
or not, RR MUST send at least one RMS-T message. Against the
possibility of a message loss, RR MAY repeat the RMS-T messages
multiple times as long as it follows the RTCP timer rules defined
in [RFC4585].
7. Terminate with RTCP BYE: When RR is no longer interested in
receiving the primary multicast stream and the associated burst,
RR SHALL issue an RTCP BYE message to the Feedback Target to
terminate the burst and RTP retransmission session. Upon
receiving an RTCP BYE message, RS MUST terminate the rapid
synchronization operation, and cease transmitting any further
packets of the associated unicast burst. Section 6.1 of
[RFC3550] mandates the RTCP BYE message always to be sent with a
sender or receiver report in a compound RTCP packet (If no data
has been received, an empty receiver report MUST be included).
With the information contained in the receiver report, RS can
also figure out how many duplicate RTP packets have been
delivered to RR (Note that this will be an upper-bound estimate
as one or more packets might have been lost during the burst
transmission). The impact of duplicate packets and measures that
can be taken to minimize the impact of receiving duplicate
packets will be addressed in Section 6.3.
Note that if RR decides to switch to a new multicast session
VerSteeg, et al. Expires September 10, 2009 [Page 17]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
after it already joined a multicast session following a rapid
synchronization request, RR MUST also send an RTCP BYE message
for the session associated with the current multicast source
stream.
For the purpose of gathering detailed information about RR's rapid
synchronization experience,[I-D.begen-avt-rapid-sync-rtcp-xr] defines
an RTCP Extended Report (XR) Block. This report is designed to be
payload-independent, thus, it can be used by any multicast
application that supports rapid synchronization. Support for this XR
report is, however, optional.
6.3. Shaping the Unicast Burst
Editor's note: This section may discuss sizing of the buffers,
output buffer overload protection, output bandwidth management,
adjustment of burst rate and duration.
TBC.
6.4. Failure Cases
Editor's note: This section discusses what happens if the request
for rapid synchronization gets lost, or rapid synchronization fails,
or when there are no available resources, etc.
All RMS messages MAY be sent several times to the possibility of
message loss as long as RS/RR follows the RTCP timer rules defined in
[RFC4585]. In the following we examine the implications of losing
the RMS-R, RMS-I or RMS-T messages.
When RR sends an RMS-R message to initiate a rapid synchronization
but the message gets lost and RS does not receive it, RR will not get
an RMS-I message, nor an RTP burst. In this case, RR may, within a
reasonable amount of time, either resend the request or may time out
and immediately join the primary multicast session. The timeout
duration may be based on the previous observed response times.
In the case RR starts receiving an RTP burst but it does not receive
a corresponding RMS-I message within a reasonable amount of time, RR
MAY either discard the burst data and stop the burst by sending an
RTCP BYE message to RS, or decide not to interrupt the RTP burst and
be prepared to join the primary multicast session at an appropriate
time it determines or indicated in a subsequent RMS-I message. In
either case, RR SHALL send an RMS-T message to RS at an appropriate
time.
In the case the RMS-T message sent by RR does not reach its
VerSteeg, et al. Expires September 10, 2009 [Page 18]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
destination, RS may continue sending the RTP burst even though RR no
longer needs it. In some cases, RS has not pre-computed the burst
duration and does not know when to stop the burst. To cover that
case, RR MAY repeat the RMS-T message multiple times as long as it
follows the RTCP timer rules defined in [RFC4585]. RS MUST be
provisioned to deterministically terminate the burst at some point,
even if it never receives an RMS-T message.
If RR determines that rapid synchronization has failed, it SHOULD
first cancel the pending/active rapid synchronization operation.
Then, if staying on the same session, RR SHOULD join the multicast
session; if switching to a new session, RR MAY send a new rapid
synchronization request for the new session only after it sends an
RTCP BYE message to the Feedback Target to terminate the existing
burst and RTP retransmission session.
7. Encoding of the Signaling Protocol in RTCP
This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between the Retransmission Server (RS)
and RTP Receiver (RR) during rapid multicast synchronization (RMS).
These messages are payload-independent and SHOULD be used by all RTP-
based multicast applications that support rapid synchronization
regardless of the payload they carry.
Specific payload formats are not defined in this document, but a
framework is presented that allows payload-specific information to be
included in the exchange.
The common packet format for the RTCP feedback messages is defined in
Section 6.1 of [RFC4585]. Each feedback message has a fixed-length
field for version, padding, feedback message type (FMT), payload type
(PT), length, SSRC of packet sender, SSRC of media source as well as
a variable-length field for feedback control information (FCI).
In the transport-layer feedback messages, the PT field is set to
RTPFB (205).
Editor's note: Rather than having special cases for "value unknown
or unspecified" in each of the fields carried in the messages, we are
considering to format the fields in these structures as Type/Length/
Value (TLV) elements. If the originator of the message does not have
a value for a field, the field will not be present. The advantage of
this design is that there will not be any ambiguity in the value of
the field. The disadvantage is that the message is variable length,
and slightly more complex to generate/parse.
VerSteeg, et al. Expires September 10, 2009 [Page 19]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
Extensions: Optional extended parameters may be encoded using TLV
elements as described below:
o Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element.
o Length: A two-octet field that indicates the length of the Value
field.
o Value: Variable-size set of octets that contains the specific
value for the parameter.
If a TLV element does not fall on a 32-bit boundary, the last word
must be padded to the boundary using further bits set to 0.
Editor's note: A design that will allow vendor-specific extensions
to be used in these messages is also desirable. For interop
purposes, the design must avoid collisions. Some approaches are
currently being examined.
7.1. RMS Request
The RMS Request message is identified by PT=RTPFB and FMT=5.
The FCI field MUST contain only one RMS Request.
The RMS Request is used by RR to request rapid synchronization for a
new multicast RTP session.
The FCI field has the structure depicted in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min RMS Buffer Fill Requirement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max RMS Buffer Fill Requirement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Receive Bitrate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: FCI field syntax for the RMS Request message
VerSteeg, et al. Expires September 10, 2009 [Page 20]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
Min RMS Buffer Fill Requirement (32 bits): The minimum amount of
data (in ms) required by RR after the burst completes.
If specified, the amount of backfill that will be provided by the
unicast burst SHOULD NOT be smaller than this value since it will
not be able to build up the desired level of buffer at RR and may
cause buffer underruns.
Max RMS Buffer Fill Requirement (32 bits): The maximum amount of
data (in ms) that can be received by RR after the burst completes.
If specified, the amount of backfill that will be provided by the
unicast burst SHOULD NOT be larger than this value since it may
cause buffer overflows at RR.
Max Receive Bitrate (32 bits): The maximum bitrate (in bits per
second) that RR can receive.
If specified, the unicast burst bitrate SHOULD NOT be larger than
this value since it may cause congestion and packet loss.
The length of the feedback message MUST be set to 2+n, where n is the
number of fields contained in the message.
The semantics of this feedback message is independent of the payload
type.
7.2. RMS Information
The RMS Information message is identified by PT=RTPFB and FMT=6.
The FCI field MUST contain only one RMS Information.
The RMS Information is used to describe the unicast burst that will
be sent for rapid synchronization. It also includes other useful
information for RR.
The FCI field has the structure depicted in Figure 5.
VerSteeg, et al. Expires September 10, 2009 [Page 21]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSN | Response | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of the First Burst Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest IGMP Join Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rapid Synchronization Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Burst Bitrate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FCI field syntax for the RMS Information message
Message Sequence Number (8 bits) : During rapid synchronization,
the RMS-I message(s) may be sent more than once. The first RMS-I
message SHALL have an MSN value of 0. This value SHALL NOT be
changed if the same RMS-I message is sent to the same RR multiple
times for redundancy purposes. If a new information is conveyed
in a new RMS-I message, the MSN value SHALL be incremented by one.
Response (8 bits): Three values are defined: A value of 0
indicates that rapid synchronization request has been rejected.
This MAY trigger RR to proceed with joining the primary multicast
session. A value of 1 indicates that the rapid synchronization
request has been accepted. A value of 2 means that RR SHOULD
immediately join the primary multicast session. Other values MAY
be defined later.
Rsvd (16 bits): Reserved.
Extended RTP Seqnum of the First Burst Packet (32 bits): The
extended RTP sequence number of the first packet that will be sent
as part of the rapid synchronization in the burst. This allows RR
to know if one or more packets have been dropped at the beginning
of the burst. 32-bit extended RTP sequence number is constructed
by putting the 16-bit RTP sequence number in the lower two bytes
and octet 0's in the higher two bytes.
Earliest IGMP Join Time (32 bits): Time difference between the
arrival of the RMS-I message and the earliest time instant when RR
could join the new multicast session (in RTP clock ticks). A
value of all 1's means that it is not specified.
VerSteeg, et al. Expires September 10, 2009 [Page 22]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
Rapid Synchronization Duration (32 bits): Time difference between
the timestamps of the first and last RTP packets in the unicast
burst (in RTP clock ticks). A value of all 1's means that it is
not specified.
Max Burst Bitrate (32 bits): The max bandwidth used by RS for the
unicast burst, expressed in bits per second. A value of 0 means
that it is not specified.
The length of the feedback message MUST be set to 2+n, where n is the
number of fields contained in the message.
The semantics of this feedback message is independent of the payload
type.
The RMS-I message MAY be sent multiple times at the start of, prior
to, or during the RTP unicast burst. The subsequent RMS-I messages
MAY signal changes in any of the fields.
7.3. RMS Termination
The RMS Termination message is identified by PT=RTPFB and FMT=7.
The FCI field MUST contain only one RMS Termination.
The RMS Termination may be used to assist RS in determining when to
stop the burst.
If prior to sending the RMS-T message RR has already joined the
multicast session and received at least one RTP packet from the
multicast session, RR includes the sequence number of the first RTP
packet in the RMS-T message. With this information, RS can decide
when to terminate the unicast burst.
If RR issues the RMS-T message before it has joined and/or begun
receiving RTP packets from the multicast session, RR does not specify
any sequence number in the RMS-T message, which indicates RS to stop
the burst immediately. However, note that RS may not receive this
message or may alter the burst.
The FCI field has the structure depicted in Figure 6.
VerSteeg, et al. Expires September 10, 2009 [Page 23]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of the First Multicast Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FCI field syntax for the RMS Termination message
Extended RTP Seqnum of the First Multicast Packet (32 bits): The
extended RTP sequence number of the first packet received from the
multicast session.
Editor's note: We need to either have TLV syntax for this field,
add a "valid flag" or come up with a reasonable value for
"unknown".
The length of the feedback message MUST be set to 2+n, where n is the
number of fields contained in the message.
The semantics of this feedback message is independent of the payload
type.
8. SDP Definitions and Examples
8.1. Definitions
The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585].
Here we add the following syntax to the 'rtcp-fb' attribute (the
feedback type and optional parameters are all case sensitive):
(In the following ABNF [RFC5234], fmt, SP and CRLF are used as
defined in [RFC4566].)
rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec
rtcp-fb-val = "nack" SP "ssli"
The following parameter is defined in this document for use with
'nack':
o 'ssli' stands for Stream Synchronization Loss Indication and
indicates the use of RMS messages as defined in Section 7.
VerSteeg, et al. Expires September 10, 2009 [Page 24]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
8.2. Examples
This section provides an SDP [RFC4566] example for enabling rapid
synchronization with multicast RTP sessions. The following example
uses the SDP grouping semantics [RFC3388], the RTP/AVPF profile
[RFC4585], the RTP retransmissions [RFC4588], the RTCP extensions for
SSM sessions with unicast feedback [I-D.ietf-avt-rtcpssm] and the
source-specific media attributes
[I-D.ietf-mmusic-sdp-source-attributes].
In the example below, we have two primary source streams and two
unicast retransmission streams for each of these source streams. The
source streams are multicast from a distribution source (with a
source IP address of 8.166.1.1) in different multicast groups. For
each source stream, a feedback target address (9.30.30.1) is also
specified with the 'rtcp' attribute. The receiver(s) can report
missing packets on the source stream to the feedback target and
request retransmissions. The parameter 'rtx-time' specifies the time
in milliseconds (measured from the time a packet was first sent) that
the sender (in this case the feedback target) keeps an RTP packet in
its buffers available for retransmission.
For the first source stream, only the conventional retransmission
support is enabled. For the second source stream, both the
conventional retransmission and rapid synchronization support are
enabled. This is achieved by the "a=rtcp-fb:98 nack ssli" line.
When a receiver requires rapid synchronization for a new multicast
session it wants to join, it sends an RMS-R message to the feedback
target. This feedback message has to have the SSRC of the primary
source session for which rapid synchronization is requested for.
However, since this receiver has not received any RTP packets from
this primary source session yet, the receiver MUST learn the SSRC
value from the 'ssrc' attribute of the media description
[I-D.ietf-avt-rtcpssm]. In addition to the SSRC value, the 'cname'
source attribute MUST also be present in the SDP description
[I-D.ietf-mmusic-sdp-source-attributes]. Note that listing the SSRC
values for the primary source sessions in the SDP file does not
create a problem in SSM sessions when an SSRC collision occurs. This
is because in SSM sessions, a receiver that observed an SSRC
collision with a media source MUST change its own SSRC
[I-D.ietf-avt-rtcpssm] by following the rules defined in [RFC3550].
A feedback target that receives an RMS-R feedback message becomes
aware that the prediction chain at the receiver side has been broken
or does not exist any more. If the necessary conditions are
satisfied (as outlined in Section 7 of [RFC4585]) and available
resources exist, the feedback target MAY react to the RMS-R message
VerSteeg, et al. Expires September 10, 2009 [Page 25]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
by sending the payload-specific feedback message(s) and starting the
unicast burst.
v=0
o=ali 1122334455 1122334466 IN IP4 rtp.rocks.com
s=Rapid Synchronization Examples
t=0 0
a=group:FID 1 2
a=group:FID 3 4
a=rtcp-unicast:rsi
m=video 40000 RTP/AVPF 96
i=Primary Source Stream #1
c=IN IP4 224.1.1.1/255
a=source-filter: incl IN IP4 224.1.1.1 8.166.1.1
a=recvonly
a=rtpmap:96 MP2T/90000
a=rtcp:40001 IN IP4 9.30.30.1
a=rtcp-fb:96 nack
a=mid:1
m=video 40002 RTP/AVPF 97
i=Unicast Retransmission Stream #1 (Ret. Support Only)
c=IN IP4 9.30.30.1
a=recvonly
a=rtpmap:97 rtx/90000
a=rtcp:40003
a=fmtp:97 apt=96
a=fmtp:97 rtx-time=3000
a=mid:2
m=video 41000 RTP/AVPF 98
i=Primary Source Stream #2
c=IN IP4 224.1.1.2/255
a=source-filter: incl IN IP4 224.1.1.2 8.166.1.1
a=recvonly
a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 9.30.30.1
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack ssli
a=ssrc:123321 cname:iptv-ch32@rms.example.com
a=mid:3
m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream #2 (Ret. and Rapid Synch. Support)
c=IN IP4 9.30.30.1
a=recvonly
a=rtpmap:99 rtx/90000
a=rtcp:41003
a=fmtp:99 apt=98
a=fmtp:99 rtx-time=5000
a=mid:4
VerSteeg, et al. Expires September 10, 2009 [Page 26]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
9. NAT Considerations
TBC.
10. Known Implementations
10.1. Open Source RTP Receiver Implementation by Cisco
An open source RTP Receiver code that implements the functionalities
introduced in this document is available. For documentation, visit
the following URL:
http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_0/user/guide/
ch1_over.html
The code is also available at:
ftp://ftpeng.cisco.com/ftp/vqec/
Note that this code is under development and may be based on an
earlier version of this document. As we make progress in the draft,
the source code will also be updated to reflect the changes.
Some preliminary results based on this code are available in [CCNC09]
and [IC2009].
10.2. IPTV Commercial Implementation by Microsoft
Rapid Multicast Synchronization is supported as part of the Microsoft
Mediaroom Internet Protocol Television (IPTV) and multimedia software
platform. This system is in wide commercial deployment. More
information can be found at:
http://www.microsoft.com/mediaroom
http://informitv.com/articles/2008/10/13/channelchangetimes/
11. Open Issues
o Finalizing the RTCP payload-independent message formats.
o Designing a capability for extending the feedback message formats
in the future.
o Burst shaping issues.
VerSteeg, et al. Expires September 10, 2009 [Page 27]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
12. Security Considerations
TBC.
13. IANA Considerations
This document registers a new SDP attribute value and several new
RTCP packets.
The following contact information shall be used for all registrations
in this document:
Ali Begen
abegen@cisco.com
170 West Tasman Drive
San Jose, CA 95134 USA
13.1. Registration of SDP Attribute Values
This document registers a new value for the 'nack' attribute to be
used with the 'rtcp-fb' attribute in SDP. For more information about
'rtcp-fb', refer to [RFC4585].
Value name: ssli
Long name: Stream Synchronization Loss Indication
Usable with: nack
Reference: This document
13.2. Registration of FMT Values
Within the RTPFB range, the following three format (FMT) values are
registered:
Name: RMS-R
Long name: Rapid Multicast Synchronization Request
Value: 5
Reference: This document
VerSteeg, et al. Expires September 10, 2009 [Page 28]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
Name: RMS-I
Long name: Rapid Multicast Synchronization Information
Value: 6
Reference: This document
Name: RMS-T
Long name: Rapid Multicast Synchronization Termination
Value: 7
Reference: This document
14. Acknowledgments
The authors would like to thank the following for their contributions
to this document: Dave Oran, Tony Faustini, Jeff Goldberg, Muriel
Deschanel, Orit Levin, Roni Even and Guy Hirson.
15. Change Log
15.1. draft-versteeg-avt-rapid-synchronization-for-rtp-02
The following are the major changes compared to version 01:
o The discussion around MPEG2-TS has been moved to another document.
o The RMS-R, RMS-I and RMS-T messages have been extensively modified
and they have been made mandatory.
o IANA Considerations section has been updated.
o The discussion of RTCP XR report has been moved to another
document.
o A new section on protocol design considerations has been added.
15.2. draft-versteeg-avt-rapid-synchronization-for-rtp-01
The following are the major changes compared to version 00:
o The core of the rapid synchronization method is now payload-
independent. But, the draft still defines payload-specific
messages that are required for enabling rapid synch for the RTP
flows carrying MPEG2-TS.
o RTCP APP packets have been removed, new RTCP transport-layer and
payload-specific feedback messages have been defined.
VerSteeg, et al. Expires September 10, 2009 [Page 29]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
o The step for leaving the current multicast session has been
removed from Section 6.2.
o A new RTCP XR (Multicast Join) report has been defined.
o IANA Considerations section have been updated.
o Editorial changes to clarify several points.
16. References
16.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[I-D.ietf-avt-rtcpssm]
Ott, J., "RTCP Extensions for Single-Source Multicast
Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17
(work in progress), January 2008.
[I-D.ietf-mmusic-sdp-source-attributes]
Lennox, J., Ott, J., and T. Schierl, "Source-Specific
VerSteeg, et al. Expires September 10, 2009 [Page 30]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
Media Attributes in the Session Description Protocol
(SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work
in progress), October 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
16.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[I-D.ietf-rmt-pi-norm-revised]
Adamson, B., Bormann, C., London, U., and J. Macker,
"NACK-Oriented Reliable Multicast Protocol",
draft-ietf-rmt-pi-norm-revised-08 (work in progress),
December 2008.
[I-D.begen-avt-rtp-mpeg2ts-preamble]
Begen, A., "RTP Payload Format for MPEG2-TS Preamble",
draft-begen-avt-rtp-mpeg2ts-preamble-00 (work in
progress), March 2009.
[I-D.begen-avt-rapid-sync-rtcp-xr]
Begen, A., "Rapid Multicast Synchronization Report Block
Type for RTCP XR", draft-begen-avt-rapid-sync-rtcp-xr-00
(work in progress), March 2009.
[CCNC09] Begen, A., Glazebrook, N., and W. VerSteeg, "A Unified
Approach for Repairing Packet Loss and Accelerating
Channel Changes in Multicast IPTV (IEEE CCNC)",
January 2009.
[IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing
Channel Change Times in IPTV with Real-Time Transport
Protocol (IEEE Internet Computing)", May 2009.
Authors' Addresses
Bill VerSteeg
Cisco Systems
5030 Sugarloaf Parkway
Lawrenceville, GA 30044
USA
Email: billvs@cisco.com
VerSteeg, et al. Expires September 10, 2009 [Page 31]
Internet-Draft Rapid Synchronization for RTP Flows March 2009
Ali Begen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: abegen@cisco.com
Tom VanCaenegem
Alcatel-Lucent
Copernicuslaan 50
Antwerpen, 2018
Belgium
Email: Tom.Van_Caenegem@alcatel-lucent.be
Zeev Vax
Microsoft Corporation
1065 La Avenida
Mountain View, CA 94043
USA
Email: zeevvax@microsoft.com
VerSteeg, et al. Expires September 10, 2009 [Page 32]