J. Chesterfield
E. Schooler
Internet Draft AT&T Labs - Research
Document:draft-ietf-avt-rtcpssm-01 J. Ott
Tellique Kommunikationstechnik
GmbH
Expires: December 2002 June 2002
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
Chesterfield Internet Draft - Expires December 2002 [Page 1]
RTCP with Unicast Feedback
5. Packet types....................................................6
6. Simple feedback model...........................................7
7. Sender feedback summary model...................................8
8. Mixer/Translator issues........................................16
9. Transmission interval calculation..............................17
10. SDP Extensions................................................17
11. Security Considerations.......................................18
12. IANA Considerations...........................................24
13. Outstanding Issues............................................24
14. Acknowledgements..............................................24
15. References....................................................24
16. Appendix......................................................26
A GSR packet processing at the receiver..........................26
B GSR packet creation at the source...............................27
C AUTHORS ADDRESSES...............................................28
D FULL COPYRIGHT STATEMENT........................................28
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 via 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
Chesterfield Internet Draft - Expires December 2002 [Page 2]
RTCP with Unicast Feedback
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
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.
An alternative approach has been developed for multicast groups with
just a single data sender. The Source Specific Multicast (SSM) [7]
model provides a simpler alternative in that it removes a great deal
of the routing complexity involved in multicast group creation and
source information distribution. In creating such a simplification,
however the SSM model defines a clear separation between the data
source and the multicast receiver group. As a consequence the
multicast distribution is uni-directional providing only one source
with the capability to communicate to the whole group.
SSM sessions are typically assigned a value in the group address
range 232.0.0.0 through 232.255.255.255, although this is not a
requirement. A session may be assigned any valid multicast address,
as long as the local network is configured to allow source-specific
joins outside the suggested SSM range. In order for a host to
receive traffic from an SSM capable source, it must support the
IGMPv3 multicast group membership reporting protocol [19], which
enables the host to explicitly request traffic from a (source,group)
pair. An SDP syntax is defined in Section 10 to specify the mode of
operation for the session and the session characteristics such as
the (source, group) identifier and feedback address.
The effect of using an SSM channel for RTP is that the ability for
receivers in the group to communicate RTCP control information with
all other members in the group is not provided by default. In order
to explicitly enable this at the routing level, receivers would be
required to join to an SSM channel from every other member of the
group. The creation of such a routing mesh, however would clearly
contradict the initial intention of introducing SSM in the first
place, and would likely be less efficient than using ASM.
In this draft, therefore we define a solution to this problem. We
introduce a new method for distributing control information amongst
all members in a multicast session that is designed to operate under
any multicast group communication scenario. It is, however, of
particular benefit to SSM sessions in the absence of receivers being
able to communicate with other members directly. The RTP data stream
protocol itself is unaffected. The basic architectural models to
which the unicast feedback method could provide benefit include:
Chesterfield Internet Draft - Expires December 2002 [Page 3]
RTCP with Unicast Feedback
a) SSM groups with a single sender.
This is the main motivation behind the unicast RTCP feedback
mechanism. 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 more
preferable simply for routing simplicity.
c) ASM with a single sender.
An SDP [16] session announcement type 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
efficiently. However, it is not more efficient than a standard
multicast group RTP communication scenario, and therefore is not
recommended 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. For certain distribution networks, such as SSM networks,
this may be a requirement, whereas in others it is an optional
feature that may be used.
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 include Receiver Reports
(RRs) and Session Description (SDES) information since they are
never active sources in the session. Additionally, Application
defined (APP) packets may also be transmitted. The various reports
are combined into a single RTCP packet which should not exceed the
path MTU. Packets are sent at a rate that is inversely proportional
to the group size in order to scale the amount of traffic generated.
Chesterfield Internet Draft - Expires December 2002 [Page 4]
RTCP with Unicast Feedback
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 and still receives RTCP traffic on
the 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
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 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
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 the members in the
session 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 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.
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).
Chesterfield Internet Draft - Expires December 2002 [Page 5]
RTCP with Unicast Feedback
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, using ports n for RTP and k for RTCP ,
the unicast RTCP feedback target is the IP address of Source A
on port k unless otherwise stated in the session description.
Note that typically n is an even port number and k=n+1;
however, certain circumstances such as the presence of NATs
may require deviating from these rules. 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.
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
These remain unmodified. Two new packet types are introduced in this
draft. Later profile extensions may be added to these which are not
covered in [1] or this document.
The new packet types are:
type description Payload number
RSI Receiver Summary Information [see Section 12]
GSR General Summary Report [see Section 12]
Within the General Summary Report packet, various types of
distribution data may be reported, each of which requires a
Chesterfield Internet Draft - Expires December 2002 [Page 6]
RTCP with Unicast Feedback
distribution type identifier. Distribution types defined in this
document are:
Distribution Type Number
Packet Loss 1
Receiver Jitter 2
Round Trip Time estimation 3
SSRC distribution 4
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.
6.2 Distribution Source behaviour
For the simple feedback model, the source provides a simple 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. Any multicast
data received on this port MUST NOT be forwarded but processed as
defined in [1].
The reflected traffic MUST NOT be included in the transmission
interval calculation by the source. In other words, the source MUST
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
Chesterfield Internet Draft - Expires December 2002 [Page 7]
RTCP with Unicast Feedback
feedback model MUST be made in advance of the session and MUST be
indicated in the SDP announcement [16].
When reflecting traffic, it is recommended that the source SHOULD
attempt to avoid generating bursts of packets whenever buffer
playout smoothing is possible.
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 sender 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 two new
packets. The Receiver Summary Information packet (RSI), which MUST
be sent by a source if the summarised feedback mechanism is
selected, and the OPTIONAL General Summary Report packet (GSR),
which MAY be appended to the RSI packet to provide more detailed
information on the overall session characteristics reported by all
receivers.
The sender MUST send at least one Receiver Summary Information
packet for each reporting interval. The sender can additionally
stack General Summary Reports (GSRs) after the RSI packet. Each GSR
packet 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, GSR packets are not required but recommended. RSI and GSR
packets are sent in addition to the standard receiver-issued
packets, such as Sender Reports and SDES packets outlined in [1].
Chesterfield Internet Draft - Expires December 2002 [Page 8]
RTCP with Unicast Feedback
7.1 Packet Formats
7.1.1 RSI: Receiver Summary Information RTCP Packet
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| SC | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| group size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFL | HCNL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Highest interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver RTCP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| collision SSRC #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
The RSI packet consists of a main report block modeled along the
same lines as a Receiver Report with optional GSR blocks appended.
The first eight bytes of header extension follow the standard RTP
header outline. This ensures backwards compatibility with older
versions that may not understand the RSI packet format but can read
the length field indicating the end of the report block. The
following fields are included:
The fields "V", "P", and "length" have the same meaning as per [1].
SC: 5 bits
The number of collision SSRC entries towards the end of the
report block. A value of 0 is allowed, indicating that no
collisions are reported.
PT: 8 bits
The payload type of this report, see Section 5 for further
details.
SSRC: 32 bits
The synchronisation source identifier for the originator of the
summary report packet.
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.
Chesterfield Internet Draft - Expires December 2002 [Page 9]
RTCP with Unicast Feedback
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].
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.
highest interarrival jitter: 32 bits
Highest 'interarrival jitter' value out of all RTCP RR packets
since the last RSI from any of the receivers.
receiver bandwidth: 32 bits
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.
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.2 GSR: General Summary Report RTCP Packet Header
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| BC | PT | Length |header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |report
| ... |blocks
The GSR packet is a three-level structure composed of an 8 Octet
header and zero or more report blocks, each of which contains a 12
Octet sub-header and variable length payload.Each GSR report
Chesterfield Internet Draft - Expires December 2002 [Page 10]
RTCP with Unicast Feedback
describes a range of values and indicates the distribution of the
group members across the data values. The report block formats are
described in subsequent sections.
The fields "V", "P", and "length" have the same meaning as per [1].
block count (BC): 5 bits
The number of report blocks contained in this packet
PT: 8 bits
The payload type of this report, see Section 5 for further
details.
SSRC of Sender: 32 bits
The SSRC of the distribution source
7.1.3 GSR Report block
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
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| DT | NDB | MF | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Distribution Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Distribution Value |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Distribution Buckets |
| ... |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
distribution type (DT): 8 bits
A numeric identifier to indicate the significance of the
distribution values. The distribution types currently defined are
described in the following four sections. Additional items may be
defined in a separate profile by registering the type numbers
with IANA (see Section 12).
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.
Chesterfield Internet Draft - Expires December 2002 [Page 11]
RTCP with Unicast Feedback
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
The length of the whole GSR data packet in 4 byte units. The full
length of the packet in bytes is calculated by multiplying the
length value by 4. This 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 GSR 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 GSR Loss report block
GSR loss report blocks indicate 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 distribution type (DT) is 1. The maximum
number of fields is 256, therefore the minimum and maximum
distribution values may not exceed 0 - 255.
Valid results for the minimum distribution value field therefore 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.
Chesterfield Internet Draft - Expires December 2002 [Page 12]
RTCP with Unicast Feedback
The distribution bucket values are always unsigned positive integers
of length ((length*4)-12)*8/NDB.
For examples on processing GSR loss report blocks, see section 7.4
and the Appendix B.
7.1.5 GSR Jitter report block
GSR jitter report blocks indicate 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
jitter results. Jitter values are measured in timestamp units and
expressed as unsigned integers. The maximum number of fields is
(2^32), therefore the minimum and maximum distribution values may
not exceed 0 - (2^32)-1. The values are timestamp units expressed as
an unsigned integer. The minimum distribution value must always be
less than the maximum. The distribution type (DT) is 2.
The distribution bucket values are always unsigned positive integers
of length ((length*4)-12)*8/NDB.
7.1.6 GSR Round Trip Time report block
GSR round trip time reports indicate 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 32-bit 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 distribution type (DT) is
3.
The distribution bucket values are always unsigned positive integers
of length ((length*4)-12)*8/NDB.
7.1.7 SSRC Distribution report block
GSR SSRC distribution report blocks are an additional data type that
can be provided by the distribution source to indicate the
allocation of SSRCs across the group. SSRCs are expressed as 32-bit
unsigned integers. The multiplicative factor (MF) 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
distribution type (DT) is 4.
The distribution bucket values are always unsigned positive integers
of length ((length*4)-12)*8/NDB.
Chesterfield Internet Draft - Expires December 2002 [Page 13]
RTCP with Unicast Feedback
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 GSR summary packets, since incorrect information can have
serious implications. Section 11 addresses the security risks in
detail.
The group size and Receiver RTCP Bandwidth packet fields MUST be
calculated and included in the RSI packet. Typically, the bandwidth
value will be calculated as outlined in [1] using the group size and
session bandwidth as input. However, the Receiver RTCP Bandwidth
field, does provide 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 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 GSR packet, the source must decide which are the most
significant feedback values to convey. 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.
Chesterfield Internet Draft - Expires December 2002 [Page 14]
RTCP with Unicast Feedback
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 portrayed by the source
can be extremely detailed, providing the receiver with an accurate
view of the overall session quality, 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 GSR 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 MUST 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.
7.4 Generating and analyzing summarised reports
In the most basic form, the sender uses an algorithm such as
Appendix A.1 to generate the data bucket values for a distribution
providing buckets for every possible value. As a first step in
creating the GSR packet for loss, the source would calculate the
highest loss value out of each data bucket in order to identify what
bucket width is required. In the case of loss values, there is a
fixed maximum number of different values which could possibly be
reported, i.e. 256 since the RTCP fraction lost field is exactly 1
octet. This means that in this, the most basic example, the source
creates a distribution with 256 buckets and calculates for each
bucket how many receivers reported each value. When generating the
packet, the source sets the Minimum Distribution Value to 0 and the
Maximum Distribution Value to 255. The maximum data value determines
the width of the bucket, i.e.
(2^n-2) -1 < Max Value <= (2^n) -1 where n is an even number. As an
example, the maximum data bucket values for the widths 6,8 and 10
Chesterfield Internet Draft - Expires December 2002 [Page 15]
RTCP with Unicast Feedback
bits would be 63,255 and 1023. Therefore if the maximum distribution
value was 557, a data bucket of size 10 would be required.
Clearly, there is further potential for applying compression
techniques to the basic algorithm. In many cases the most extreme
values, e.g. 200 - 255, may not even be reported by the group or may
be considered irrelevant. In such circumstances the source might
choose to decrease either the range or the number of buckets within
the range. Additionally, the multiplicative factor can be applied to
further reduce the necessary bucket size. Examples of this and more
detailed processing are explained in Appendix B. Further information
on the applicability of distributions to various application
scenarios is addressed in Appendix A.3.
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.
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
Chesterfield Internet Draft - Expires December 2002 [Page 16]
RTCP with Unicast Feedback
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.
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.
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 SSM 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).
Chesterfield Internet Draft - Expires December 2002 [Page 17]
RTCP with Unicast Feedback
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 gsr -- MUST be used to indicate the "General
Summary Report" mode of operation.
rtcp:unicast rsi -- MUST be used to indicate the "Receiver
Summary Information" mode of operation.
10.2 SSM Source Specification
In addition, in an SSM RTCP session, the sender(s) need to be
indicated for both source-specific joins to the multicast group as
well as for addressing RTCP packets to.
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 MUST 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 [17].
11. Security Considerations
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
Chesterfield Internet Draft - Expires December 2002 [Page 18]
RTCP with Unicast Feedback
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. SAP, SIP, RTSP, and HTTP, as prime
candidates for conveying SDP-based session descriptions support the
necessary protocol mechanisms, drawing on work from the MSEC WG.
Further work is in progress within the Gsec working group, which is
addressing the security implications of distributing session
announcements.
It is also assumed that the multicast or 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 in a number of ways by using
the unicast feedback characteristic as a weakness. Since standard
multicast communication does not typically involve many to one
unicast forwarding of data, this poses new challenges for a
security solution.
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
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 with a spoofed
source address.
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
Chesterfield Internet Draft - Expires December 2002 [Page 19]
RTCP with Unicast Feedback
benefit other types of attack, and should therefore be considered
as a potential threat.
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 that source
intended it to be. The authenticity of the data must be tested in
a separate manner.
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 original
plaintext is the intended receiver(s), therefore in order to
restrict access only to authorized entities, confidentiality is
required. It does not prevent eavesdroppers from receiving the
traffic but does guarantee that they cannot recover the original
data.
d) Replay protection
Ensures that given some pre-determined range of either time or
session values, a host can determine whether the data was
transmitted within the given window.
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
Chesterfield Internet Draft - Expires December 2002 [Page 20]
RTCP with Unicast Feedback
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.
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.
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
Chesterfield Internet Draft - Expires December 2002 [Page 21]
RTCP with Unicast Feedback
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 the security breach is not detectable 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.
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
Chesterfield Internet Draft - Expires December 2002 [Page 22]
RTCP with Unicast Feedback
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.
Data integrity is required to ensure that interception and
modification of an individual receiver's RTCP traffic is not
accomplished. This is to protect against the false influence of
group control information and the possible 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 an
additional requirement in order to ensure the origin of the data
is secure. 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.
11.6 Overview of existing security solutions
This section addresses some existing group security mechanisms and
identifies which aspects of the security requirements they might
provide. This security analysis is a work in progress, and these
options will be explored in more detail in subsequent versions of
the draft.
SRTP provides confidentiality of the RTP and RTCP packets as well as
protection against integrity compromise and replay attacks. It
provides authentication of the data stream, however it does not
provide authentication on a per-user basis. This means that a packet
can be authenticated as having originated from one of the session
members, but it does not indicate which member. All keys for an SRTP
session are derived from a single master key, which it is assumed
has been distributed via some out-of-band secure method.
The most detailed group security profile which may be considered is
the Group Domain of Interpretation, which provides a solution for
multicast IPSec ESP security with group authentication. Used in
combination with a Key negotiation protocol, it provides integrity
and group authentication and re-keying for groups with dynamic
membership. It is not particularly well suited to Real-time
application data stream processing, however and may therefore not be
appropriate.
A third option with respect to group security frameworks is TESLA
[18], a lightweight source authentication scheme based on loose time
synchronisation calculations by receivers to the source, and a
delayed key disclosure interval. The usefulness of this scheme in
Chesterfield Internet Draft - Expires December 2002 [Page 23]
RTCP with Unicast Feedback
addition to the others is currently being considered for the unicast
RTCP feedback scenario, the results of which will be addressed in a
subsequent draft.
12. IANA Considerations
Based on the guidelines suggested in [10], this document proposes 2
new RTCP data payload types for consideration by IANA, and 4 new
sub-payload types for summary distribution types, defined in section
5.
Furthermore, four new SDP media-level attributes are defined in
Section 10.
13. Outstanding Issues
6.2 Complication with detecting unicast versus multicast transmitted
data on the same port.
Backwards Compatibility section?
Incorporate additional distribution type to include packet loss rate
based on Cumulative values.
Analyse and select suitable scheme(s) for appropriate security
14. Acknowledgements
Many people have made comments and suggestions regarding this
document. In particular, we would like to thank Patrick McDaniel for
advice and suggestions regarding the security aspects, Marshall
Eubanks, Marty Schoch, Bill Fenner, the Networking Research group at
AT&T in California and also the AVT working group.
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-11.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-05.txt,
March 2001
[4] Farinacci, D, Kouvelas, I, Windisch, K, "State Refresh in PIM-
DM" draft-ietf-pim-refresh-02.txt, November, 2000
Chesterfield Internet Draft - Expires December 2002 [Page 24]
RTCP with Unicast Feedback
[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.
[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-01.txt.
[14] E. Carrara, D. McGrew, M. Naslund, K. Norrman, D. Oran, "The
Secure Real Time Transport Protocol", draft-ietf-avt-srtp-
05.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, Perkins, C. "SDP: Session Description
Protocol", draft-ietf-mmusic-sdp-new-10.txt, May 2002.
[17] C. Huitema, "RTCP Attribute in SDP," Internet Draft draft-ietf-
mmusic-sdp4nat-02.txt, February 2002.
[18] A. Perrig et al,." TESLA:Multicast source authentication
transform introduction", draft-perrig-msec-tesla-intro-00.txt,
February 2002.
[19] B. Cain, S. Deering, B. Fenner, I. Kouvelas, and A.
Thyagarajan, "Internet Group Management Protocol, Version 3,"
Internet Draft draft-ietf-idmr-igmp-v3-11.txt, May 2002.
Chesterfield Internet Draft - Expires December 2002 [Page 25]
RTCP with Unicast Feedback
16. Appendix
A GSR packet 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))
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. This section enumerates
some potential uses for the distribution scheme, however it is
anticipated that future applications might benefit from it in ways
not addressed in this document. Due to the flexible nature of the
GSR packet format, future extensions may easily be added. Some of
the scenarios addressed here 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:
Chesterfield Internet Draft - Expires December 2002 [Page 26]
RTCP with Unicast Feedback
- 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
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 GSR packet creation at the source
See Postscript version.
Chesterfield Internet Draft - Expires December 2002 [Page 27]
RTCP with Unicast Feedback
C AUTHORS ADDRESSES
Julian Chesterfield
AT&T Labs - Research
75 Willow Road
Menlo Park, CA 94025
USA
Phone: +1(650)330 7762
Fax: +1(650)463 7037
Email: julian@research.att.com
Eve Schooler
AT&T Labs - Research
75 Willow Road
Menlo Park, CA 94025
USA
Email: schooler@research.att.com
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
D FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (2000). 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 Internet Draft - Expires December 2002 [Page 28]
