J. Chesterfield
University of Cambridge
J. Ott
Internet Draft Tellitec GmbH
Document: draft-ietf-avt-rtcpssm-07 E. Schooler
AT&T Labs - Research
Expires: January 2005 19 July 2004
RTCP Extensions for Single-Source Multicast Sessions
with Unicast Feedback
Status of this Memo
By submitting this Internet-Draft, each author certifies that any
applicable patent or other IPR claims of which the author is aware
have been disclosed, or will be disclosed, and any of which each
author becomes aware will be disclosed, in accordance with RFC 3668.
By submitting this Internet-draft, the authors accept the provisions
of Section 3 of RFC 3667 (BCP 78).
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.
Copyright (C) The Internet Society (date). All Rights Reserved.
Abstract
This document specifies an extension to the Real-time Transport
Control Protocol (RTCP) to use unicast feedback. The proposed
extension is useful for single-source multicast sessions such as
Source-Specific Multicast (SSM) communication where the traditional
model of many-to-many group communication is either not available or
not desired. In addition, it can be applied to any group that might
benefit from a sender-controlled summarised reporting mechanism.
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 1]
RTCP with Unicast Feedback
Table of Contents
1. Conventions and Acronyms........................................2
2. Introduction....................................................2
3. Basic Operation.................................................4
4. Definitions.....................................................5
5. Packet types....................................................6
6. Simple feedback model...........................................6
7. Sender feedback summary model...................................8
8. Mixer/Translator issues........................................20
9. Transmission interval calculation..............................21
10. SDP Extensions................................................23
11. Security Considerations.......................................23
12. Backwards Compatibility.......................................30
13. IANA Considerations...........................................30
14. Bibliography..................................................32
15. Appendix: Distribution Report processing at the receiver......34
16. AUTHORS ADDRESSES.............................................39
17. IPR Notice....................................................39
18. FULL COPYRIGHT STATEMENT......................................40
1. Conventions and Acronyms
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119.
2. Introduction
The Real-time Transport Protocol (RTP) [1] provides a real-time
transport mechanism suitable for unicast or multicast communication
between multimedia applications. Typical uses of RTP are for real-
time or near real-time group communication of audio and video data
streams. An important component of the RTP protocol is the control
channel, defined as the Real-Time Control Protocol (RTCP). RTCP
involves the periodic transmission of control packets between group
members, enabling group size estimation and the distribution and
calculation of session-specific information such as packet loss and
round trip time to other hosts. An additional advantage of providing
a control channel for a session is that a third-party session
monitor can listen to the traffic to establish network conditions
and to diagnose faults based on receiver locations.
RTP was designed to operate in either a unicast or multicast mode.
In multicast mode, it assumes an Any Source Multicast (ASM) group
model, where both one-to-many and many-to-many communication are
supported via a common group address in the range 224.0.0.0 through
239.255.255.255. To enable internet-wide multicast communication,
intra-domain routing protocols (those that operate only within a
single administrative domain, e.g., DVMRP [15], PIM [16][17]) are
used in combination with an Inter-domain routing protocol (those
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 2]
RTCP with Unicast Feedback
that operate across administrative domain borders, e.g., MBGP [18],
MSDP [19]). Such routing protocols enable a host to join a single
multicast group address and to send to or to receive data from all
members in the group with no prior knowledge of the membership.
There is a great deal of complexity involved, however at the routing
level to support such a multicast service in the network.
In addition, many-to-many communication is not always available, nor
desired by all group applications. For example, with Source-Specific
Multicast (SSM) and satellite communication, the multicast
distribution channel only supports source-to-receiver traffic. In
other cases, such as large ASM groups with a single active data
source and many passive receivers, it is sub-optimal to create a
full routing-level mesh of multicast sources just for the
distribution of RTCP control packets. Thus an alternative solution
is preferable.
Although a one-to-many multicast topology may simplify routing and
may be a closer approximation to the requirements of certain RTP
applications, unidirectional communication makes it impossible for
receivers in the group to share RTCP feedback information amongst
all other group members. Therefore, in this draft, we specify a
solution to this problem. We introduce unicast feedback as a new
method to distribute RTCP control information amongst all session
members. It is designed to operate under any group communication
model, ASM or SSM. The RTP data stream protocol itself is unaltered.
Scenarios under which the unicast feedback method could provide
benefit include but are not limited to:
a) SSM groups with a single sender.
The proposed extensions allow SSM groups that do not have many-
to-many communication capability to still receive RTP data
streams and to continue to participate in the RTP control
protocol, RTCP, by using multicast in the source-to-receiver
direction and using unicast to send receiver feedback to the
source on the standard RTCP port.
b) One-to-many broadcast networks.
Unicast feedback may also be beneficial to one-to-many broadcast
networks, such as a satellite network with a terrestrial low-
bandwidth return channel or a broadband cable link. Unlike the
SSM network, these networks may have the ability for a receiver
to multicast return data to the group. However, a unicast
feedback mechanism may be preferable for routing simplicity.
c) ASM with a single sender.
A unicast feedback approach may be used by an ASM application
with a single sender, as it would help to prevent overtaxing
multicast routing infrastructure that does not scale as
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 3]
RTCP with Unicast Feedback
efficiently. Because it is not more efficient than a standard
multicast group RTP communication scenario, it is not expected to
replace the traditional mechanism.
The modifications proposed in this document are intended to
supplement the existing RTCP feedback mechanisms described in [1],
Section 6.
3. Basic Operation
This draft proposes two new methods to enable unicast receiver
feedback. Each involves the unicasting of RTCP packets to a source
whose job it is to re-distribute the information to the members of
the group. The source must be able to communicate with all group
members in order for either mechanism to work.
The first method, the 'Simple Feedback Model', is a basic reflection
mechanism whereby all Receiver RTCP packets are unicast to the
source and subsequently forwarded by the source to all receivers on
the multicast RTCP channel. The advantage of using this method is
that an existing receiver implementation requires little
modification in order to use it. Instead of sending reports to a
multicast address, a receiver uses a unicast address to send reports
to the source, yet still receives forwarded RTCP traffic on the
multicast control data channel. This method also has the advantage
of being backwards compatible with standard RTP/RTCP
implementations.
The second method, the 'Sender Feedback Summary Model', is a
summarised reporting scheme that provides savings in bandwidth by
consolidating Receiver Reports at the source into one summary packet
that is then distributed to all the receivers. The advantage of this
scheme is apparent for large group sessions where the basic
reflection mechanism outlined above generates a large amount of
packet forwarding when it replicates all the information to all the
receivers. The basic operation of the scheme is similar to the first
method in that receivers send feedback via unicast to the source. In
the second scheme, however the source distributes summaries of the
feedback over the multicast channel. Thus this technique requires
that all session members understand the new summarised packet format
outlined in Section 7.1. Additionally, the summarised scheme
provides an optional mechanism to send distribution information or
histograms about the feedback data reported by the whole group.
Potential uses for the compilation of distribution information are
addressed in Section 7.4.
To differentiate between the two reporting methods, a new SDP
identifier is created and discussed in Section 10. The reporting
method MUST be decided prior to the start of the session. A
distribution source MUST NOT change the method during a session.
In a session using SSM, the network SHOULD prevent any multicast
data from the receiver being distributed further than the first hop
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 4]
RTCP with Unicast Feedback
router. Additionally, any data heard from a non-unicast capable
receiver by other hosts on the same subnet SHOULD be filtered out by
the host IP stack and therefore will not cause problems with respect
to the calculation of the Receiver RTCP bandwidth share.
4. Definitions
Distribution Source:
In an SSM context, only one source distributes RTP data and
redistributes RTCP information to all receivers. That source is
called the distribution source. In order for unicast feedback
to work, there MUST be only one session distribution source for
any subset of receivers to which RTCP feedback is directed.
Note that heterogeneous networks comprised of ASM multiple-
sender groups, unicast-only clients and/or SSM single-sender
receiver groups MAY be connected via translators or mixers to
create a single-source group (see Section 9 for details).
RTP and RTCP Channels:
The data distributed from the source to the receivers is
referred to as the RTP channel and the control information the
RTCP channel. With standard RTP/RTCP, these channels typically
share the same multicast address but are differentiated via
port numbers as specified in [1]. In an SSM context, the RTP
channel is multicast, whereas the RTCP or feedback channel is
actually the collection of unicast channels between each
receiver and the source.
Unicast RTCP Feedback Target:
For a session defined as having a distribution source A, on
ports n for the RTP channel and k for the RTCP channel, the
unicast RTCP feedback target is the IP address of Source A on
port k unless otherwise stated in the session description. See
Section 10 for details on how the address is specified.
SSRC:
Synchronization source. A 32-bit value that uniquely identifies
each member in a session. See [1] for further information.
Report blocks:
Report block is the standard terminology for an RTCP reception
report. RTCP [1] encourages the stacking of multiple report
blocks in Sender Report (SR) and Receiver Report (RR) packets.
As a result, a variable size feedback packet may be created by
one source that reports on multiple other sources in the group.
The summarised reporting scheme builds upon this model through
the inclusion of multiple summary report blocks in one packet.
However, stacking of reports from multiple receivers is not
permitted in the simple feedback scheme.
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 5]
RTCP with Unicast Feedback
5. Packet types
The RTCP packet types defined in [1], [6], and [10] are:
Type Description Payload number
-------------------------------------------------------
SR Sender Report 200
RR Receiver Report 201
SDES Source Description 202
BYE Goodbye 203
APP Application-Defined 204
RTPFB Generic RTP feedback 205
PSFB Payload-specific feedback 206
XR RTCP Extension 207
This document defines one further RTCP packet format:
Type Description Payload number
---------------------------------------------------------
RSI Receiver Summary Information 208
Within the Receiver Summary Information packet there are various
types of information that may be reported and encapsulated in
optional sub-report blocks:
Report Block Type Description Identifier number
------------------------------------------------------------------
IPv4 Address IPv4 Unicast Feedback address 0
IPv6 Address IPv6 Unicast Feedback address 1
DNS name DNS name for Unicast Feedback 2
- - reserved - 3
Loss Loss distribution 4
Jitter Jitter distribution 5
RTT Round trip time distribution 6
Cumulative loss Cumulative loss distribution 7
Collisions SSRC collision list 8
Stats General statistics 10
Receiver BW RTCP Receiver Bandwidth 11
- - reserved - 13 - 255
As with standard RTP/RTCP, the various reports may be combined into
a single RTCP packet, which should not exceed the path MTU. Packets
continue to be sent at a rate that is inversely proportional to the
group size in order to scale the amount of traffic generated.
6. Simple feedback model
6.1 Packet Formats
The simple feedback model uses the same packet types as traditional
RTCP feedback described in [1]. Receivers still generate Receiver
Reports with information on the quality of the stream received from
the source. The distribution source still must create Sender Reports
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 6]
RTCP with Unicast Feedback
that include timestamp information for stream synchronisation and
round trip time calculation. Both senders and receivers are required
to send SDES packets as outlined in [1]. The rules for generating
BYE and APP packets as outlined in [1] also apply.
6.2 Distribution Source behaviour
For the simple feedback model, the source MUST provide a basic
packet reflection mechanism. It is the default behaviour for any
distribution source and is the minimum requirement for acting as a
source to a group of receivers using unicast RTCP feedback.
In this model, the source MUST not stack report blocks received from
different SSRCs into one packet for retransmission to the group.
Every RTCP packet from each receiver MUST be reflected individually.
The source (the unicast feedback target) MUST listen for unicast
RTCP data sent to the RTCP port. All unicast data received on this
port MUST be forwarded by the source to the group on the multicast
RTCP channel. If the application can determine that the destination
address of an RTCP packet is not a unicast address, the packet MUST
NOT be forwarded but processed as defined in [1].
The reflected traffic SHOULD NOT be included in the transmission
interval calculation by the source. In other words, the source
SHOULD NOT consider reflected packets as part of its own control
data bandwidth allowance. However, they MUST be processed by the
source and the average RTCP packet size, RTCP transmission rate, and
RTCP statistics must be calculated. The algorithm for computing the
allowance is explained in Section 9.
If an application wishes to use APP packets, it is recommended that
the simple feedback model be used since it is likely that all
receivers in the session will need to hear the APP-specific packets.
The same applies for all other RTCP packets that are not defined in
the base RTP specification [1]. The decision to use the simple
feedback model MUST be made in advance of the session and MUST be
indicated in the SDP announcement [5].
6.3 Receiver behaviour
Receivers listen on the RTP channel for data and the RTCP channel
for control. Each receiver calculates its share of the control
bandwidth R/n, based on the standard rule that a fraction of the
RTCP bandwidth, R, allocated to receivers is divided equally between
the number of unique receiver SSRCs in the session, n. See Section 9
for further information on the calculation of the bandwidth
allowance. When a receiver is eligible to transmit, it sends a
unicast Receiver Report packet to the RTCP port of the distribution
source.
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 7]
RTCP with Unicast Feedback
7. Sender feedback summary model
In the sender feedback summary model, the Distribution Source is
required to summarise the information received from all the Receiver
Reports generated by the receivers and place the information into
summary reports. The sender feedback summary model introduces a new
report block format and a number of optional sub-report block
formats. The Receiver Summary Information report (RSI) is required
and MUST be sent by a source if the summarised feedback mechanism is
selected. Transmission of sub-report types is OPTIONAL. They MAY be
appended to the RSI report block to provide more detailed
information on the overall session characteristics reported by all
receivers and also to convey important information such as the
feedback address and reporting bandwidth.
From an RTP perspective, the Distribution Source acts like an RTP
receiver but it is not counted in the receiver bandwidth allocation
(as it summarizes information provided by the other receivers);
nevertheless, the Distribution Source's transmission rate MUST
adhere to RTCP bandwidth limitations for receivers. Any
summarization data MUST be appended to a Receiver Report (RR) packet
generated by the distribution source and forwarded to the receiver
group. If the distribution source is actually an RTP sender, even if
it is the only session sender, it MUST also generate Sender Report
(SR) packets.
The Distribution Source MUST use an SSRC value for transmitting
summarization information and MUST perform proper SSRC collision
detection and resolution.
Editor's note: Here, we can also optimize for the common case
(Distribution Source == sender) and reduce the forward bit
rate. However, the generalized way always requiring the
Distribution Source to be a receiver with its own SSRC appears
to be much cleaner; but this comes at the cost of some extra
bit rate.
The Distribution Source MUST send at least one Receiver Summary
Information packet for each reporting interval. The distribution
source can additionally stack sub-report blocks after the RSI
packet. Each sub-report block corresponds to the initial RSI packet
and acts as an enhancement to the basic summary information required
by the receivers to calculate their reporting time interval. For
this reason, additional sub-report blocks are not required but
recommended. RSI and the corresponding sub-report blocks are sent in
addition to the standard receiver-issued packets, such as Receiver
Reports and SDES packets outlined in [1].
7.1 Packet Formats
7.1.1 RSI: Receiver Summary Information Packet
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 8]
RTCP with Unicast Feedback
The RSI report block has a fixed header size followed by a variable
length report:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=RSI=208 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: optional report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RSI packet includes the following fields:
length: 16 bits
As defined in [1], the length of the RTCP packet in 32-bit words
minus one, including the header and any padding.
SSRC: 32 bits
The SSRC of the distribution source.
Timestamp: 64 bits
Indicates the wallclock time, which is seconds relative to 0h UTC
on 1 January 1900, when this report was sent. This value is used
to enable detection of duplicate packets, reordering and to
provide a chronological profile of the feedback reports.
Group size: 32 bits
This field provides the sender's view of the number of receivers
in a session. This MUST include the sender itself and any other
senders potentially connected to the session, e.g., via a
mixer/translator gateway. The group size is calculated according
to the rules outlined in [1].
The group size field MAY be left empty (indicated by a value of
0); if so, the RTCP Bandwidth report block MUST be present to
indicate the per-receiver RTCP bandwidth.
7.1.2 Optional Sub-Report Block Types
For RSI reports, this document also introduces a sub-report block
format specific to the RSI packet. The sub-report blocks are
appended to the RSI packet using the following generic format. All
sub-report blocks MUST be 32-bit aligned.
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 9]
RTCP with Unicast Feedback
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRBT-specific data +
| |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SRBT: 8 bits
Sub-Report Block Type. The sub-report block type identifier. The
values for the sub-report block types are defined in section 5.
Length: 8 bits
The length of the sub-report in 32-bit words.
SRBT-specific data: <Length*4 - 2> octets
This field may contain type-specific information based upon the
SRBT value.
7.1.3 Generic Sub-Report Block Fields
For the sub-report blocks that convey distributions of values (Loss,
Jitter, RTT, Cumulative Loss), a flexible 'data bucket' style report
is used. This divides the data set into variable size buckets that
are interpreted according to the guide fields at the head of the
report block.
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
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SRBT | Length | NDB | MF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Distribution Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Distribution Value |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Distribution Buckets |
| ... |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The SRBT and Length fields are calculated as explained in section
7.1.2.
Number of distribution buckets (NDB): 12 bits
The number of distribution buckets of data. The size of the
bucket can be calculated using the formula ((length * 4) -
12)*8/NDB number of bits. The calculation is based upon the
length of the whole sub-report block in octets (length field * 4)
minus the header of 12 octets. Providing 12 bits for the NDB
field enables bucket sizes as small as 2 bits for a full length
packet of MTU 1500 bytes. The bucket size in bits must always be
divisible by 2 to ensure proper byte alignment. A bucket size of
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 10]
RTCP with Unicast Feedback
2 bits is fairly restrictive, however, and it is expected that
larger bucket sizes will be more practical for most
distributions.
Multiplicative Factor (MF): 4 bits
MF+1 indicates the multiplicative factor to be applied to each
distribution bucket value. Possible values are 0 - 15,
indicating multiplicative factors of 1 - 16.
Length: 8 bits
The length field tells the receiver the full length of the sub-
report block in 32-bit words (i.e. length * 4 bytes), and enables
the receiver to identify the bucket size. For example, given no
MTU restrictions, the data portion of a distribution packet may
be only as large as 1008 bytes (255 * 4 - 12), providing up to
4032 data buckets of length 2 bits, or 2016 data buckets of
length 4 bits etc...
Minimum distribution value (min): 32 bits
The minimum distribution value, in combination with the maximum
distribution value, indicates the range covered by the data
bucket values.
Maximum distribution value (max): 32 bits
The maximum distribution value, in combination with the minimum
distribution value, indicates the range covered by the data
bucket values. The significance and range of the distribution
values is defined in the individual profiles for each
distribution type (DT).
Distribution buckets: each bucket is ((length * 4) - 12)*8/NDB bits
The size and number of buckets is calculated as outlined above
based upon the value of NDB and the length of the packet. The
values for distribution buckets are equally distributed;
according to the following formula, distribution bucket x (with 0
<= x < NDB) covering the value range:
[ min+(max-min)/NDB*x ; min+(max-min)/NDB*(x+1) ]
Interpretation of the minimum, maximum and distribution values in
the sub-report block are profile-specific and are addressed
individually in the sections below. The size of the sub-report block
is variable, as indicated by the packet length field.
7.1.4 Loss sub-report block
The loss sub-report block allows a receiver to determine how its own
reception quality relates to the other recipients. A receiver may
use this information, e.g. to drop out of a session (instead of
sending lots of error repair feedback) if it finds itself isolated
at the lower end of the reception quality scale.
Chesterfield, et al. Internet Draft - Expires Jan 2005 [Page 11]
RTCP with Unicast Feedback
The loss sub-report block indicates the distribution of losses as
reported by the receivers to the distribution source. Values are
expressed as a fixed-point number with the binary point at the left
edge of the field similar to the "fraction lost" field in SR and RR
packets as defined in [1]. The sub-report block type (SRBT) is 4.
Valid results for the minimum distribution value field are 0 - 254.
Similarly, valid results for the maximum distribution value field
are 1 - 255. The minimum distribution value MUST always be less than
the maximum.
For examples on processing summarised loss report sub-blocks, see
the Appendix.
7.1.5 Jitter sub-report block
A jitter sub-report block indicates the distribution of the
estimated statistical variance of the RTP data packet interarrival
time reported by the receivers to the distribution source. This
allows receivers both to place their own observed jitter values in
context with the rest of the group, and to approximate dynamic
parameters for playout buffers. See [1] for details on how the
values are calculated and the relevance of the jitter results.
Jitter values are measured in timestamp units and expressed as
unsigned integers. The minimum distribution value must alw