J. Chesterfield
University of Cambridge
E. Schooler
Internet Draft AT&T Labs - Research
Document: draft-ietf-avt-rtcpssm-06 J. Ott
Tellique GmbH
Expires: August 2004 16 February 2004
RTCP Extensions for Single-Source Multicast Sessions
with Unicast Feedback
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 a modification 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 possible or
not preferred. In addition, it can be applied to any group that
might benefit from a sender-controlled summarised reporting
mechanism.
Table of Contents
1. Conventions and Acronyms........................................2
2. Introduction....................................................2
3. Basic Operation.................................................4
Chesterfield Internet Draft - Expires July 2004 [Page 1]
RTCP with Unicast Feedback
4. Definitions.....................................................5
5. Packet types....................................................5
6. Simple feedback model...........................................6
7. Sender feedback summary model...................................7
8. Mixer/Translator issues........................................19
9. Transmission interval calculation..............................20
10. SDP Extensions................................................22
11. Security Considerations.......................................23
12. Backwards Compatibility.......................................29
13. IANA Considerations...........................................30
15. Bibliography..................................................31
16. Appendix: Distribution Report processing at the receiver......33
17.AUTHORS ADDRESSES..............................................38
18. IPR Notice....................................................39
19. FULL COPYRIGHT STATEMENT......................................39
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
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.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 2]
RTCP with Unicast Feedback
However, there is a great deal of complexity involved at the routing
level to support such a multicast service in the network.
In addition, many-to-many communication is not always available to,
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
efficiently. Because it is not more efficient than a standard
multicast group RTP communication scenario, it is not expected to
replace the traditional mechanism.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 3]
RTCP with Unicast Feedback
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.
Now 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
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.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 4]
RTCP with Unicast Feedback
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.
5. Packet types
The RTCP packet types defined in [1], [6], and [10] are:
Type Description Payload number
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 5]
RTCP with Unicast Feedback
-------------------------------------------------------
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
Number of Senders Indicates # senders in a session 12
- - 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
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.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 6]
RTCP with Unicast Feedback
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.
7. Sender feedback summary model
In the sender feedback summary model, the source is required to
summarise the information received from all the Receiver Reports
generated by the receivers and place the information into summary
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 7]
RTCP with Unicast Feedback
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.
The sender MUST send at least one Receiver Summary Information
packet for each reporting interval. The sender 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
sender-issued packets, such as Sender Reports and SDES packets
outlined in [1].
7.1 Packet Formats
7.1.1 RSI: Receiver Summary Information Packet
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
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 8]
RTCP with Unicast Feedback
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.
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.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 9]
RTCP with Unicast Feedback
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
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
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 10]
RTCP with Unicast Feedback
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.
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 always be
less than the maximum. The sub-report block type (SRBT) is 5.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 11]
RTCP with Unicast Feedback
7.1.6 Round Trip Time sub-report block
A round trip time sub-report indicates the distribution of round
trip times from the distribution source to the receivers, providing
receivers with a global view of the range of values in the group.
The distribution source is the only member of the group capable of
calculating the round trip time to any other members since it is the
only sender in the group. The sender has the option of distributing
these round trip time estimations to the whole group, uses of which
are described in Section 7.4. Round trip times are measured in
timestamp units and expressed as unsigned integers. The
multiplicative factor can be used to reduce the number of bits
required to represent the values. The minimum distribution value
MUST always be less than the maximum. The sub-report block type
(SRBT) is 6.
7.1.7 Cumulative Loss sub-report block
The cumulative loss field in a Receiver Report [1], in contrast to
the Average Fraction Lost field, is intended to provide some
historical perspective on the session performance. The distribution
is provided as a percentage figure based on the long term
accumulation of values. The sender must maintain a record of the
Cumulative number lost and Extended Highest Sequence number received
as reported by each receiver. Ideally the recorded values are from
the first report received. Future calculations are then based on
(the new cumulative loss value - the recorded value) / (new extended
highest sequence number - recorded sequence number) * 100. The sub-
report block type (SRBT) is 7.
7.1.8 Feedback Address Target sub-report block
The feedback address target block provides a dynamic mechanism for
the source to signal an alternative unicast RTCP feedback address to
the receivers. If this field is included, it MUST override any
static SDP address information for the session.
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={0,1,2} | Length | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 8 bits
The length of the sub-report block in 32-bit words. For an IPv4
address this should be 2 (e.g., Total length = 4 + 4 = 2*4
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 12]
RTCP with Unicast Feedback
Octets). For an IPv6 address this should be 5. For a DNS name,
the length field indicates the number of 32-bit words making up
the string plus 1 byte and any additional padding required to
reach the next word boundary.
Port: 2 octets (optional)
The port number to which receivers send feedback reports. A port
number of 0 is invalid and MUST NOT be used.
Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)
The address to which receivers send feedback reports. For IPv4
and IPv6 fixed-length address fields are used. A DNS name is an
arbitrary length string that is padded with null bytes to the
next 32 bit boundary. The string is UTF-8 encoded (RFC 2279).
For IPv4, SRBT=0. For IPv6, SRBT=1. And for the DNS name for
unicast feedback, SRBT=2.
A feedback target address block with a certain SRBT MUST NOT occur
more than once. Dual Numerical feedback target address blocks for
IPv4 and IPv6 MAY both be present. If so, the resulting transport
addresses MUST point to the same logical entity (i.e., the
distribution source).
If a feedback target address block with an SRBT indicating a DNS
name is present, there MUST NOT be any other numerical feedback
target address blocks present.
7.1.9 Collisions sub-report block
The collision SSRC sub-report provides the source with a mechanism
to report SSRC collisions amongst the group. In the event that a
non-unique SSRC is discovered based on the tuple [SSRC,CNAME], the
collision is reported in this block and the affected nodes must
reselect an SSRC identifier.
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=8 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Collision SSRC :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Collision SSRC: n x 32 bits
The final fields in the packet are used to identify any SSRCs
that are duplicated within the group. Usually this is handled by
the hosts upon detection of the same SSRC, however since
receivers in an SSM context no longer have a global view of the
session, the collision algorithm is handled by the source. SSRCs
that collide are listed in the packet. Each Collision SSRC is
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 13]
RTCP with Unicast Feedback
included repeatedly in Collision sub-report blocks and sent at
least five times. If more Collision SSRCs need to be reported
than fit into an MTU, the reporting is done in a round robin
fashion so that all Collision SSRCs have been reported once
before the second round of reporting starts. On receipt of the
packet, receiver(s) MUST detect the collision and select another
SSRC,
if the collision pertains to them.
7.1.10 General Statistics sub-report block
The general statistics sub-report block is used if specifying
buckets is deemed too complex. With the general statistics sub-
report block only cumulative values are reported back.
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=10 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFL | HCNL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Average fraction lost (AFL): 8 bits
The average fraction lost indicated by Receiver Reports forwarded
to this source, expressed as a fixed point number with the binary
point at the left edge of the field. A value of all '1's
indicates that the AFL field is not provided.
Highest cumulative number of packets lost (HCNL): 24 bits
Highest 'cumulative number of packets lost' value out of all RTCP
RR packets since the last RSI from any of the receivers. A value
of all '1's indicates that the HCNL field is not provided.
Average interarrival jitter: 32 bits
Average 'interarrival jitter' value out of all RTCP RR packets
since the last RSI from the receiver set. A value of all '1's
indicates that this field is not provided.
7.1.11 RTCP Bandwidth indication sub-report block
This sub-report block is used to inform the receivers about the
maximum total relative RTCP bandwidth that is used by (all) the
sender(s) or about the maximum total bandwidth allowance for all
receivers.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 14]
RTCP with Unicast Feedback
| SRBT=11 | Length |S|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTCP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender (S): 1 bit
The contained bandwidth value applies to all RTCP senders.
Receivers (R): 1 bit
The contained bandwidth value applies to all RTCP receivers.
Reserved: 14 bits
MUST be set to zero upon transmission and ignored upon reception.
RTCP Bandwidth: 32 bits
If the S bit is set to 1, this field indicates the maximum
bandwidth allocated to each individual sender. This informs the
receivers about the RTCP report frequency to expect from the
senders. This is a fraction value indicating a percentage of the
session bandwidth, expressed as a fixed-point number with the
binary point at the left edge of the field.
If the R bit is set to 1, this field indicates the maximum
bandwidth allocated per receiver for sending RTCP data relating
to the session. This is a fraction value indicating a percentage
of the session bandwidth, expressed as a fixed-point number with
the binary point at the left edge of the field. Each receiver
MUST use this value for its bandwidth allowance.
This report block SHOULD only be used when the Group Size field in
the RSI header is set to 0.
7.1.12 Number of Senders sub-report block
This sub-report block is used to inform the RTP entities in a
session about the number of active senders in the group. If this
report block is not included in a RSI packet, a default of 1 is
assumed.
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=12 | Length | # senders |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# senders: 16 bits
This field indicates the number of active senders.
7.2 Distribution Source behaviour
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 15]
RTCP with Unicast Feedback
The source is responsible for accepting RTCP packets from the
receivers, and interpreting and storing per-receiver information as
defined in [1]. The importance of providing these functions is
apparent when creating the RSI and sub-report block reports, since
incorrect information can have serious implications. Section 11
addresses the security risks in detail.
As defined in [1], all RTCP reports from the source MUST be
prepended with an SR report and any relevant SDES fields. Either the
Group size field MUST be valid in the RSI header or the Receiver
RTCP Bandwidth sub-report block MUST be included. If there is more
than a single sender, the distribution source SHOULD include a
Number of Senders sub-report block to provide accurate information
on bandwidth allocation to the receivers.
A sender has the option of masking the Group size by setting it to
0. However, the Receiver RTCP Bandwidth sub-report block field MUST
be included. If both are included, the Receiver RTCP Bandwidth sub-
report block MUST take precedence.
The Receiver RTCP Bandwidth sub-report block provides the source
with the capability to control the amount of feedback from the
receivers and MAY be increased or decreased based on the
requirements of the source. Regardless of the value selected by the
source for the Receiver RTCP Bandwidth sub-report block, the source
MUST continue to forward Sender Reports and RSI packets at the rate
allowed by the total RTCP bandwidth allocation. See Section 9 for
further details about the frequency of reports.
A distribution source MAY start out reporting Group sizes and switch
to Receiver RTCP Bandwidth reporting later on and vice versa. If the
distribution source does so, it SHOULD ensure that the
correspondingly indicated values for the Receiver RTCP Bandwidth
roughly match, i.e., are at least the same order of magnitude.
In order to identify SSRC collisions, the source is responsible for
maintaining a record of each SSRC and the corresponding CNAME within
at least one reporting interval by the group in order to
differentiate between clients. It is RECOMMENDED that an updated
list of more than one interval be maintained to increase accuracy.
This mechanism should prevent the possibility of collisions since
the combination of SSRC and CNAME should be unique, if the CNAME is
generated correctly. If collisions are not detected, the source will
have an inaccurate impression of the group size. Since the
statistical probability is very low that collisions will both occur
and be undetectable, this should not be a significant concern. In
particular, the clients would have to randomly select the same SSRC
and have the same username + IP address (e.g., using private address
space behind a NAT router).
For the optional sub-report blocks, the source MAY decide which are
the most significant feedback values to convey and MAY choose not to
include any. The packet format provides flexibility in the amount of
detail conveyed by the data points. There is a tradeoff between the
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 16]
RTCP with Unicast Feedback
granularity of the data and the accuracy of the data based on the
multiplicative factor (MF), the number of buckets, and the min and
max values. In order to focus on a particular region of a
distribution, the source can adjust the minimum and maximum values,
and either increase the number of buckets and possibly the
factorisation, or decrease the number of buckets and provide more
accurate values. See Appendix B for detailed examples on how to
convey a summary of RTCP Receiver Reports as RSI sub-report block
information.
For each value the distribution source decides to include in an RSI
packet, it MUST adhere to the following measurement rules.
a) If the distribution source intends to use a sub-report to convey
a distribution of values (sections 7.1.3 to 7.1.7), it MUST keep
per receiver state, i.e., remember the last value V reported by
the respective receiver. If a new value is reported by a
receiver, the existing value MUST be replaced by the new one.
The value MUST be deleted (along with the entire entry) if the
receiver is timed out (as per section 6.3.5 of [1]) or has sent
a BYE packet (as per section 6.3.7 of [1]).
All the values collected in this way MUST be included in the
creation of the subsequent distribution sub-report block.
The results should correspond as closely as possible to the
values received during the interval since the last report. The
source may stack as many sub-report blocks as required in order
to convey different distributions. If the distribution size
exceeds the largest packet length (1008 bytes data portion),
more packets MAY be stacked with additional information up to
the link MTU.
Note: This intentionally provides persistent full coverage of
the entire session membership to avoid oscillations due to
changing membership samples.
b) If the distribution source intends to report a short summary
using the format defined in section 7.1.10, for EACH of the
values included in the report (AFL, HCNL, average interarrival
jitter), it MUST keep a timer T_summary as well as three
entries: V, V', and V" (indicated as Vi, with i=0,1,2). The
respective value V is included in each report sent.
The summary values are included here to reflect the current
group situation. By recording the last three reporting intervals
the source incorporates reports from all members while allowing
for individual RTCP receiver report packet losses. The process
of collecting these values also aims to avoid resetting any of
the values and then having to send out an RSI report based upon
just a few values collected.
The timer constant T_summary MUST be initialized as T_summary =
1.5*Td, where Td is the reporting interval, and MUST be updated
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 17]
RTCP with Unicast Feedback
following timer reconsideration whenever the Group size or the
average RTCP size ("avg_rtcp_size") changes. This choice should
allow each receiver to report once per interval.
V, V', and V" are initialized to an "empty" value. Because 0
and -1 are sometimes valid values, here are guidelines on how to
initialize the empty value. If Vi indicates a signed maximum,
the empty value is Infinity, for an unsigned maximum it is 0.
If Vi indicates a (signed or unsigned) minimum, the empty value
is +Infinity. If Vi indicates an average, the empty value is 0
and an associated counter VNi is required which is also
initialized to 0.
As RTCP receiver reports are received by the distribution
source, the values V, V', and V" are updated as described below.
When T_summary expires, the assignments V = V' (V0=V1) and V' =
V" (V1=V2) are carried out and V" (V3) is initialized to
"empty".
Let VR be the newly received value. For a maximum calculation,
if Vr > Vi then Vi = Vr, otherwise Vi remains unchanged.
For a minimum calculation, if Vr < Vi then Vi = Vr, otherwise Vi
remains unchanged.
For an average calculation, Vi and VNi are updated as follows:
Vi = (Vi * VNi + Vr) / (VNi + 1)
VNi = VNi + 1
7.3 Receiver behaviour
The receiver MUST process RSI packets and adapt session parameters
such as the RTCP bandwidth based on the information received. The
receiver no longer has a global view of the session, and will
therefore be unable to receive information from individual receivers
aside from itself. However, the information conveyed by the source
can be extremely detailed, providing the receiver with an accurate
view of the session quality overall, without the processing overhead
associated with listening to and analyzing all Receiver Reports.
The SSRC collision list MUST be checked against the SSRC selected by
the receiver to ensure there are no collisions.
The Group size n allows a receiver to calculate its share of the
RTCP bandwidth, r. Given R, the total available RTCP bandwidth share
for receivers (in the SSM RTP session), and m, the number of senders
(either reported in the Number of Senders sub-report block or by
default set to 1), r = R/(n-m).
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 18]
RTCP with Unicast Feedback
The Receiver RTCP Bandwidth field MAY override this value. If the
Receiver RTCP Bandwidth field is present, the receiver MUST use this
value as its own RTCP reporting bandwidth r.
If the RTCP Bandwidth field was used by the distribution source in
an RTCP session but this field was not included in the last five
RTCP RSI reports, the receiver MUST revert to calculating its
bandwidth share based upon the Group size information.
If the receiver has not obtained any RTCP RSI packets from the
distribution source for a period of five times the sender reporting
interval, it MUST cease transmitting RTCP receiver reports until the
next RTCP RSI packet is received.
The receiver can use the summarised data as desired. This data is
most useful in providing the receiver with a more global view of the
conditions experienced by other receivers, and enables the client to
place itself within the distribution and establish the extent to
which its reported conditions correspond to the group reports as a
whole. The appendix (section 16) provides further information and
examples of data processing at the receiver.
The receiver SHOULD assume that any sub-report blocks in the same
packet correspond to the same data set received by the source during
the last reporting time interval. This applies to packets with
multiple blocks, where each block conveys a different range of
values.
8. Mixer/Translator issues
The original RTP specification allows a session to use mixers and
translators which help to connect heterogeneous networks into one
session. There are a number of issues, however, which are raised by
the unicast feedback model proposed in this document. The term
'mixer' refers to devices that provide data stream multiplexing
where multiple sources are combined into one stream. Conversely, a
translator does not multiplex streams, but simply acts as a bridge
between two distribution mechanisms, e.g., a unicast-to-multicast
network translator. Since the issues raised by this draft apply
equally to either a mixer or translator, they are referred to from
this point onwards as mixer-translator devices.
A mixer-translator between distribution networks in a session must
ensure that all members in the session receive all the relevant
traffic to enable the usual operation by the clients. A typical use
may be to connect an older implementation of an RTP client with an
SSM distribution network, where the client is not capable of
unicasting feedback to the source. In this instance the mixer-
translator must join the session on behalf of the client and send
and receive traffic from the session to the client. Certain hybrid
scenarios may have different requirements.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 19]
RTCP with Unicast Feedback
8.1 Use of a mixer-translator
The mixer-translator MUST adhere to the SDP description [5] for the
single source session (Section 10) and use the feedback mechanism
indicated. Receivers SHOULD be aware that by introducing a mixer-
translator into the session, more than one source may be active in a
session since the mixer-translator may be forwarding traffic from
either multiple unicast sources or from an ASM session to the SSM
receivers. Receivers SHOULD still forward unicast RTCP reports in
the usual manner to the distribution source, which in this case
would be the mixer-translator itself. It is RECOMMENDED that the
simple packet reflection mechanism be used under these circumstances
since attempting to coordinate RSI + summarisation reporting between
more than one source may be complicated unless the mixer-translator
is capable of undertaking the summarisation itself.
8.2 Encryption and Authentication issues
Encryption and security issues are discussed in detail in Section
11. A mixer-translator MUST be able to follow the same security
policy as the client in order to unicast forward RTCP feedback to
the source, and it therefore MUST be able to apply the same
authentication and/or encryption policy required for the session.
Transparent bridging, where the mixer-translator is not acting as
the distribution source, and subsequent unicast feedback to the
source is only allowed if the mixer-translator can conduct the same
source authentication as required by the receivers. A translator may
forward unicast packets on behalf of a client, but SHOULD NOT
translate between multicast-to-unicast flows towards the source
without authenticating the source of the feedback address
information.
9. Transmission interval calculation
The Control Traffic Bandwidth referred to in [1] is an arbitrary
amount that is intended to be supplied by a session management
application (e.g., sdr [20]) or decided based upon the bandwidth of
a single sender in a session.
The RTCP transmission Interval calculation remains the same as in
the original RTP specification [1]. In the original specification,
the senders, S, and receivers, R, divide up the available RTCP
bandwidth according to the following rules. If S/(R+S) < 1/4, then a
fixed portion of 1/4 of the RTCP bandwidth is allocated to senders.
If S/(R+S) >= 1/4, senders receive the full share of S/(R+S). This
is to ensure that sender RTCP traffic is always announced regularly
for the benefit of new session members. The remaining bandwidth is
allocated to the receivers and is divided evenly amongst them.
9.1 Receiver RTCP Transmission
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 20]
RTCP with Unicast Feedback
If the distribution source is operating in simple feedback mode
(which may be indicated in the corresponding session description for
the media session but which the receiver also notices from the
absence of RTCP RSI packets), a receiver MUST calculate the number
of other members in a session based upon its own SSRC count derived
from the forwarded Receiver Reports it receives. The receiver MUST
calculate the average RTCP packet size from all the RTCP packets it
receives.
If the distribution source is operating in sender feedback summary
mode, the receiver MUST use either the group size field and the
average RTCP packet size field or the Receiver Bandwidth Field from
the respective RTCP RSI header fields.
A receiver uses these values as input to the calculation of the
deterministic calculated interval as per [1].
9.2 Distribution Source RTCP Transmission
If operating in simple feedback mode, the distribution source should
calculate the transmission interval for its Sender Reports and
associated RTCP packets based upon the above control traffic
bandwidth and should count itself the only RTP sender. Receiver
reports will be forwarded as they arrive without further
consideration. The distribution source MAY choose to validate that
all or selected receivers roughly adhere to the calculated bandwidth
constraints and MAY choose to drop excess packets for receivers that
do not. In all cases, the average RTCP packet size is determined
from the receivers' RTCP packets forwarded and those originated by
the distribution source.
If operating in sender feedback summary mode, the distribution
source does not share the forward RTCP bandwidth with any of the
receivers. Therefore, the distribution source SHOULD use the full
RTCP bandwidth for sender reports and associated RTCP packets, as
well as RTCP RSI packets. In this case, the average RTCP packet
size is only determined from the RTCP packets originated by the
distribution source.
The distribution source uses these values as input to the
calculation of the deterministic calculated interval as per [1].
9.3 Operation in conjunction with AVPF
If the RTP session is an AVPF session [10] (as opposed to a regular
AVP [11] session the receivers MAY modify their RTCP report
scheduling as defined in [10]. Use of AVPF does not affect the
sender RTCP transmission or forwarding behavior nor the sender's
summarization.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 21]
RTCP with Unicast Feedback
In the event that APP specific packets without a defined
summarisation format are to be used, the reflection mode of
operation MUST be adopted from the start.
10. SDP Extensions
The Session Description Protocol (SDP) [5] is used as a means to
describe media sessions in terms of their transport addresses,
codecs, and other attributes. Providing RTCP feedback via unicast as
specified in this document constitutes another session parameter
needed in the session description. Similarly, other single-source
multicast RTCP feedback parameters need to be provided, such as the
summarisation mode at the sender and the target unicast address to
which to send feedback information. This section defines the SDP
parameters that are needed by the proposed mechanisms in this draft
(and that also need to be registered with IANA).
10.1 SSM RTCP Session Identification
A new session level attributes MUST be used to indicate the use of
unicast instead of multicast feedback: "rtcp-unicast".
This attribute uses one parameter to specify the mode of operation.
Rtcp-unicast:reflection -- MUST be used to indicate the Simple
Feedback mode of operation where packet reflection is used by the
RTCP target (without further processing).
Rtcp-unicast:rsi -- MUST be used to indicate the "Receiver
Summary Information" mode of operation.
10.2 SSM Source Specification
In addition, in a Source-Specific Multicast RTCP session, the sender
needs (or senders need) to be indicated for both source-specific
joins to the multicast group, as well as for addressing unicast RTCP
packets on the backchannel from receivers to the source.
This is achieved by following the proposal for SDP source filters
documented in [4]. According to the specification, for SSM RTCP only
the inclusion mode ("a=source-filter:incl") MUST be used.
There SHOULD be exactly one "a=source-filter:incl" attribute listing
the address of the sender. The RTCP port MUST be derived from the
m= line of the media description.
An alternative feedback address and port may be supplied using the
SDP RTCP attribute [12], e.g., a=rtcp:<port> IN IP4 192.168.1.1.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 22]
RTCP with Unicast Feedback
11. Security Considerations
The level of security provided by the current RTP/RTCP model MUST
NOT be diminished by the introduction of unicast feedback to the
source. This section identifies the security weaknesses introduced
by the feedback mechanism, potential threats, and level of
protection that MUST be adopted. Any suggestions on increasing the
level of security provided to RTP sessions above the current
standard are RECOMMENDED but OPTIONAL. The final section outlines
some security frameworks that are suitable to conform to this
specification.
11.1 Assumptions
RTP/RTCP is a protocol that carries real-time multimedia traffic,
and therefore a main requirement is for any security framework to
maintain as low overhead as possible. This includes the overhead of
different applications and types of cryptographic operations, as
well as the overhead to deploy or to create security infrastructure
for large groups.
Although the distribution of session parameters, typically encoded
as SDP objects, through SAP [21], e-mail, or the web, is beyond the
scope of this document, it is RECOMMENDED that the distribution
method employs adequate security measures to ensure the integrity
and authenticity of the information. Suitable solutions that meet
the security requirements outlined here are included at the end of
this section.
In practice, the multicast and group distribution mechanism, e.g.,
the SSM routing tree, is not immune to source IP address spoofing or
traffic snooping. Therefore, all security weaknesses are addressed
from the transport level or above.
11.2 Security threats
Attacks on media distribution and the feedback architecture proposed
in this document may take a variety of forms. An outline of the
types of attacks in detail:
a) Denial of Service (DoS)
DoS is a major area of concern. Due to the nature of the
communication architecture a DoS can be generated in a number of
ways by using the unicast feedback channel to the attackers
advantage.
b) Packet Forgery
Another potential area for attack is packet forgery. In
particular, it is essential to protect the integrity of certain
influential packets since compromise could directly affect the
transmission characteristics of the whole group.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 23]
RTCP with Unicast Feedback
c) Session Replay
The potential for session recording and subsequent replay is an
additional concern. An attacker may not actually need to
understand packet content, but simply have the ability to record
the data stream and, at a later time, replay it to any receivers
that are listening.
d) Eavesdropping on a session
The consequences of an attacker eavesdropping on a session may
not directly constitute a security weakness, however it might
benefit other types of attack, and is therefore considered a
potential threat. For example, an attacker might be able to use
the eavesdropped information to perform an intelligent DoS
attack.
11.3 Architectural Contexts
To better understand the requirements of the solution, the threats
outlined above are addressed for each of the two communication
contexts:
a) Source-to-Receiver communication
The downstream communication channel, from the source to the
receivers, is critical to protect as it controls the behavour of
the group; it conveys the bandwidth allocation for each receiver
and hence the rate at which the RTCP traffic is unicast directly
back to the source. All traffic that is distributed over the
downstream channel is generated by a single source. Both the RTP
data stream and the RTCP control data from the source are
included in this context, with the RTCP data generated by the
source being indirectly influenced by the group feedback.
The downstream channel is vulnerable to four types of attacks. A
denial of service attack is possible, but less of a concern. The
worst case effect would be the transmission of large volumes of
traffic over the distribution channel with the potential to reach
every receiver, but only on a one-to-one basis. Consequently,
this threat is no more pronounced than the current multicast ASM
model. The real danger of denial of service attacks in this
context comes indirectly via compromise of the source RTCP
traffic. If receivers are provided with an incorrect group size
estimate or bandwidth allowance, the return traffic to the source
may create a distributed DoS effect on the source. Similarly, an
incorrect feedback address whether as a result of a malicious
attack or by mistake, e.g., an IP address typing error, could
directly create a denial of service attack on another host.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 24]
RTCP with Unicast Feedback
An additional concern relating to Denial of Service attacks would
come indirectly through the generation of fake BYE packets
causing the source to adjust the advertised group size. A
distribution source MUST follow the correct rules for timing out
members in a session prior to reporting a change in the group
size providing the authentic SSRC with sufficient time to
continue to report and consequently cancel the fake BYE report.
The danger of Packet forgery in the worst case may be to
maliciously instigate a denial of service attack, e.g. if an
attacker were capable of spoofing the source address and
injecting incorrect packets into the data stream or intercepting
the source RTCP traffic and modifying the fields.
The replay of a session would have the effect of recreating the
receiver feedback to the source address at a time when the source
is not expecting additional traffic from a potentially large
group. The consequences of this type of attack may be less
effective on their own, but in combination with other attacks
might be serious.
Eavesdropping on the session would provide an attacker with
information on the characteristics of the source to receiver
traffic such as the frequency of RTCP traffic. If RTCP traffic is
unencrypted, this might also provide valuable information on
characteristics such as group size and transmission
characteristics of the receivers back to the source.
b) Receiver-to-source or gateway communication
The second context is the return traffic from the group to the
source or gateway. This traffic should only consist of RTCP
packets, and should include receiver reports, SDES information,
BYE reports, extended reports (XR), feedback messages (RTPFB,
PSFB) and possibly Application specific packets. The effects of
compromise on a single or subset of receivers is less likely to
have as great an impact as the first context, however much of the
responsibility for detecting compromise of the source data stream
relies on the receivers.
The effects of compromise of critical distribution source control
information would be amplified most seriously in this context. A
large group of receivers may unwittingly generate a distributed
DoS attack on the source in the event that the integrity of the
source RTCP channel has been compromised and is not detected by
the individual receivers.
An attacker capable of instigating a packet forgery attack could
introduce false RTCP traffic and create fake SSRC identifiers.
Such attacks might slow down the overall control channel data
rate, since an incorrect perception of the group size may be
created. Similarly, the creation of fake BYE reports by an
attacker would cause some group size instability, but should not
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 25]
RTCP with Unicast Feedback
be effective as long as the correct timeout rules are applied by
the source in removing SSRC entries from its database.
A replay attack on receiver return data to the source would have
the same implications as the generation of false SSRC identifiers
and RTCP traffic to the source. Therefore, ensuring authenticity
and freshness of the data source is important.
Eavesdropping in this context may potentially provide an attacker
with a great deal of personal information about a large group of
receivers available from SDES packets. It would also provide an
attacker with information on group traffic generation
characteristics and parameters for calculating individual
receiver bandwidth allowance.
11.4 Requirements in each context
To address these threats, the following section presents the
security requirements in each context.
a) The main threat in the first context concerns denial of service
attacks through possible packet forgery. The forgery may take the
form of interception and modification of packets from the source,
or simply injecting false packets into the distribution channel.
To combat these attacks, data integrity and source authenticity
of the source traffic MUST be applied. The degree of
confidentiality which may be deployed is not a requirement in
this context since the actual consequences of eavesdropping do
not affect the operation of the protocol. However without
confidentiality, access to personal and group characteristics
information would be unrestricted to an external listener and it
is therefore recommended.
b) The threats in the second context also concern the same kinds of
attacks but are considered less important than the downstream
traffic compromise. All the security weaknesses are also
applicable to the current RTP/RTCP security model and therefore
only recommendations are made towards protection from compromise.
Data integrity is RECOMMENDED to ensure that interception and
modification of an individual receivers RTCP traffic can be
detected. This would protect against the false influence of group
control information and the potentially more serious compromise
of future services provided by the distribution functionality. In
order to ensure security, data integrity and authenticity of
receiver traffic is therefore also RECOMMENDED. The same
situation applies as in the first context with respect to data
confidentiality, and it is recommended that precautions should be
taken to protect the privacy of the data.
An additional security consideration that is not a component of this
specification but has a direct influence upon the general security
is the origin of the session initiation data. This involves the SDP
parameters that are communicated to the members prior to the start
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 26]
RTCP with Unicast Feedback
of the session via channels such as an HTTP server, email, SAP, or
other means. It is beyond the scope of this document to place any
strict requirements on the external communication of such
information, however suitably secure SDP communication approaches
are outlined in section 11.7.
11.5 Discussion of trust models
As identified in the previous sections, source authenticity is a
fundamental requirement of the protocol, however it is important to
also clarify the model of trust that would be acceptable to achieve
this requirement. There are two fundamental models that apply in
this instance:
a) The shared key model where all authorised group members share the
same key and can equally encrypt/decrypt the data. This method
assumes that an out-of-band method is applied to the distribution
of the shared group key ensuring that every key-holder is
individually authorized to receive the key, and in the event of
member departures from the group, a re-keying exercise can occur.
The advantage of this model is that the costly processing
associated with one-way key authentication techniques is avoided,
as well as the need to execute additional cipher operations with
alternative key sets on the same data set, e.g. in the event that
data confidentiality is also applied. The disadvantage is that
for very large groups where the receiver set becomes effectively
untrusted, a shared key does not offer much protection.
b) The public-key authentication model using cryptosystems such as
RSA-based or PGP authentication provides a more secure method of
source authentication at the expense of generating higher
processing overhead. This is typically not recommended for Real-
time data streams, but in the case of RTCP reports which are
distributed with a minimum interval of 5 seconds, this is a
viable option (the processing overhead might still be too great
for small, low-powered devices and should therefore be considered
with caution). Wherever possible, however the use of public key
source authentication is preferable to the shared key model
identified above.
As concerns requirements for protocol acceptability, either model is
acceptable, although it is RECOMMENDED that the more secure public-
key based options should be applied wherever possible.
11.7 Recommended security solutions
This section presents some existing security mechanisms that are
RECOMMENDED to suitably address the requirements outlined in section
11.5. This is only intended as a guideline and it is acknowledged
that there are many other solutions that would also be suitable in
order to be compliant with the specification.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 27]
RTCP with Unicast Feedback
11.7.1 Secure Distribution of SDP Parameters
a) SAP, HTTPS, Email - Initial distribution of the SDP parameters
for the session should use a secure mechanism such as the SAP
authentication framework which allows an authentication
certificate to be attached to the session announcements. Other
methods might involve HTTPS or signed email content from a
trusted source, however some commonly used techniques for
distributing session initiation information and starting media
streams are RTSP [8] and SIP [9].
b) RTSP - RTSP provides a client or server initiated stream control
mechanism for real-time multimedia streams. The session
parameters are conveyed using SDP syntax and may adopt standard
Transport Layer Security techniques such as are common in HTTP
transactions. In other words, in order to securely retrieve and
authenticate the source of the session description information
such as the multicast session address and the unicast feedback
identifier, the RTSP client and server should use a transport
level security transaction, e.g. SSL incorporating X.509 style
certificates.
c) SIP - A typical use of SIP involving a unicast feedback
identifier might be a client wishing to dynamically join a multi-
party call on a multicast address using unicast RTCP feedback.
The client would be required to authenticate the SDP session
descriptor information returned by the SIP server. The
recommended method for this, as outlined in the SIP specification
[9] is to use an S/MIME message body containing the session
parameters signed with an acceptable certificate. This would
provide the client with satisfactory knowledge of the
authenticity and integrity of the session descriptor information.
Other options exist within the SIP specification for establishing
authenticity of data such as end-to-end SIP message tunneling.
For the purposes of this profile, it is acceptable to use any
suitably secure authentication mechanism which establishes the
identity and integrity of the information provided to the client.
11.7.2 Suitable Security Solutions for RTP Sessions with Unicast
Feedback
a) SRTP - SRTP is the recommended AVT security framework for RTP
sessions. It specifies the general packet formats and cipher
operations that are used, and provides the flexibility to select
different stream ciphers based on preference/requirements. It can
provide confidentiality of the RTP and RTCP packets as well as
protection against integrity compromise and replay attacks. It
provides authentication of the data stream using the shared key
trust model. Any suitable key-distribution mechanism can be used in
parallel to the SRTP streams.
b) IPSEC - A more general group security profile which might be used
is the Group Domain of Interpretation [22], which defines the
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 28]
RTCP with Unicast Feedback
process of applying IPSec mechanisms to multicast groups. This
requires the use of ESP in tunnel mode as the framework and it
provides the capability to authenticate either using a shared key or
individually through public-key mechanisms. It should be noted that
using IPSec would break the 'transport independent' condition of RTP
and would therefore not be useable for anything other than IP based
communication.
c) TESLA - TESLA [23] is a scheme that provides a more flexible
approach to data authentication using time-based key disclosure. The
authentication uses one-way pseudo-random key functions based on key
chain hashes that have a short period of authenticity based on the
key disclosure intervals from the source. As long as the receiver
can ensure that the encrypted packet is received prior to the key
disclosure by the source, this requires loose time synchronization
between source and receivers, it can prove the authenticity of the
packet. The scheme does introduce a delay into the packet
distribution/decryption phase due to the key disclosure delay
however the processing overhead is much less than other standard
public-key mechanisms.
11.7.3 Secure Key Distribution Mechanisms
a) MIKEY - MIKEY [7] is the preferred solution for SRTP sessions
providing a shared group key distribution mechanism and intra-
session rekeying facilities.
b) GSAKMP - GSAKMP [x] is the general solution favoured for
Multicast Secure group key distribution. It is the recommended
key distribution solution for GDOI sessions.
12. Backwards Compatibility
The use of unicast feedback to the source should not present any
serious backwards compatibility issues. The RTP data streams should
remain unaffected, as are the RTCP packets from the source enabling
inter-stream synchronization in the case of multiple streams. The
unicast transmission of RTCP data to a source that does not have the
ability to reflect traffic by either mechanism could have serious
security implications as outlined in Section 11, but would not
actually break the operation of RTP. For RTP-compliant receivers
that do not understand the unicast mechanism, the RTCP traffic may
still reach the group, in the event that an ASM distribution network
is used, in which case there may be some duplication of traffic due
to the reflection channel, but this should be ignored. It is
anticipated, however that typically the distribution network will
not enable the receiver to multicast RTCP traffic, in which case the
data will be lost, and the RTCP calculations will not include those
receivers. It is RECOMMENDED that any session that may involve non-
unicast capable clients should always use the simple packet
reflection mechanism to ensure that the packets received can be
understood by all clients.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 29]
RTCP with Unicast Feedback
13. IANA Considerations
The following contact information shall be used for all
registrations included here:
Contact: Joerg Ott
mailto:jo@acm.org
tel:+49-421-201-7028
Based on the guidelines suggested in [2], this document proposes 1
new RTCP packet format to be registered with the RTCP Control Packet
type (PT) Registry:
Name: RSI
Long name: Receiver Summary Information
Value: 208
Reference: This document.
This document defines a substructure for RTCP RSI packets. A new
sub-registry needs to be set up for the sub-report block type (SRBT)
values for the RSI packet, with the following registrations created
initially:
Name: IPv4 Address
Long name: IPv4 Feedback Target Address
Value: 0
Reference: This document.
Name: IPv6 Address
Long name: IPv6 Feedback Target Address
Value: 1
Reference: This document.
Name: DNS Name
Long name: DNS Name indicating Feedback Target Address
Value: 2
Reference: This document.
Name: Loss
Long name: Loss distribution
Value: 4
Reference: This document.
Name: Jitter
Long name: Jitter Distribution
Value: 5
Reference: This document.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 30]
RTCP with Unicast Feedback
Name: RTT
Long name: Round-trip time distribution
Value: 6
Reference: This document.
Name: Cumulative loss
Long name: Cumulative loss distribution
Value: 7
Reference: This document.
Name: Collisions
Long name: SSRC Collision list
Value: 8
Reference: This document.
Name: Stats
Long name: General statistics
Value: 10
Reference: This document.
Name: RTCP BW
Long name: RTCP Bandwidth indication
Value: 11
Reference: This document.
Name: Number of senders
Long name: Number of senders in a session
Value: 12
Reference: This document.
The value 3 shall be reserved for a further way of specifying a
feedback target address. The value 3 MUST only be allocated for a
use defined in an IETF Standards Track document.
Further values may be registered on a first-come first-serve
basis. For each new registration, it is mandatory that a
permanent, stable, and publicly accessible document exists that
specifies the semantics of the registered parameter as well as the
syntax and semantics of the associated sub-report block. The
general registration procedures of [5] apply.
15. Bibliography
15.1 Normative References
[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP -
A Transport Protocol for Real-time Applications," RFC 3550, July
2003.
[2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 31]
RTCP with Unicast Feedback
[3] M. Baugher, D. McGrew, D. Oran, R. Blom, E. Carrara, M. Naslund,
and K. Norrman, "The Secure Real Time Transport Protocol",
Internet Draft draft-ietf-avt-srtp-09.txt, Work in Progress,
July 2003.
[4] B. Quinn, R. Finlayson, "SDP Source-Filters", Internet Draft
draft-ietf-mmusic-sdp-srcfilter-05.txt, Work in Progress, May
2003.
[5] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session
Description Protocol", Internet Draft draft-ietf-mmusic-sdp-new-
15, Work in Progress, October 2003.
[6] T. Friedman, R. Caceres, and A. Clark (eds), "RTCP Reporting
Extensions", Internet Draft, RFC 3611, November 2003.
[7] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman,
"MIKEY: Multimedia Internet Keying", Internet Draft draft-ietf-
msec-mikey-08.txt, Work in Progress, December 2003.
[8] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session
Initiation Protocol", RFC 3261, June 2002.
[10]J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey, "
Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)",
Internet Draft draft-ietf-ietf-avt-rtcp-feedback-08.txt, January
2004.
[11]H. Schulzrinne, S. Casner, " RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.
[12]C. Huitema, "RTCP Attribute in SDP", RFC 3605, October 2003.
[13]D. Meyer, R. Rockell, G. Shepherd, "Source-Specific Protocol
Independent Multicast in 232/8", Internet Draft draft-ietf-
mboned-ssm232-07.txt, Work in Progress, January 2004.
[14]H. Holbrook, B. Cain, B. Haberman, "Using IGMPv3 For Source-
Specific Multicast", Internet Draft draft-holbrook-idmr-igmpv3-
ssm-05.txt, Work in Progress, October 2003.
15.2 Informative References
[15]Pusateri, T, "Distance Vector Multicast Routing Protocol",
Internet Draft draft-ietf-idmr-dvmrp-v3-11.txt, Work in
Progress, October 2003.
[16]B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 32]
RTCP with Unicast Feedback
Specification (Revised)", Internet Draft, draft-ietf-pim-sm-v2-
new-08.txt, Work in Progress, October 2003.
[17]Adams, A, Nicholas, J, Siadak, W, "Protocol Independent
Multicast- Dense Mode (PIM-DM)", Internet Draft, draft-ietf-pim-
dm-new-v2-04.txt, Work in Progress, September, 2003.
[18]Bates, T, Rekhter, Y, Chandra, R, Katz, D, Multiprotocol
Extension fo BGP-4, RFC 2858, June 2000.
[19]D. Meyer, B. Fenner, "Multicast Source Discovery Protocol
(MSDP)", Experimental RFC 3618, October 2003.
[20]Session Directory Rendez-vous (SDR), developed at University
College London by Mark Handley and the Multimedia Research
Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/.
[21]M. Handley, C. Perkins, E. Whelan, "Session Announcement
Protocol (SAP)", RFC 2974, October 2000.
[22]M. Baugher, T. Hardjono, H. Harney, and B. Weis, "The Group
Domain of Interpretation", RFC 3547, July 2003.
[23]A. Perrig, R. Canetti, B. Whillock, "TELSA: Multicast Source
Authentication Transform Specification", Internet Draft draft-
ietf-msec-tesla-spec-00.txt, Work in Progress, April 2002.
[24]A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
Netscape Communications Corp., Nov 18, 1996.
16. Appendix: Distribution Report processing at the receiver
16.1 Algorithm
Example processing of Loss Distribution Values
X values represent the loss percentage.
Y values represent the number of receivers.
Number of x values is the NDB value
xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV)
First data point = MnDV,first ydata
then
Foreach ydata => xdata += (MnDV + (xrange / NDB))
16.2 Pseudo-code
Packet Variables -> factor,NDB,MnDVL,MaDV
Code variables -> xrange, ydata[NDB],x,y
xrange = MaDV - MnDV
x = MnDV;
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 33]
RTCP with Unicast Feedback
for(i=0;i<NDB;i++) {
y = (ydata[i] * factor);
/*OUTPUT x and y values*/
x += (xrange / NDB);
}
16.3 Application Uses and Scenarios
Providing a distribution function in a feedback message has a number
of uses for different types of applications. Although this section
enumerates potential uses for the distribution scheme, it is
anticipated that future applications might benefit from it in ways
not addressed in this document. Due to the flexible nature of the
summarisation format, future extensions may easily be added. Some of
the scenarios addressed in this section envisage potential uses
beyond a simple SSM architecture. For example, single-source group
topologies where every receiver may in fact also be capable of
becoming the source. Another example may be multiple SSM topologies,
which when combined, make up a larger distribution tree.
A distribution of values is useful as input into any algorithm,
multicast or otherwise, that could be optimized or tuned as a result
of having access to the feedback values for all group members.
Following is a list of example areas that might benefit from
distribution information:
- The parameterization of a multicast Forward Error Correction (FEC)
algorithm. Given an accurate estimate of the distribution of
reported losses, a source or other distribution agent, which does
not have a global view, would be able to tune the degree of
redundancy built in to the FEC stream. The distribution might help
to identify whether the majority of the group is experiencing high
levels of loss, or whether in fact the high loss reports are only
from a small subset of the group. Similarly, this data might enable
a receiver to make a more informed decision about whether it should
leave a group that includes a very high percentage of the worst-case
reporters.
- The organization of a multicast data stream into useful layers for
layered coding schemes. The distribution of packet losses and delay
would help to identify what percentage of members experience various
loss and delay levels, and thus how the data stream bandwidth might
be partitioned to suit the group conditions. This would require the
same algorithm to be used by both senders and receivers in order to
derive the same results.
- The establishment of a suitable feedback threshold. An application
might be interested to generate feedback values when above (or
below) a particular threshold. However, determining an appropriate
threshold may be difficult when the range and distribution of
feedback values is not known a priori. In a very large group,
knowing the distribution of feedback values would allow a reasonable
threshold value to be established, and in turn would have the
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 34]
RTCP with Unicast Feedback
potential to prevent message implosion if many group members share
the same feedback value. A typical application might include a
sensor network that gauges temperature or some other natural
phenomenon. Another example is a network of mobile devices
interested in tracking signal power to assist with hand-off to a
different distribution device when power becomes too low.
- The tuning of Suppression algorithms. Having access to the
distribution of round trip times, bandwidth, and network loss would
allow optimization of wake-up timers and proper adjustment of the
Suppression interval bounds. In addition, biased wake-up functions
could be created not only to favor the early response from more
capable group members, but also to smooth out responses from
subsequent respondents and to avoid bursty response traffic.
- Leader election among a group of processes based on the maximum or
minimum of some attribute value. Knowledge of the distribution of
values would allow a group of processes to select a leader process
or processes to act on behalf of the group. Leader election can
promote scalability when group sizes become extremely large.
16.4 Distribution Sub-report creation at the source
The following example demonstrates three different ways to convey
loss data using the generic format of a Loss sub-report block
(section 7.1.4). The same techniques could also be applied to
representing other distribution types.
1) The first method attempts to represent the data in as few bytes
as possible.
2) The second method, attempts to convey all the values, but in as
small a space as possible by using a multiplicative value.
3) The final example conveys all values without providing any
savings in bandwidth.
The second and third methods provide similar results, but as the
graphs indicate at the end of the example, the second method is
not as accurate as the third method.
Data Set
X values indicate loss percentage reported, Y values indicate the
number of receivers reporting that loss percentage
X - 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Y 1000| 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 |
103
X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19
Y - 74 | 21 | 30 | 65 | 60 | 80 | 6 | 7 | 4 | 5
X - 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29
Y - 2 | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 | 205
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 35]
RTCP with Unicast Feedback
X - 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39
Y - 163 | 174 | 103 | 94 | 76 | 52 | 68 | 79 | 42 | 4
Constant value
Due to the size of the multiplicative factor field being 4 bits, the
Maximum multiplicative value is 15.
The Distribution Type field of this packet would be value 1 since it
it represents loss data.
EXAMPLE - 1st Method
Description
The minimal method of conveying data, i.e., small amount of
bytes used to convey the values.
Algorithm
Attempt to fit the data set into a small sub-report size, selected
length 8 Octets
Option 1 - Can we split the range (0 - 39) into 16 4-bit values?
The maximum value would therefore be 5 - 7.5 which is 5970. This
will not fit into the 4-bit space using the maximum multiplicative
value.
Option 2 - Can we split the range (0 - 39) into 8 8-bit values?
The maximum value would therefore be 5 - 9 which is 6823. This will
not fit into the 8-bit space using the maximum multiplicative value.
Option 3 - Can we split the range (0 - 39) into 4 16-bit values?
The maximum value would therefore be 0 - 9 which is 13029. This will
fit into the 16-bit space using a multiplicative factor of 1. Only 1
sub-report block of length 8 bytes is necessary.
The packet fields will contain the values:
Header distribution Block
Distribution Type: 1
Number of Data Buckets: 4
Multiplicative Factor: 1
Packet Length field: 5 (5 * 4 => 20 Bytes)
Minimum Data Value: 0
Maximum Data Value: 39
Data Bucket values: 13029, 352, 5460, 855
(each value is 16-bits)
Results, 16-bit buckets:
X - 0 - 9 | 10 - 19 | 20 - 29 | 30 - 39
Y - 13029 | 352 | 5460 | 855
Example - 2nd Method
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 36]
RTCP with Unicast Feedback
Description
A semi-accurate method for representing data. This method wishes to
optimise the space used to convey results while representing every
value.
Algorithm
Attempt to convey all values, i.e. 40 buckets, but in the smallest
amount of space possible by using the multiplicative factor.
The maximum value is 3120. Using the maximum multiplicative factor
this will not fit into a 2, 4 or 6 bit space. The next minimum size
block is 8 bits. The maximum value of 3120 will fit into an 8 bit
space using the lowest possible multiplicative factor of 13.
Can the whole of the data set fit into a maximum size packet? The
maximum packet size is 1008 bytes. This will fit since there are
only 39 data points.
The packet fields will contain the values:
Header Distribution Block
Distribution Type: 1
Number of Data Buckets: 40
Multiplicative Factor: 13
Packet Length field: 13 (13 * 4 => 52 Bytes)
Minimum Loss Value: 0
Maximum Loss Value: 39
Data Portion
Results, 8-bit buckets:
X - 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Y - 77 | 62 | 0 | 138 | 200 | 240 | 177 | 85 | 15 | 8
X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19
Y - 6 | 2 | 2 | 5 | 5 | 6 | 0 | 1 | 0 | 0
X - 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29
Y - 0 | 1 | 7 | 177 | 89 | 21 | 18 | 16 | 15 | 16
X - 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39
Y - 13 | 13 | 8 | 7 | 6 | 4 | 5 | 6 | 3 | 0
Example - 3rd Method
Description
This demonstrates the most accurate method for representing the data
set. This method doesn't attempt to optimise any values.
Algorithm
Identify the highest value and select buckets large enough to convey
the exact values, i.e. no multiplicative factor.
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 37]
RTCP with Unicast Feedback
The highest value is 3120. This requires 12 bits (closest 2 bit
boundary) to represent, therefore it will use 60 bytes to represent
the entire distribution. This is within the max packet size,
therefore all data will fit within one sub-report block. The
multiplicative value will be 1.
The packet fields will contain the values:
Header Distribution Block
Distribution Type: 1
Number of Data Buckets: 40
Multiplicative Factor: 1
Packet Length field: 18 (18 * 4 => 72 Bytes)
Minimum Loss Value: 0
Maximum Loss Value: 39
Bucket values are the same as initial data set.
Result
The selection of which of the three methods outlined above might be
determined by a congestion parameter, or a user preference. The
overhead associated with processing the packets is likely to differ
very little between the techniques. The savings in bandwidth are
apparent however, using 20, 52 and 72 octets respectively. These
values would vary more widely for a larger data set with less
correlation between results.
17.AUTHORS ADDRESSES
Julian Chesterfield
University of Cambridge
Computer Laboratory,
JJ Thompson Avenue,
Cambridge, CB3 0FD, UK
Julian.chesterfield@cl.cam.ac.uk
Eve Schooler
AT&T Labs - Research
75 Willow Road
Menlo Park, CA 94025
eve_schooler@acm.org
Joerg Ott
Tellique Kommunikationstechnik GmbH
Berliner Str. 26
D-13507 Berlin
GERMANY
Phone: +49.30.43095-560 (sip:jo@tzi.org)
Fax: +49.30.43095-579
Email: jo@tellique.com
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 38]
RTCP with Unicast Feedback
18. IPR Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
19. FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Chesterfield, et al. Internet Draft - Expires July 2004 [Page 39]
