Internet Engineering Task Force Chesterfield/Schooler/Ott
Internet Draft U. Cambridge/AT&T Labs/GmbH
draft-ietf-avt-rtcpssm-02.txt November 2002
Expires: May 2003
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.
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
4. Definitions.....................................................5
5. Packet types....................................................6
6. Simple feedback model...........................................6
Chesterfield Internet Draft - Expires May 2003 [Page 1]
RTCP with Unicast Feedback
7. Sender feedback summary model...................................7
8. Mixer/Translator issues........................................15
9. Transmission interval calculation..............................16
10. SDP Extensions................................................17
11. Security Considerations.......................................18
12. Backwards Compatibility.......................................24
13. IANA Considerations...........................................25
14. Outstanding Issues............................................25
15. References....................................................25
16. Appendix......................................................26
A Distribution Report processing at the receiver.................26
B Distribution Report creation at the source......................28
C AUTHORS ADDRESSES...............................................31
D FULL COPYRIGHT STATEMENT........................................32
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 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 in a
session, enabling group size estimation and the distribution or
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 a unicast mode or in the traditional
multicast mode of Any Source Multicast (ASM) group communication,
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. Typical intra-domain routing protocols, that is
protocols that operate only within a single administrative domain,
that enable such communication are the Distance Vector Multicast
Routing Protocol (DVMRP) [2] or Protocol Independent Multicast (PIM)
[3][4]. Typically these are used in combination with an Inter-domain
routing protocol, that is to say a protocol that operates across
administrative domain borders, such as the Multi-protocol extension
to the Border Gateway Protocol (MBGP) [5] in combination with the
Chesterfield Internet Draft - Expires May 2003 [Page 2]
RTCP with Unicast Feedback
Multicast Source Discovery Protocol (MSDP) [6]. 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 across any multicast-enabled
portion of the internet. In order to enable such a service in the
network, however there is a great deal of complexity involved at the
routing level.
The any-to-any mode of communication however is not always desired
or, in some cases, even available. The recent popularity of Source
Specific Multicast (SSM) is one such example where the multicast
distribution channel is only available for the source-to-receiver
traffic. In other cases such as large ASM groups with a single
active data source and many passive receivers, it is not optimal to
create at the routing level a full mesh of multicast sources just
for the distribution of control packets and an alternative solution
is preferable.
The effect of using a unidirectional broadcast topology for RTP is
that it removes the ability for receivers in the group to
communicate RTCP control information with all other members in the
group, whether for reasons of resource economy or availability. In
this draft, therefore, we define a solution to this problem. We
introduce unicast feedback as a new method to distribute control
information amongst all members in a multicast session. It is
designed to operate under any group communication scenario (ASM or
SSM). The RTP data stream protocol itself is unaffected. The basic
architectural models to 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 unicasting the data to the source on the
standard RTCP port.
b) One-to-many broadcast networks.
An example of such a network is a satellite network with a
terrestrial low-bandwidth return channel or a broadband cable
link. Unlike the SSM network, this communication architecture may
have the ability for a receiver to multicast return data to the
group, however, a unicast feedback mechanism is likely to be
preferable for routing simplicity.
c) ASM with a single sender.
An SDP [16] session announcement may identify a session as having
a single sender receiving unicast RTCP feedback. Receivers join
the multicast group address and receive RTP and RTCP data from
the source on the specified address/port combinations. The RTCP
feedback is unicast back to the source on the RTCP port. The
unicast feedback approach may help to prevent overtaxing
multicast routing infrastructure that does not scale as
Chesterfield Internet Draft - Expires May 2003 [Page 3]
RTCP with Unicast Feedback
efficiently. However, it is not more efficient than a standard
multicast group RTP communication scenario, and therefore 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 receiver feedback to
all members in a session. 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 always be able to
communicate with all group members in order for either mechanism to
work.
The content of receiver RTCP traffic will continue to include
Receiver Reports (RRs) and Session Description (SDES) information
since they are never active sources in the session. Additionally,
Goodbye (BYE) packets and Application-defined (APP) packets may also
be transmitted. 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.
The first method, the 'Simple Feedback Model', is a basic 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 yet still receives RTCP traffic in
on the multicast control data channel. This method also has the
advantage of being backwards compatible with RTP/RTCP
implementations that do not support unicast feedback to the source
and that operate using the standard multicast group communication
model, ASM. In a session that uses ASM, such a receiver would
multicast reports to the group address and designated RTCP port as
stated in [1]. The reports would be directly received by all
members. 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.
The second method, the 'Sender Feedback Summary Model', is a
summarised reporting scheme that provides savings in bandwidth by
consolidating all the 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
Chesterfield Internet Draft - Expires May 2003 [Page 4]
RTCP with Unicast Feedback
the basic forwarding mechanism outlined above would create a large
amount of packet replication in order to forward all the information
to all the receivers. The basic operation of the scheme is the same
as the first method. However it 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 about the feedback data reported by
the whole group. Potential uses for the compilation of distribution
information are addressed in the Appendix.
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.
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].
Unicast RTCP Feedback Target: For a session defined as having a
distribution source A, on ports n and k, 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: RTCP [1] encourages the stacking of multiple report
blocks in Sender and Receiver Report packets. As a result, a
variable size feedback packet is created and sent from one source
that pertains to multiple other sources in the group. In this draft,
the method of stacking report blocks is extended in Generic Summary
Report packets, where a source optionally may stack multiple reports
into one packet in order to provide additional feedback on the RTCP
traffic received from the group.
Chesterfield Internet Draft - Expires May 2003 [Page 5]
RTCP with Unicast Feedback
5. Packet types
The RTCP packet types defined in [1] are:
Type Description Payload number
SR Sender Report 200
RR Receiver Report 201
SDES Source Description 202
BYE Goodbye 203
APP Application-Defined 204
XR RTCP Extension 205
Recent extensions to the RTCP reporting format have been proposed in
[17] to provide a generic structure to facilitate the introduction
of more data types. This format, defined in the previous list as
payload type XR=205, is leveraged in this draft to introduce a new
report type and several sub-report extension options.
The RTCP extension report provides an identifier field called Block
Type that specifies the extension report type that follows. To
implement unicast feedback, we define a new Block Type identifier
referred to as the Receiver Summary Information (RSI) report and a
series of sub-block types that can be appended to the RSI packet.
The new Block Type is:
Block Type Description Identifier number
RSI Receiver Summary Information 24
And the sub-types are:
Sub-block Type Description Identifier number
Collisions SSRC collision list 1
Address Unicast Feedback address 2
Loss Loss distribution 3
Jitter Jitter distribution 4
RTT Round trip time distribution 5
Cumulative loss Cumulative loss distribution 6
Stats General statistics 7
6. Simple feedback model
6.1 Packet Formats
The simple feedback model uses the same packet types as standard
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 Internet Draft - Expires May 2003 [Page 6]
RTCP with Unicast Feedback
6.2 Distribution Source behaviour
For the simple feedback model, the source provides 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.
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 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 the destination address of an RTCP packet
as being multicast, any such data 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. The algorithm for computing the allowance
is explained in Section 9. The control traffic included in the
bandwidth calculation includes any Sender Reports to the group,
along with any additional SDES and APP packets.
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 [16].
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 based on the standard rule that 75% of the RTCP bandwidth
is divided equally between all unique SSRCs in the session. 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
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
Chesterfield Internet Draft - Expires May 2003 [Page 7]
RTCP with Unicast Feedback
sent by a source if the summarised feedback mechanism is selected.
The OPTIONAL sub-report types 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 block
for each reporting interval. The sender can additionally stack sub-
reports 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, sub-report blocks are not
required but recommended. RSI and corresponding sub-report blocks
are sent in addition to the standard receiver-issued packets, such
as Sender Reports and SDES packets outlined in [1].
7.1 Packet Formats
As defined in [17] the XR packet provides a fixed header block of 8
octets, modeled along the same lines as the RTCP report headers:
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=XP=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this case the length field corresponds to the whole of the XP
packet, including the appended RSI report block and the sub-report
blocks.
The RSI report block has a fixed header size of 4 octets 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=RSI=24 | type-specific | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: type-specific data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BT: 8 bits
Block Type. As defined in [17] this is the block type identifier
number. For RSI reports, the type number is 24.
7.1.1 RSI: Receiver Summary Information Report Block
Chesterfield Internet Draft - Expires May 2003 [Page 8]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=24 |type-specific=0| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver RTCP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: sub-blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RSI report includes the following fields:
BT: 8 bits
The block type of this report, see Section 5 for further details.
Timestamp: 32 bits
The time the packet was sent. This is an unsigned integer value
displayed in NTP timestamp units 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].
Receiver RTCP bandwidth: 32 bits (make optional?)
Indicates the maximum bandwidth allocated to any single 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.
7.1.2 Optional Sub-Block Types
In addition to the new Block Type definition for RSI reports, this
document also introduces a new sub-block report format specific to
the RSI packet. The sub-blocks are appended to the RSI report using
the following generic format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBT | SBT-specific | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chesterfield Internet Draft - Expires May 2003 [Page 9]
RTCP with Unicast Feedback
SBT: 8 bits
Sub-Block Type. The sub-block type identifier.
SBT-specific: 16 bits
This field may contain type-specific information based upon the
SBT value.
Length: 8 bits
The length of the sub-report in 4 byte units. The full length of
the report in bytes is calculated by multiplying the length value
by 4.
7.1.3 Generic Sub-Block Fields
For the sub-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 read based upon 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
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SBT | NDB | MF | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Distribution Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Distribution Value |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Distribution Buckets |
| ... |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The SBT 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 the data. The size of the
bucket can be calculated using the formula, number of bits equals
((length * 4) - 12)*8/NDB. The calculation is based upon the
length of the whole packet 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. 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
Indicates the multiplicative factor to be applied to each
distribution Bucket value. Possible values are 1 - 15.
Length: 8 bits
Chesterfield Internet Draft - Expires May 2003 [Page 10]
RTCP with Unicast Feedback
The length field tells the receiver the full length of the packet
and enables the receiver to identify the bucket size based on the
calculation ((length * 4) - 12)*8/NDB. Therefore the maximum data
portion of a distribution packet may be 1008 bytes, which would
provide up to 4032 data buckets of length 2 bits, or 2016 data
buckets of length 4 bits etc...
Minimum distribution value: 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: 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 depends upon the value of NDB and
the length of the packet. In order to calculate the size of the
bucket, the formula ((length * 4) - 12)*8/NDB should be used.
This indicates the division of the data space and the size of
each data point in bits. Each value must be multiplied by the
multiplicative factor.
Interpretation of the minimum, maximum and distribution values in
the report block are profile-specific and are addressed individually
in the sections below. The size of the report block is variable, as
indicated by the packet length field.
7.1.4 Loss report block
A loss 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. The sub-block type (SBT) is 3.
Valid results for the minimum distribution value field are 0 - 99.
Similarly, valid results for the maximum distribution value field
are 1 - 100. The minimum distribution value MUST always be less than
the maximum.
For examples on processing GSR loss report blocks, see the Appendix.
7.1.5 Jitter report block
A jitter 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. See [1] for
details on how the values are calculated and the relevance of the
Chesterfield Internet Draft - Expires May 2003 [Page 11]
RTCP with Unicast Feedback
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-block type (SBT) is 4.
7.1.6 Round Trip Time report block
A round trip time report indicates the distribution of round trip
times from the distribution source to the receivers. 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-block type (SBT) is 5.
7.1.7 Cumulative Loss report block
The cumulative loss field, in contrast to the Average Fraction Lost
field, in a Receiver Report [1] 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-
block type (SBT) is 6.
7.1.8 Feedback Address Target 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBT=2 | Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 8 bits
The IP address version of the attached variable length field.
E.g. A value of 4 corresponds to IPv4, a value of 6 corresponds
to Ipv6.
Length: 8 bits
The length of the report block in 4 octet units. For an Ipv4
address this should be 2 (e.g. Total length = 2 * 4 = 8 Octets).
For an Ipv6 address this should be 33.
7.1.9 Collisions report block
Chesterfield Internet Draft - Expires May 2003 [Page 12]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBT=1 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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. On receipt of the packet,
receiver(s) MUST detect the collision and select another SSRC.
7.1.10 General Statistics 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SBT=7 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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.
Average interarrival jitter: 32 bits
Average 'interarrival jitter' value out of all RTCP RR packets
since the last RSI from the receiver set.
7.2 Distribution Source behaviour
The source is responsible for accepting RTCP packets from the
receivers, interpreting and storing the per-receiver information as
defined in [1]. The importance of this is apparent when creating the
RSI and sub-block reports, since incorrect information can have
serious implications. Section 11 addresses the security risks in
detail.
Chesterfield Internet Draft - Expires May 2003 [Page 13]
RTCP with Unicast Feedback
Either the group size or the Receiver RTCP Bandwidth fields MUST be
included. A sender has the option of masking the group size by
setting it to a value of choice, however the receiver bandwidth
field MUST be included. If both are included, the bandwidth field
MUST override the Session bandwidth/group size calculation as
outlined in [1]. The Receiver RTCP Bandwidth field, therefore
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 field, the source MUST
continue to forward Sender Reports and RSI packets at the rate
allowed by its bandwidth allocation. See Section 9 for further
details about the frequency of reports.
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 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 trade-off between the
granularity of the data and the accuracy based on the factorisation
values, 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 GSR information.
The results should correspond as near as possible to the values
received during the interval since the last report. The source may
stack as many 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 MTU of the connection.
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
Chesterfield Internet Draft - Expires May 2003 [Page 14]
RTCP with Unicast Feedback
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 portrayed 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 analysing 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 value
provides the receiver with the data necessary to calculate its share
of the RTCP bandwidth. The Receiver RTCP Bandwidth field may
override this value. The Receiver RTCP Bandwidth field provides the
source with the capability to control the amount of feedback from
the receivers.
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. Appendix A provides further information and examples of data
processing at the receiver.
The receiver SHOULD assume that any 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 Internet Draft - Expires May 2003 [Page 15]
RTCP with Unicast Feedback
8.1 Use of a mixer-translator
The mixer-translator MUST adhere to the SDP description [16] 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 + LJS 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 which is intended to be supplied by a session management
application (e.g., [9]) or decided based upon the bandwidth of a
single sender in a session. A receiver MUST calculate the number of
other members in a session based upon either its own SSRC count
determined by the number of forwarded Receiver Reports, or from the
group size field in the RSI report from a sender.
The RTCP transmission Interval calculation remains the same as in
the original RTP specification [1]. In the original specification,
the senders are allocated 1/4 of the control traffic bandwidth if
they number 25% or less than the group size. Otherwise the
allocation for senders is the percentage of senders to group size.
The remaining bandwidth is allocated to the receivers to be divided
evenly amongst the group. The source should calculate the
transmission interval for RSI + LJS packets out of its 1/4 of the
control traffic bandwidth with a minimum transmission interval of 5
seconds.
Chesterfield Internet Draft - Expires May 2003 [Page 16]
RTCP with Unicast Feedback
10. SDP Extensions
The Session Description Protocol (SDP) [16] 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 additional parameter to specify the mode of
operation.
rtcp:unicast reflection -- MUST be used to indicate packet
reflection 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(s) 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 done following the proposal for SDP source filters
documented in draft-ietf-mmusic-sdp-srcfilter-00.txt [15].
From this specification, only the inclusion mode ("a=incl:") MUST be
used for SSM RTCP.
There SHOULD be exactly one "a=incl:" attribute listing the address
of the sender. The RTCP port MUST be derived from the m= line of
the media description.
An optional alternative feedback address may be supplied using an
attribute such as a=rtcp:<port> IN IP4 192.168.1.1.
Chesterfield Internet Draft - Expires May 2003 [Page 17]
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 presents an analysis of the security weaknesses
introduced by the feedback mechanism, identifying the potential
threats and specifying the measures that MUST be adopted to address
the issues. Any Suggestions on increasing the level of security
provided to RTP sessions above the current standard are RECOMMENDED
but OPTIONAL.
11.1 Assumptions
RTP/RTCP is a protocol for carrying real-time multimedia traffic,
and therefore one of the main considerations for any security
solution must be to maintain as low an overhead as possible in order
to limit processing constraints. This includes the consideration of
overhead for different applications and types of cryptographic
operations, as well as considerations for deploying or creating
security infrastructure for large groups.
The distribution of session parameters, typically using type
information through SAP, email or the web is beyond the scope of
this document. It is recommended, however, that the method used
should employ adequate security measures to ensure the integrity and
authenticity of the information. For the purposes of this analysis,
it is assumed that the information has already been securely
distributed out-of-band. This work is in progress within the Gsec
working group, which is addressing the security implications of
distributing session announcements.
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. All security weaknesses are therefore addressed
from a transport level perspective or above.
11.2 Security threats
Attacks on this architecture may take a variety of forms, and in
order to identify the security weaknesses, it is important to
address these individually.
a) Denial of Service
A major area of concern would be a denial of service attack. Due
to the nature of the communication architecture this is a
situation that could be generated a number of ways by using the
unicast feedback characteristic to the attackers advantage.
b) Packet Forgery
One potential area of attack to guard against is packet forgery.
In particular, it is important to protect against the integrity
of certain influential packets since compromise of certain
control packets could directly affect the transmission
characteristics of the whole group, however for the purposes of
Chesterfield Internet Draft - Expires May 2003 [Page 18]
RTCP with Unicast Feedback
defining a security profile at this stage, every packet is
considered equally as important. This decision may be revisited
in future revisions as the requirements emerge more clearly. It
is clear, however that in the case of a large group, the
compromise of RTCP traffic could have serious consequences.
c) Session Replay
An additional concern is the potential for session recording and
subsequent replay. The issue to deal with in particular in this
instance is that an attacker may not actually need to understand
the packet contents, but just simply have the ability to record
the data stream and at a later time replay it to any receivers
that are listening. This would be less effective than a direct
denial of service attack, since the integrity of the original
session packets would not be affected, however the feedback at
that time by the receiver group to the source would be
unexpected.
d) Eavesdropping on a session
The consequences of eavesdropping by an attacker on a session may
not directly constitute a security weakness, however it might
benefit other types of attack, and should therefore be considered
as a potential threat. For example, an attacker might be able to
use the information to perform an intelligent DoS attack.
11.3 Security properties
The following security types are relevant to this draft and will be
addressed in greater detail in subsequent sections.
a) Data integrity
Ensures that any third party has not tampered with the data
received from the network, either maliciously or through a
network error. This property ensures that the packet received is
guaranteed to be in exactly the same condition as intended, and
that what is received can be confirmed as being from an
authenticated source.
b) Data authenticity
Ensures the origin of the message can either be uniquely
identified, or in the case of group authentication can be
identified as coming from a specific trusted group of sources.
c) Data confidentiality
Ensures that the only receiver(s) that can recover the plaintext
is the intended receivers, therefore in order to restrict access
only to authorized entities, confidentiality is required. It does
not prevent eavesdroppers receiving the ciphertext but does
guarantee that they cannot recover the plaintext.
d) Replay protection
This prevents an attacker from re-using the packet via simple
replay without necessarily having to recover the plaintext.
Chesterfield Internet Draft - Expires May 2003 [Page 19]
RTCP with Unicast Feedback
11.4 Architectural Contexts
In order to understand the potential weaknesses to guard against, it
is necessary to divide the communication model into a number of
distinct contexts.
a) Source to Receiver communication
The first, and perhaps most influential context to protect, is
the 'downstream' communication channel from the source to the
receivers. This is effectively the main controlling influence
over the behaviour of the group since it determines the bandwidth
allocation for each receiver and hence the rate at which the RTCP
traffic is directly unicast back to the source. All traffic that
is distributed over the downstream channel should be generated by
a single source. Both the RTP data stream and the RTCP control
data are sent over this channel. The RTCP data is indirectly
influenced by the information the source has received from the
whole group.
This context is vulnerable to all four attacks outlined in the
previous section. A denial of service attack from the source to
the receivers is possible, but less of a concern since the worst
case effect of sending large volumes of traffic over the
distribution channel has the potential to reach every receiver,
but only on a one-to-one basis, this is no different from the
current multicast model where an individual source may send large
volumes of traffic to a multicast group. 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 which must also be guarded against.
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. Other
consequences of packet forgery in this context may be the
compromise of data affecting the integrity of the data received
both in the RTP stream itself and the RTCP data in general.
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 very 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.
Chesterfield Internet Draft - Expires May 2003 [Page 20]
RTCP with Unicast Feedback
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 and, if
unencrypted, might also provide valuable information on
characteristics such as group size and transmission
characteristics of the receivers back to the source in addition
to enabling an attacker to listen to the media streams. In this
context, the attacker might also have access to personal
information carried in the SDES packets such as email, phone and
full username information through traffic analysis.
b) Receiver to source or gateway communication
The second context to address is the return traffic from the
group to the source or gateway, which for the purposes of this
analysis may be considered in the same light as a distribution
source. This traffic should only be RTCP type data, and should
include receiver reports, SDES information 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 the first context with respect to
critical source RTCP control information would be witnessed most
seriously in the second 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.
In the event that packet forgery may occur in this context, the
effect may be the introduction of false RTCP traffic and/or the
creation of fake SSRC identifiers. Such an attack might slow down
the overall control channel data rate, since an incorrect
perception of the group size may be created. This might affect
external issues such as group accounting and other as yet unknown
potential uses of the distribution functionality for controlling
group behaviour such as leader election based on feedback
criteria.
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. It is therefore equally as
important to protect against compromise of any receiver
contribution to the RTCP channel, as it is to ensure authenticity
and freshness of the data source.
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.
Chesterfield Internet Draft - Expires May 2003 [Page 21]
RTCP with Unicast Feedback
11.5 Requirements in each context
Some initial requirements to consider for each context in general
are that the overhead of ensuring the security of the session should
be kept as low as possible. This entails keeping the setup and
communication of keys to a minimum. The nature of RTP/RTCP traffic
is that sessions require real-time processing and minimal overhead
for communication. This means that processing constraints imposed by
the required cryptographic techniques are an important consideration
in defining this security profile.
Having identified the security weaknesses for each communication
context, security type requirements can be addressed for each.
a) The first context is concerned with 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 are
required. 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 second context must defend against the same kinds of attacks
but is 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 receiver's RTCP traffic is not
accomplished. 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 such as leader election based on various
parameters. In order to ensure data integrity, receiver
authenticity is therefore also RECOMMENDED to guarantee the
origin of the data. 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
of the session via channels such as an HTTP server, email or SAP. As
it is beyond the scope of this document to place any requirements on
the external communication of such information, no further analysis
Chesterfield Internet Draft - Expires May 2003 [Page 22]
RTCP with Unicast Feedback
is included here, however it is highly RECOMMENDED that wherever
possible an implementor or user of the protocol should attempt to
identify the source of the information.
11.6 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 have 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
potentially an 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 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 Discussion of suitable security solutions
This section presents some existing security mechanisms that would
be suitable for addressing 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 adequately address
the requirements.
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
Chesterfield Internet Draft - Expires May 2003 [Page 23]
RTCP with Unicast Feedback
session announcements. Other methods might involve HTTPS or signed
email content from a trusted source.
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, however MIKEY [18] is the preferred system by the
authors.
A more general group security profile which might be used is the
Group Domain of Interpretation [19], which defines the 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 just using a shared key or on an
individual basis. 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.
TESLA [20] 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.
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
Chesterfield Internet Draft - Expires May 2003 [Page 24]
RTCP with Unicast Feedback
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.
13. IANA Considerations
Based on the guidelines suggested in [10], this document proposes 1
new RTCP XR block type for consideration by IANA, and 6 new sub-
block types for summary distribution types, defined in section 5.
Furthermore, four new SDP media-level attributes are defined in
Section 10.
14. Outstanding Issues
None outstanding.
15. References
[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP -
A Transport Protocol for Real-time Applications," Internet
Draft, draft-ietf-avt-rtp-new-10.txt, Work in Progress, July 2001.
[2] Pusateri, T, "Distance Vector Multicast Routing Protocol",
draft-ietf-idmr-dvmrp-v3-10, August 2000
[3] Fenner, B, Handley, M, Holbrook, H, Kouvelas, I, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", draft-ietf-pim-sm-v2-new-02.txt, March 2001
[4] Farinacci, D, Kouvelas, I, Windisch, K, "State Refresh in PIM-
DM" draft-ietf-pim-refresh-02.txt, November, 2000
[5] Thaler, D, Cain, B, "BGP Attributes for Multicast Tree
Construction", draft-ietf-idmr-bgp-mcast-attr-00.txt, February 1999
[6] Farinacci, D, Rekhter, Y, Meyer, D, Lothberg, P, Kilmer, H,
Hall, J, "Multicast Source Discovery Protocol (MSDP)", draft-ietf-
msdp-spec-06.txt, July 2000
[7] Shepherd, G, Luczycki, E, Rockell, R, "Source-Specific Protocol
Independent Multicast in 232/8", draft-shepherd-ssm232-00.txt, March
2000.
[8] Holbrook, H, Cain, B, "Using IGMPv3 For Source-Specific
Multicast", draft-holbrook-idmr-igmpv3-ssm-00.txt, July 2000.
[9] Session Directory Rendez-vous (SDR), developed at University
College London by Mark Handley and the Multimedia Research Group.
Chesterfield Internet Draft - Expires May 2003 [Page 25]
RTCP with Unicast Feedback
[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[11] Handley, M, Perkins, C, Whelan, E, "Session Announcement
Protocol", (SAP), RFC 2974, October 2000.
[12] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
Netscape Communications Corp., Nov 18, 1996.
[13] Perrig, Canetti, Briscoe, Tygar, Song, "TESLA: Multicast Source
Authentication Transform", draft-irtf-smug-tesla-00.txt.
[14] E. Carrara, D. McGrew, M. Naslund, K. Norrman, D. Oran, "The
Secure Real Time Transport Protocol", draft-ietf-avt-srtp-01.txt.
[15] B. Quinn, "SDP Source-Filters", Internet Draft draft-ietf-
mmusic-sdp-srcfilter-00.txt, Work in Progress, May 2000.
[16] M. Handley, V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[17] T. Friedman, R. Caceres, K. Almeroth, K. Sarac, A. Clark, R.
Cole, K. Hedayat, "RTCP Reporting Extensions", draft-ietf-avt-rtcp-
report-extns-03.txt, October 2002.
[18] J. Arkko et al, "MIKEY: Multimedia Internet Keying", draft-
ietf-msec-mikey-04, September 2002.
[19] M. Baugher et al "The Group Domain of Interpretation", draft-
ietf-msec-gdoi-06, October 2002.
[20] A. Perrig, R. Canetti, B. Whillock, "TELSA: Multicast Source
Authentication Transform Specification", draft-ietf-msec-tesla-spec-
00, October 2002.
16. Appendix
A Distribution Report processing at the receiver
A.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))
Chesterfield Internet Draft - Expires May 2003 [Page 26]
RTCP with Unicast Feedback
A.2 Pseudo-code
Packet Variables -> factor,NDB,MnDVL,MaDV
Code variables -> xrange, ydata[NDB],x,y
xrange = MaDV - MnDV
x = MnDV;
for(i=0;i<NDB;i++) {
y = (ydata[i] * factor);
/*OUTPUT x and y values*/
x += (xrange / NDB);
}
A.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.
Chesterfield Internet Draft - Expires May 2003 [Page 27]
RTCP with Unicast Feedback
- 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
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.
B Distribution Report creation at the source
The following example demonstrates three different ways to convey
loss data using the generic format of a Loss 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
Chesterfield Internet Draft - Expires May 2003 [Page 28]
RTCP with Unicast Feedback
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
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 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
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)
Chesterfield Internet Draft - Expires May 2003 [Page 29]
RTCP with Unicast Feedback
Results, 16-bit buckets:
X - 0 - 9 | 10 - 19 | 20 - 29 | 30 - 39
Y - 13029 | 352 | 5460 | 855
Example - 2nd Method
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
Chesterfield Internet Draft - Expires May 2003 [Page 30]
RTCP with Unicast Feedback
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.
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 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.
C 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
schooler@research.att.com
Joerg Ott
Tellique Kommunikationstechnik GmbH
Berliner Str. 26
Chesterfield Internet Draft - Expires May 2003 [Page 31]
RTCP with Unicast Feedback
D-13507 Berlin
GERMANY
Phone: +49.30.43095-560 (sip:jo@tzi.org)
Fax: +49.30.43095-579
Email: jo@tellique.com
D 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."
