[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-chesterfield-avt-rtcpssm) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 5760

Internet Draft                                                 J. Ott
draft-ietf-avt-rtcpssm-19            Helsinki University of Technology
AVT Working Group                                      J. Chesterfield
Intended Status: Proposed Standard             University of Cambridge
                                                           E. Schooler
                                                                Intel
Expires: April 2010                                   9 November 2009


        RTCP Extensions for Single-Source Multicast Sessions
                       with Unicast Feedback


Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time.  It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 9, 2010.


Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.








Ott et al.       Internet Draft - Expires April 2010         [Page 1]

                  RTCP with Unicast Feedback

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008.  The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.


Abstract

This document specifies an extension to the Real-time Transport
Control Protocol (RTCP) to use unicast feedback to a multicast
sender. The proposed extension is useful for single-source multicast
sessions such as Source-Specific Multicast (SSM) communication where
the traditional model of many-to-many group communication is either
not available or not desired. In addition, it can be applied to any
group that might benefit from a sender-controlled summarized
reporting mechanism.


Table of Contents

1. Conventions and Acronyms .................................... 2
2. Introduction................................................. 3
3. Definitions.................................................. 4
4. Basic Operation.............................................. 6
5. Packet types................................................. 9
6. Simple Feedback Model....................................... 10
7. Distribution Source Feedback Summary Model.................. 12
8. Mixer/Translator issues..................................... 32
9. Transmission interval calculation........................... 33
10. SDP Extensions............................................. 35
11. Security Considerations ................................... 38
12. Backwards Compatibility ................................... 46
13. IANA Considerations........................................ 46
14. Bibliography............................................... 48
15. Appendix A: Examples for Sender Side Configurations........ 51
16. Appendix B: Distribution Report processing at the receiver. 55
18. ACKNOWLEDGEMENTS........................................... 59
19. AUTHORS' ADDRESSES......................................... 59
20. IPR Notice................................................. 59
21. FULL COPYRIGHT STATEMENT................................... 59


1. Conventions and Acronyms

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [13].

Ott et al.       Internet Draft - Expires April 2010           [Page 2]

                  RTCP with Unicast Feedback

The following acronyms are used throughout this document:

ASM  Any Source Multicast;
SSM  Source-Specific Multicast.

2. Introduction

The Real-time Transport Protocol (RTP) [1] provides a real-time
transport mechanism suitable for unicast or multicast communication
between multimedia applications. Typical uses of RTP are for real-
time or near real-time group communication of audio and video data
streams. An important component of the RTP protocol is the control
channel, defined as the RTP Control Protocol (RTCP). RTCP involves
the periodic transmission of control packets between group members,
enabling group size estimation and the distribution and calculation
of session-specific information such as packet loss and round trip
time to other hosts. An additional advantage of providing a control
channel for a session is that a third-party session monitor can
listen to the traffic to establish network conditions and to
diagnose faults based on receiver locations.

RTP was designed to operate in either a unicast or multicast mode.
In multicast mode, it assumes an Any Source Multicast (ASM) group
model, where both one-to-many and many-to-many communication are
supported via a common group address in the range 224.0.0.0 through
239.255.255.255. To enable Internet-wide multicast communication,
intra-domain routing protocols (those that operate only within a
single administrative domain, e.g., DVMRP [16], PIM [17][18]) are
used in combination with inter-domain routing protocols (those that
operate across administrative domain borders, e.g., MBGP [19], MSDP
[20]). 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.
However, there is a great deal of complexity involved at the routing
level to support such a multicast service in the network.

Many-to-many communication is not always available, nor desired by
all group applications. For example, with Source-Specific Multicast
(SSM) [8][9] and satellite communication, the multicast distribution
channel only supports source-to-receiver traffic. In other cases,
such as large ASM groups with a single active data source and many
passive receivers, it is sub-optimal to create a full routing-level
mesh of multicast sources just for the distribution of RTCP control
packets.  Thus, an alternative solution is preferable.

Although a one-to-many multicast topology may simplify routing and
may be a closer approximation to the requirements of certain RTP
applications, unidirectional communication makes it impossible for
receivers in the group to share RTCP feedback information with other
group members. In this document, we specify a solution to that
problem.  We introduce unicast feedback as a new method to
distribute RTCP control information amongst all session members.
This method is designed to operate under any group communication
model, ASM or SSM. The RTP data stream protocol itself is unaltered.

Ott et al.       Internet Draft - Expires April 2010           [Page 3]

                  RTCP with Unicast Feedback


Scenarios under which the unicast feedback method can 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 receive RTP data streams and
   to continue to participate in the RTP control protocol, RTCP, by
   using multicast in the source-to-receiver direction and unicast
   to send receiver feedback to the source on the standard RTCP
   port.

b) One-to-many broadcast networks.

   Unicast feedback may also be beneficial to one-to-many broadcast
   networks, such as a satellite network with a terrestrial low-
   bandwidth return channel or a broadband cable link. Unlike the
   SSM network, these networks may have the ability for a receiver
   to multicast return data to the group.  However, a unicast
   feedback mechanism may be preferable for routing simplicity.

c) ASM with a single sender.

   A unicast feedback approach can be used by an ASM application
   with a single sender to reduce the load on the multicast routing
   infrastructure that does not scale as efficiently as unicast
   routing does. Because this is no more efficient than a standard
   multicast group RTP communication scenario, it is not expected to
   replace the traditional mechanism.

The modifications proposed in this document are intended to
supplement the existing RTCP feedback mechanisms described in [1],
Section 6.


3. Definitions

Distribution Source:
     In an SSM context, only one entity distributes RTP data and
     redistributes RTCP information to all receivers.  This entity
     is called the Distribution Source.  It is also responsible for
     forwarding RTCP feedback to the Media Senders and thus creates
     a virtual multicast environment in which RTP and RTCP can be
     applied.

     Note that heterogeneous networks consisting 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 8 for details).

Media Sender:
     A Media Sender is an entity that originates RTP packets for a
     particular media session. In RFC 3550, a Media Sender is simply

Ott et al.       Internet Draft - Expires April 2010           [Page 4]

                  RTCP with Unicast Feedback

     called a source.  However, as the RTCP SSM system architecture
     includes a Distribution Source, to avoid confusion, in this
     document a media source is commonly referred to as a Media
     Sender.  There may often be a single Media Sender that is co-
     located with the Distribution Source.  But although there MUST
     be only one Distribution Source, there MAY be multiple Media
     Senders on whose behalf the Distribution Source forwards RTP
     and RTCP packets.

RTP and RTCP Channels:
     The data distributed from the source to the receivers is
     referred to as the RTP channel and the control information as
     the RTCP channel.  With standard RTP/RTCP, these channels
     typically share the same multicast address but are
     differentiated via port numbers as specified in [1].  In an SSM
     context, the RTP channel is multicast from the Distribution
     Source to the receivers. In contrast, the RTCP or feedback
     channel is actually the collection of unicast channels between
     the receivers and the Distribution Source via the Feedback
     Target(s). Thus bi-directional communication is accomplished by
     using SSM in the direction from Distribution Source to the
     receivers and using the unicast feedback channel in the
     direction from receivers to Distribution Source.  As discussed
     in the next section, the nature of the channels between the
     Distribution Source and the Media Sender(s) may vary.


(Unicast RTCP) Feedback Target:
     The Feedback Target is a logical function to which RTCP unicast
     feedback traffic is addressed.  The functions of the Feedback
     Target and the Distribution Source MAY be co-located or
     integrated in the same entity.  In this case, for a session
     defined as having a Distribution Source A, on ports n for the
     RTP channel and k for the RTCP channel, the unicast RTCP
     Feedback Target is identified by an IP address of Distribution
     Source A on port k unless otherwise stated in the session
     description.  See Section 10 for details on how the address is
     specified.  The Feedback Target MAY also be implemented in one
     or more entities different from the Distribution Source, and
     different RTP receivers MAY use different Feedback Target
     instances, e.g., for aggregation purposes.  In this case, the
     Feedback Target instances(s) MUST convey the feedback received
     from the RTP receivers to the Distribution Source using the
     RTCP mechanisms specified in this document.  If disjoint, the
     Feedback Target instances MAY be organized in arbitrary
     topological structures: in parallel, hierarchical, or chained.
     But the Feedback Target instance(s) and Distribution Source
     MUST share, e.g., through configuration, enough information to
     be able to provide coherent RTCP information to the RTP
     receivers based upon the RTCP feedback collected by the
     Feedback Target instance(s) -- as would be done if both
     functions were part of the same entity.



Ott et al.       Internet Draft - Expires April 2010           [Page 5]

                  RTCP with Unicast Feedback

     In order for unicast feedback to work, each receiver MUST
     direct its RTCP reports to a single specific Feedback Target
     instance.

SSRC:
     Synchronization source as defined in [1].  This 32-bit value
     uniquely identifies each member in a session.

Report blocks:
     Report block is the standard terminology for an RTCP reception
     report.  RTCP [1] encourages the stacking of multiple report
     blocks in Sender Report (SR) and Receiver Report (RR) packets.
     As a result, a variable size feedback packet may be created by
     one source that reports on multiple other sources in the group.
     The summarized reporting scheme builds upon this model through
     the inclusion of multiple summary report blocks in one packet.
     However, stacking of reports from multiple receivers is not
     permitted in the Simple Feedback Model (see Section 6).


4. Basic Operation

As indicated by the definitions of the preceding section, one or
more Media Senders send RTP packets to the Distribution Source.  The
Distribution Source relays the RTP packets to the receivers using a
source-specific multicast arrangement.  In the reverse direction,
the receivers transmit RTCP packets via unicast to one or more
instances of the Feedback Target. The Feedback Target sends either
the original RTCP reports (the Simple Feedback Model) or summaries
of these reports (the Summary Feedback model) to the Distribution
Source.  The Distribution Source in turn relays the RTCP reports
and/or summaries to the Media Senders.  The Distribution Source also
transmits the RTCP sender reports and receiver reports or summaries
back to the receivers, using source-specific multicast.

When the Feedback Target(s) is/are co-located (or integrated) with
the Distribution Source, re-distribution of original or summarized
RTCP reports is trivial.  When the Feedback Target(s) is/are
physically and/or topologically distinct from the Distribution
Source, each Feedback Target either relays the RTCP packets to the
Distribution source, or summarizes the reports and forwards an RTCP
summary report to the Distribution Source.  Coordination between
multiple Feedback Targets is beyond the scope of this specification.

The Distribution Source MUST be able to communicate with all group
members in order for either mechanism to work.  The general
architecture is displayed below in Figure 1.  There may be a single
Media Sender or multiple Media Senders, Media Sender i, 1<=i<=M, on
whose behalf the Distribution Source disseminates RTP and RTCP
packets.  The base case, which is expected to be the most common
case, is that the Distribution Source is co-located with a
particular Media Sender. A basic assumption is that communication is
multicast (either SSM or ASM) in the direction of the Distribution


Ott et al.       Internet Draft - Expires April 2010           [Page 6]

                  RTCP with Unicast Feedback

Source to the receivers, R(j), 1<=j<=N, and unicast in the direction
of the receivers to the Distribution Source.

Communication between Media Sender(s) and the Distribution Source
may be performed in numerous ways:

i.   Unicast only: The Media Sender(s) MAY send RTP and RTCP via
     unicast to the Distribution Source and receive RTCP via
     unicast.

ii.  Any Source Multicast (ASM): the Media Sender(s) and the
     Distribution Source MAY be in the same ASM group and RTP and
     RTCP packets are exchanged via multicast.

iii. Source-Specific Multicast (SSM): The Media Sender(s) and the
     Distribution Source MAY be in an SSM group with the source
     being the Distribution Source.  RTP and RTCP packets from the
     Media Senders are sent via unicast to the Distribution Source
     while RTCP packets from the Distribution Source are sent via
     multicast to the Media Senders.

     Note that this SSM group MAY be identical to the SSM group used
     for RTP/RTCP delivery from the Distribution Source to the
     receivers or MAY be a different one.

Note that figure 1 below shows a logical diagram and, therefore, no
details about the above options for the communication between Media
Sender(s), Distribution Source, Feedback Target(s), and receivers
are provided.

Configuration information needs to be supplied so that (among
others)

  . Media Sender(s) know the transport address of the Distribution
     Source or the transport address of the (ASM or SSM) multicast
     group used for the contribution link;
  . the Distribution Source knows either the unicast transport
     address(es) or the (ASM or SSM) multicast transport address(es)
     to reach the Media Sender(s);
  . receivers know the addresses of their respectively responsible
     Feedback Target, and
  . the Feedback Target(s) know the transport address of the
     Distribution Source.

The precise setup and configuration of the Media Senders and their
interaction with the Distribution Source is beyond the scope of this
document (appropriate SDP descriptions MAY be used for this purpose)
that only specifies how the various components interact within an
RTP session.  Informative examples for different configurations of
the Media Sources and the Distribution Source are given in Appendix
A.

Future specifications may be defined to address these aspects.


Ott et al.       Internet Draft - Expires April 2010           [Page 7]

                  RTCP with Unicast Feedback


                                          Source-specific
           +--------+       +-----+          Multicast
           |Media   |       |     |     +----------------> R(1)
           |Sender 1|<----->| D S |     |                    |
           +--------+       | I O |  +--+                    |
                            | S U |  |  |                    |
           +--------+       | T R |  |  +-----------> R(2)   |
           |Media   |<----->| R C |->+  +---- :         |    |
           |Sender 2|       | I E |  |  +------> R(n-1) |    |
           +--------+       | B   |  |  |          |    |    |
               :            | U   |  +--+--> R(n)  |    |    |
               :            | T +-|          |     |    |    |
                            | I | |<---------+     |    |    |
           +--------+       | O |F|<---------------+    |    |
           |Media   |       | N |T|<--------------------+    |
           |Sender M|<----->|   | |<-------------------------+
           +--------+       +-----+            Unicast

           FT = Feedback Target
           Transport from the Feedback Target to the Distribution
           Source is via unicast or multicast RTCP if they are not
           co=located.

                       Figure 1. System Architecture.

The first method proposed to support unicast RTCP feedback, the
'Simple Feedback Model', is a basic reflection mechanism whereby all
Receiver RTCP packets are unicast to the Feedback Target which
relays them unmodified to the Distribution Source.  Subsequently,
these packets are forwarded by the Distribution 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 forwarded RTCP traffic on the multicast control channel.
This method also has the advantage of being backwards compatible
with standard RTP/RTCP implementations.   The Simple Feedback Model
is specified in section 6.

The second method, the 'Distribution Source Feedback Summary Model',
is a summarized reporting scheme that provides savings in bandwidth
by consolidating Receiver Reports at the Distribution Source,
optionally with help from the Feedback Target(s), into summary
packets that are then distributed to all the receivers. The
Distribution Source Feedback Summary Model is specified in section
7.

The advantage of the latter scheme is apparent for large group
sessions where the basic reflection mechanism outlined above
generates a large amount of packet forwarding when it replicates all


Ott et al.       Internet Draft - Expires April 2010           [Page 8]

                  RTCP with Unicast Feedback

the information to all the receivers.  Clearly, this technique
requires that all session members understand the new summarized
packet format outlined in Section 7.1.  Additionally, the summarized
scheme provides an optional mechanism to send distribution
information or histograms about the feedback data reported by the
whole group.  Potential uses for the compilation of distribution
information are addressed in Section 7.4.

To differentiate between the two reporting methods, a new SDP
identifier is created and discussed in Section 10.  The reporting
method MUST be decided prior to the start of the session.  A
Distribution Source MUST NOT change the method during a session.

In a session using SSM, the network SHOULD prevent any multicast
data from the receiver being distributed further than the first hop
router.  Additionally, any data heard from a non-unicast capable
receiver by other hosts on the same subnet SHOULD be filtered out by
the host IP stack so that it does not cause problems with respect to
the calculation of the Receiver RTCP bandwidth share.


5. Packet types

The RTCP packet types defined in [1], [26], and [15] are:

Type       Description                  Payload number
-------------------------------------------------------
SR         Sender Report                200
RR         Receiver Report              201
SDES       Source Description           202
BYE        Goodbye                      203
APP        Application-Defined          204
RTPFB      Generic RTP feedback         205
PSFB       Payload-specific feedback    206
XR         RTCP Extension               207


This document defines one further RTCP packet format:

Type       Description                    Payload number
---------------------------------------------------------
RSI        Receiver Summary Information   208

Within the Receiver Summary Information packet, there are various
types of information that may be reported and encapsulated in
optional sub-report blocks:









Ott et al.       Internet Draft - Expires April 2010           [Page 9]

                  RTCP with Unicast Feedback

Sub-Report Block Type    Description            Identifier number
------------------------------------------------------------------
IPv4 Address      IPv4 Unicast Feedback address        0
IPv6 Address      IPv6 Unicast Feedback address        1
DNS name          DNS name for Unicast Feedback        2
-                 - reserved -                         3
Loss              Loss distribution                    4
Jitter            Jitter distribution                  5
RTT               Round trip time distribution         6
Cumulative loss   Cumulative loss distribution         7
Collisions        SSRC collision list                  8
-                 - reserved -                         9
Stats             General statistics                   10
Receiver BW       RTCP Receiver Bandwidth              11
Group Info        RTCP Group and Avg Packet Size       12
-                 - reserved -                         13 - 255

As with standard RTP/RTCP, the various reports MAY be combined into
a single RTCP packet, which SHOULD NOT exceed the path MTU. Packets
continue to be sent at a rate that is inversely proportional to the
group size in order to scale the amount of traffic generated.


6. Simple Feedback Model

6.1 Packet Formats

The Simple Feedback Model uses the same packet types as traditional
RTCP feedback described in [1].  Receivers still generate Receiver
Reports with information on the quality of the stream received from
the Distribution Source.  The Distribution Source still MUST create
Sender Reports that include timestamp information for stream
synchronization and round trip time calculation.  Both Media 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 behavior

For the Simple Feedback Model, the Distribution Source MUST provide
a basic packet reflection mechanism.  It is the default behavior for
any Distribution Source and is the minimum requirement for acting as
a Distribution Source to a group of receivers using unicast RTCP
feedback.

The Distribution Source (unicast Feedback Target) MUST listen for
unicast RTCP data sent to the RTCP port.  All valid unicast RTCP
packets received on this port MUST be forwarded by the Distribution
Source to the group on the multicast RTCP channel.  The Distribution
Source MUST NOT stack report blocks received from different
receivers into one packet for retransmission to the group.  Every
RTCP packet from each receiver MUST be reflected individually.


Ott et al.       Internet Draft - Expires April 2010          [Page 10]

                  RTCP with Unicast Feedback

If the Media Sender(s) are not part of the SSM group for RTCP packet
reflection, the Distribution Source MUST also forward the RTCP
packets received from the receivers to the Media Sender(s).  If
there is more than one Media Sender and these Media Senders do not
communicate via ASM with the Distribution Source and each other, the
Distribution Source MUST forward each RTCP packet originated by one
Media Sender to all other Media Senders.

The Distribution Source MUST forward RTCP packets originating from
the Media Sender(s) to the receivers.

The reflected or forwarded RTCP traffic SHOULD NOT be counted as its
own traffic in the transmission interval calculation by the
Distribution Source.  In other words, the Distribution Source SHOULD
NOT consider reflected packets as part of its own control data
bandwidth allowance.  However, reflected packets MUST be processed
by the Distribution Source and the average RTCP packet size, RTCP
transmission rate, and RTCP statistics MUST be calculated.  The
algorithm for computing the allowance is explained in Section 9.


6.3 Disjoint Distribution Source and Feedback Target(s)

If the Feedback Target function is disjoint from the Distribution
Source, the Feedback Target(s) MUST forward all RTCP packets from
the receivers or another Feedback Target -- directly or indirectly -
- to the Distribution Source.

6.4 Receiver behavior

Receivers MUST listen on the RTP channel for data and the RTCP
channel for control.  Each receiver MUST calculate its share of the
control bandwidth R/n, in accordance with the profile in use, so
that a fraction of the RTCP bandwidth, R, allocated to receivers is
divided equally between the number of unique receiver SSRCs in the
session, n.  R may be rtcp_bw*0.75 or rtcp_bw*0.5 (depending on the
ratio of senders to receivers as per [1]) or may be set explicitly
by means of an SDP attribute [10].  See Section 9 for further
information on the calculation of the bandwidth allowance.  When a
receiver is eligible to transmit, it MUST send a unicast Receiver
Report packet to the Feedback Target following the rules defined in
section 9.

When a receiver observes either RTP packets or RTCP Sender Reports
from a Media Sender with an SSRC that collides with its own chosen
SSRC, it MUST change its own SSRC following the procedures of [1].
The receiver MUST do so immediately after noticing and before
sending any (further) RTCP feedback messages.

If a receiver has out-of-band information available about the Media
Sender SSRC(s) used in the media session, it MUST NOT use the same
SSRC for itself.  Even if such out-of-band information is available
a receiver MUST obey the above collision resolution mechanisms.


Ott et al.       Internet Draft - Expires April 2010          [Page 11]

                  RTCP with Unicast Feedback

Further mechanisms defined in [1] apply for resolving SSRC
collisions between receivers.

6.5 Media Sender behavior

Media Senders listen on a unicast or multicast transport address for
RTCP reports sent by the receivers (and forwarded by the
Distribution Source) or other Media Senders (forwarded by the
Distribution Source if needed).  Processing and general operation
follows [1].

A Media Sender that observes an SSRC collision with another entity
that is not also a Media Sender MAY delay its own collision
resolution actions as per [1] by 5*1.5*Td with Td being the
deterministic calculated reporting interval for receivers to see
whether the conflict still exists.  SSRC collisions with other Media
Senders MUST be acted upon immediately.

     Note: This gives precedence to Media Senders and places the
     burden of collision resolution on the RTP receivers.

Sender SSRC information MAY be communicated out-of-band, e.g., by
means of SDP media descriptions.  Therefore, senders SHOULD NOT
change their own SSRC aggressively or unnecessarily.


7. Distribution Source Feedback Summary Model

In the Distribution Source Feedback Summary Model, the Distribution
Source is required to summarize the information received from all
the Receiver Reports generated by the receivers and place the
information into summary reports.  The Distribution Source Feedback
Summary Model introduces a new report block format, the Receiver
Summary Information Report (RSI), and a number of optional sub-
report block formats, which are enumerated in Section 7.1.  As
described in section 7.3, individual instances of the Feedback
Target may provide preliminary summarization to reduce the
processing load at the Distribution Source.

Sub-reports appended to the RSI report block provide more detailed
information on the overall session characteristics reported by all
receivers and can also convey important information such as the
feedback address and reporting bandwidth.  Which sub-reports are
mandatory and which ones are optional is defined below.

From an RTP perspective, the Distribution Source is an RTP receiver,
generating its own Receiver Reports and sending them to the receiver
group and to the Media Senders.  In the Distribution Source Feedback
Summary Model, an RSI report block MUST be appended to all RRs the
Distribution Source generates.

In addition, the Distribution Source MUST forward the RTCP SR
reports and SDES packets of Media Senders without alteration.  If
the Distribution Source is actually a Media Sender, even if it is

Ott et al.       Internet Draft - Expires April 2010          [Page 12]

                  RTCP with Unicast Feedback

the only session sender, it MUST generate its own Sender Report (SR)
packets for its role as a Media Sender and its Receiver Reports in
its role as the Distribution Source.

The Distribution Source MUST use its own SSRC value for transmitting
summarization information and MUST perform proper SSRC collision
detection and resolution.

The Distribution Source MUST send at least one Receiver Summary
Information packet for each reporting interval.  The Distribution
Source MAY additionally stack sub-report blocks after the RSI
packet.  If it does so, each sub-report block MUST correspond to the
RSI packet and constitutes an enhancement to the basic summary
information required by the receivers to calculate their reporting
time interval.  For this reason, additional sub-report blocks are
not required but recommended.  The compound RTCP packets containing
the RSI packet and the optional corresponding sub-report blocks MUST
be formed according to the rules defined in [1] for receiver-issued
packets, e.g., they MUST begin with an RR packet, contain at least
an SDES packet with a CNAME, and MAY contain further RTCP packets
and SDES items.

Every RSI packet MUST contain either a Group and Average Packet size
sub-report or an RTCP Bandwidth sub-report for bandwidth indications
to the receivers.


7.1 Packet Formats

All numeric values comprising multiple (usually two or four) octets
MUST be encoded in network byte order.


7.1.1 RSI: Receiver Summary Information Packet

The RSI report block has a fixed header size followed by a variable
length report:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved |   PT=RSI=208  |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           SSRC                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Summarized SSRC                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              NTP Timestamp (most significant word)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              NTP Timestamp (least significant word)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                       Sub-report blocks                       :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Ott et al.       Internet Draft - Expires April 2010          [Page 13]

                  RTCP with Unicast Feedback


The RSI packet includes the following fields:

length: 16 bits
   As defined in [1], the length of the RTCP packet in 32-bit words
   minus one, including the header and any padding.

SSRC: 32 bits
   The SSRC of the Distribution Source.

Summarized SSRC: 32 bits
   The SSRC (of the Media Sender) of which this report contains a
   summary.

Timestamp: 64 bits
   Indicates the wallclock time when this report was sent.
   Wallclock time (absolute date and time) is represented using the
   timestamp format of the Network Time Protocol (NTP), which is in
   seconds relative to 0h UTC on 1 January 1900 [1].    The
   wallclock time MAY (but need not) be NTP-synchronized but it MUST
   provide a consistent behavior in the advancement if time (similar
   to NTP).  The full resolution NTP timestamp is used which is a
   64-bit unsigned fixed-point number with the integer part in the
   first 32 bits and the fractional part in the last 32 bits.  This
   format is similar to RTCP sender reports (section 6.4.1 of [1]).
   The timestamp value is used to enable detection of duplicate
   packets, reordering and to provide a chronological profile of the
   feedback reports.


7.1.2 Sub-Report Block Types

For RSI reports, this document also introduces a sub-report block
format specific to the RSI packet.  The sub-report blocks are
appended to the RSI packet using the following generic format.  All
sub-report blocks MUST be 32-bit aligned.


 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     SRBT      |    Length     |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      SRBT-specific data       +
|                                                               |
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SRBT: 8 bits
   Sub-Report Block Type. The sub-report block type identifier.  The
   values for the sub-report block types are defined in section 5.

Length: 8 bits
   The length of the sub-report in 32-bit words.

SRBT-specific data: <Length*4 - 2> octets

Ott et al.       Internet Draft - Expires April 2010          [Page 14]

                  RTCP with Unicast Feedback

   This field may contain type-specific information based upon the
   SRBT value.


7.1.3 Generic Sub-Report Block Fields

For the sub-report blocks that convey distributions of values (Loss,
Jitter, RTT, Cumulative Loss), a flexible 'data bucket' style report
is used. This format divides the data set into variable size buckets
that are interpreted according to the guide fields at the head of
the report block.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|     SRBT      |    Length     |        NDB            |   MF  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Minimum Distribution Value                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Maximum Distribution Value                  |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                      Distribution Buckets                     |
|                             ...                               |
|                             ...                               |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

The SRBT and Length fields are calculated as explained in section
7.1.2.

Number of distribution buckets (NDB): 12 bits
   The number of distribution buckets of data.  The size of each
   bucket can be calculated using the formula ((length * 4) -
   12)*8/NDB number of bits.  The calculation is based on the length
   of the whole sub-report block in octets (length field * 4) minus
   the header of 12 octets.  Providing 12 bits for the NDB field
   enables bucket sizes as small as 2 bits for a full length packet
   of MTU 1500 bytes.  The bucket size in bits must always be
   divisible by 2 to ensure proper byte alignment.  A bucket size of
   2 bits is fairly restrictive, however, and it is expected that
   larger bucket sizes will be more practical for most
   distributions.

Multiplicative Factor (MF): 4 bits
  2^MF indicates the multiplicative factor to be applied to each
  distribution bucket value.  Possible values of MF are 0 - 15,
  creating a range of values from MF = 1, 2, 4 ... 32768.  Appendix
  B gives an example of the use of the multiplicative factor; it is
  meant to provide more "bits" without having them -- the bucket
  values get scaled up by the MF.

Length: 8 bits
   The length field tells the receiver the full length of the sub-
   report block in 32-bit words (i.e., length * 4 bytes), and

Ott et al.       Internet Draft - Expires April 2010          [Page 15]

                  RTCP with Unicast Feedback

   enables the receiver to identify the bucket size. For example,
   given no MTU restrictions, the data portion of a distribution
   packet may be only as large as 1008 bytes (255 * 4 - 12),
   providing up to 4032 data buckets of length 2 bits, or 2016 data
   buckets of length 4 bits, etc.

Minimum distribution value (min): 32 bits
   The minimum distribution value, in combination with the maximum
   distribution value, indicates the range covered by the data
   bucket values.

Maximum distribution value (max): 32 bits
   The maximum distribution value, in combination with the minimum
   distribution value, indicates the range covered by the data
   bucket values.  The significance and range of the distribution
   values is defined in the individual subsections for each
   distribution type (DT).

Distribution buckets: each bucket is ((length * 4) - 12)*8/NDB bits
   The size and number of buckets is calculated as outlined above
   based upon the value of NDB and the length of the packet.  The
   values for distribution buckets are equally distributed;
   according to the following formula, distribution bucket x
   (with 0 <= x < NDB) covering the value range:

   x=0; [min, min+(max-min)/NDB]
   x>0; [min+(x)*(max-min)/NDB, min+(x+1)*(max-min)/NDB]

Interpretation of the minimum, maximum, and distribution values in
the sub-report block is sub-report-specific and is addressed
individually in the sections below.  The size of the sub-report
block is variable, as indicated by the packet length field.

Note that, for any bucket-based reporting, if the Distribution
Source and the Feedback Target(s) are disjoint entities, out-of-band
agreement on the bucket reporting granularity is recommended to
allow the Distribution Source to forward accurate information in
these kinds of reports to the receivers.


7.1.4 Loss sub-report block

The loss sub-report block allows a receiver to determine how its own
reception quality relates to the other recipients.  A receiver may
use this information, e.g., to drop out of a session (instead of
sending lots of error repair feedback) if it finds itself isolated
at the lower end of the reception quality scale.

The loss sub-report block indicates the distribution of losses as
reported by the receivers to the Distribution Source.  Values are
expressed as a fixed-point number with the binary point at the left
edge of the field similar to the "fraction lost" field in SR and RR
packets as defined in [1].  The Loss sub-report block type (SRBT) is
4.

Ott et al.       Internet Draft - Expires April 2010          [Page 16]

                  RTCP with Unicast Feedback


Valid results for the minimum distribution value field are 0 - 254.
Similarly, valid results for the maximum distribution value field
are 1 - 255.  The minimum distribution value MUST always be less
than the maximum.

For examples on processing summarized loss report sub-blocks, see
Appendix B.


7.1.5 Jitter sub-report block

A jitter sub-report block indicates the distribution of the
estimated statistical variation of the RTP data packet inter-arrival
time reported by the receivers to the Distribution Source.  This
allows receivers both to place their own observed jitter values in
context with the rest of the group, and to approximate dynamic
parameters for playout buffers. See [1] for details on the
calculation of the values and the relevance of the jitter results.
Jitter values are measured in timestamp units with the rate used by
the Media Sender and expressed as unsigned integers.  The minimum
distribution value MUST always be less than the maximum.  The Jitter
sub-report block type (SRBT) is 5.

Since timestamp units are payload-type specific, the relevance of a
jitter value is impacted by any change in the payload type during a
session.  Therefore, a Distribution Source MUST NOT report jitter
distribution values for at least 2 reporting intervals after a
payload type change occurs.


7.1.6 Round Trip Time sub-report block

A round trip time sub-report indicates the distribution of round
trip times from the Distribution Source to the receivers, providing
receivers with a global view of the range of values in the group.
The Distribution Source is capable of calculating the round trip
time to any other members since it forwards all the SR packets from
the Media Sender(s) to the group.  If the Distribution Source is not
itself a Media Sender, it can calculate the round trip time from
itself to any of the receivers by maintaining a record of the SR
sender timestamp, and the current time as measured from its own
system clock.  The Distribution Source consequently calculates the
round trip time from the receiver report by identifying the
corresponding SR timestamp and subtracting the RR advertised holding
time as reported by the receiver from its own time difference
measurement, as calculated by the time the RR packet is received and
the recorded time the SR was sent.

The Distribution Source has the option of distributing these round
trip time estimations to the whole group, uses of which are
described in Section 7.4.  The round trip time is expressed in units
of 1/65536 seconds and indicates an absolute value.  This is
calculated by the Distribution Source based on the Receiver Report

Ott et al.       Internet Draft - Expires April 2010          [Page 17]

                  RTCP with Unicast Feedback

responses declaring the time difference since an original Sender
Report, and the holding time at the receiver.  The minimum
distribution value MUST always be less than the maximum. The Round
Trip Time sub-report block type (SRBT) is 6.

   Note that if the Distribution Source and the Feedback Target
   functions are disjoint, it is only possible for the Distribution
   Source to determine RTT if all the Feedback Targets forward all
   RTCP reports from the receivers immediately (i.e., do not perform
   any preliminary summarization) and include at least the RR
   packet.


7.1.7 Cumulative Loss sub-report block

The cumulative loss field in a Receiver Report [1], in contrast to
the fraction lost field, is intended to provide some historical
perspective on the session performance, i.e., the total number of
lost packets since the receiver joined the session.  The cumulative
loss value provides a longer-term average by summing over a larger
sample set (typically the whole session).  The Distribution Source
MAY record the values as reported by the receiver group and report a
distribution of values.  Values are expressed as a fixed-point
number with the binary point at the left edge of the field, in the
same manner as the Loss sub-report block.  Since the individual
Receiver Reports give the cumulative number of packets lost but not
the cumulative number sent, which is required as a denominator to
calculate the long-term fraction lost, the Distribution Source MUST
maintain a record of the cumulative number lost and extended highest
sequence number received as reported by each receiver at some point
in the past.  Ideally the recorded values are from the first report
received.  Subsequent calculations are then based on (<the new
cumulative loss value> - <the recorded value>) / (<new extended
highest sequence number> - <recorded sequence number>).

Valid results for the minimum distribution value field are 0 - 254.
Similarly, valid results for the maximum distribution value field
are 1 - 255.  The minimum distribution value MUST always be less
than the maximum.  The Cumulative loss sub-report block type (SRBT)
is 7.


7.1.8 Feedback Target Address sub-report block

The Feedback Target Address block provides a dynamic mechanism for
the Distribution Source to signal an alternative unicast RTCP
feedback address to the receivers.  If a block of this type is
included, receivers MUST override any static SDP address information
for the session with the Feedback Target address provided in this
sub-report block.

If a Feedback Target Address sub-report block is used, it MUST be
included in every RTCP packet originated by the Distribution Source

Ott et al.       Internet Draft - Expires April 2010          [Page 18]

                  RTCP with Unicast Feedback

to ensure that all receivers understand the information.  In this
manner, receiver behavior should remain consistent even in the face
of packet loss or when there are late session arrivals.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT={0,1,2}  |     Length    |             Port              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:                            Address                            :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SRBT: 8 bits
  The type of sub-report block that corresponds to the type of
  address is as follows:

     0: IPv4 address
     1: IPv6 address
     2: DNS name


Length: 8 bits
   The length of the sub-report block in 32-bit words. For an IPv4
   address this should be 2 (i.e., Total length = 4 + 4 = 2*4
   octets). For an IPv6 address this should be 5.  For a DNS name,
   the length field indicates the number of 32-bit words making up
   the string plus 1 byte and any additional padding required to
   reach the next word boundary.

Port: 2 octets
   The port number to which receivers send feedback reports.  A port
   number of 0 is invalid and MUST NOT be used.

Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)
   The address to which receivers send feedback reports.  For IPv4
   and IPv6 fixed-length address fields are used.  A DNS name is an
   arbitrary length string that is padded with null bytes to the
   next 32 bit boundary.  The string MAY contain IDNA domain names
   and MUST be UTF-8 encoded [11].

A feedback target address block for a certain address type (i.e.,
with a certain SRBT of 0, 1, or 2) MUST NOT occur more than once
within a packet. Numerical feedback target address blocks for IPv4
and IPv6 MAY both be present.  If so, the resulting transport
addresses MUST point to the same logical entity.

If a feedback target address block with an SRBT indicating a DNS
name is present, there SHOULD NOT be any other numerical Feedback
Target Address blocks present.



Ott et al.       Internet Draft - Expires April 2010          [Page 19]

                  RTCP with Unicast Feedback

The Feedback Target Address presents a significant security risk if
accepted from unauthenticated RTCP packets.  See section 11.3 and
11.4 for further discussion.


7.1.9 Collisions sub-report block

The collision SSRC sub-report provides the Distribution Source with
a mechanism to report SSRC collisions amongst the group.  In the
event that a non-unique SSRC is discovered based on the tuple
[SSRC,CNAME], the collision is reported in this block and the
affected nodes must reselect their respective SSRC identifiers.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     SRBT=8    |    Length     |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:                         Collision SSRC                        :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Collision SSRC: n x 32 bits
   This field contains a list of 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 session
   using the Distribution Source Feedback Summary Model no longer
   have a global view of the session, the collision algorithm is
   handled by the Distribution Source.  SSRCs that collide are
   listed in the packet.  Each Collision SSRC is reported only once
   for each collision detection.  If more Collision SSRCs need to be
   reported than fit into an MTU, the reporting is done in a round
   robin fashion so that all Collision SSRCs have been reported once
   before the second round of reporting starts.  On receipt of the
   packet, receiver(s) MUST detect the collision and select another
   SSRC, if the collision pertains to them.

The Collisions sub-report block type (SRBT) is 8.

Collision detection is only possible at the Distribution Source.  If
the Distribution Source and Feedback Target Functions are disjoint
and collision reporting across RTP receiver SSRCs shall be provided,
the Feedback Targets(s) MUST forward the RTCP reports from the RTP
receivers including at least the RR and the SDES packets to the
Distribution Source.

In system settings in which, by explicit configuration or
implementation, RTP receivers are not going to act as Media Senders
in a session (e.g. for various types of television broadcasting),
SSRC collision detection MAY be omitted for RTP receivers.  In
system settings in which an RTP receiver MAY become a Media Sender


Ott et al.       Internet Draft - Expires April 2010          [Page 20]

                  RTCP with Unicast Feedback

(e.g., any conversational application), SSRC collision detection
MUST be provided for RTP receivers.

     Note: The purpose of SSRC collision reporting is to ensure
     unique identification of RTCP entities.  This is of particular
     relevance for Media Senders so that an RTP receiver can
     associate each of multiple incoming media streams (via the
     Distribution Source) properly with the correct sender.
     Collision resolution for Media Senders is not affected by the
     Distribution Source's collision reporting because all SR
     reports are always forwarded among the senders and to all
     receivers.  Collision resolution for RTP receivers is of
     particular relevance for those receivers capable of becoming a
     Media Sender.  RTP receivers that will, by configuration or
     implementation choice, not act as a sender in a particular RTP
     session, do not necessarily need to be aware of collisions as
     long as the those entities receiving and processing RTCP
     feedback messages from the receivers are capable of
     disambiguating the various RTCP receivers (e.g., by CNAME).

     Note also that RTP receivers should be able to deal with
     changing SSRCs of a Media Sender (like any RTP receiver has to
     do.) and, if possible, be prepared to render a media stream
     continuously nevertheless.


7.1.10 General Statistics sub-report block

The general statistics sub-report block is used if specifying
buckets is deemed too complex.  With the general statistics sub-
report block only aggregated values are reported back.  The rules
for the generation of these values are provided in section 7.2.1.b.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SRBT=10    |    Length     |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      MFL      |                    HCNL                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Median interarrival jitter                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Median fraction lost (MFL): 8 bits
   The median fraction lost indicated by Receiver Reports forwarded
   to this Distribution Source, expressed as a fixed point number
   with the binary point at the left edge of the field.  A value of
   all '1's indicates that the MFL value is not provided.

Highest cumulative number of packets lost (HCNL): 24 bits
   Highest 'cumulative number of packets lost' value out of the most
   recent RTCP RR packets from any of the receivers.  A value of all
   '1's indicates that the HCNL value is not provided.

Ott et al.       Internet Draft - Expires April 2010          [Page 21]

                  RTCP with Unicast Feedback


Median inter-arrival jitter: 32 bits
   Median 'inter-arrival jitter' value out of the most recent RTCP
   RR packets from the receiver set.  A value of all '1's indicates
   that this value is not provided.

The General Statistics sub-report block type (SRBT) is 10.

Note that, in case the Distribution Source and the Feedback Target
functions are disjoint, it is only possible for the Distribution
Source to determine the median of the inter-arrival jitter if all
the Feedback Targets forward all RTCP reports from the receivers
immediately and include at least the RR packet.


7.1.11 RTCP Bandwidth Indication sub-report block

This sub-report block is used to inform the Media Senders and
receivers about the maximum RTCP bandwidth that is supposed to be
used by each Media Sender or about the maximum bandwidth allowance
to be used by each receiver.  The value is applied universally to
all Media Senders or all receivers.  Each receiver MUST base its
RTCP transmission interval calculation on the average size of the
RTCP packets sent by itself. Conversely, each Media Sender MUST base
its RTCP transmission interval calculation on the average size of
the RTCP packets sent by itself.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SRBT=11    |     Length    |S|R|         Reserved          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTCP Bandwidth                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Sender (S): 1 bit
   The contained bandwidth value applies to each Media Sender.

Receivers (R): 1 bit
   The contained bandwidth value applies to each RTP receiver.

Reserved: 14 bits
   MUST be set to zero upon transmission and ignored upon reception.

RTCP Bandwidth: 32 bits
   If the S bit is set to 1, this field indicates the maximum
   bandwidth allocated to each individual Media Sender.  This also
   informs the receivers about the RTCP report frequency to expect
   from the senders.  This is a fixed point value with the binary
   point in between the second and third bytes. The value represents
   the bandwidth allocation per-receiver in kilobits per second with
   values in the range 0 <= BW < 65536.


Ott et al.       Internet Draft - Expires April 2010          [Page 22]

                  RTCP with Unicast Feedback

   If the R bit is set to 1, this field indicates the maximum
   bandwidth allocated per receiver for sending RTCP data relating
   to the session.  This is a fixed point value with the binary
   point in between the second and third bytes.  The value
   represents the bandwidth allocation per-receiver in kilobits per
   second with values in the range 0 <= BW < 65536.  Each receiver
   MUST use this value for its bandwidth allowance.

This report block SHOULD only be used when the Group and Average
Packet Size sub-report block is NOT included. The RTCP Bandwidth
Indication sub-report block type (SRBT) is 11.


7.1.12 RTCP Group and Average Packet Size Sub-report Block

This sub-report block is used to inform the Media Senders and
receivers about the size of the group (used for calculating feedback
bandwidth allocation) and the average packet size of the group.
This sub-report MUST always be present, appended to every RSI
packet, unless an RTCP Bandwidth indication sub-report block is
included (in which case it MAY but need not be present).

  Note: The RTCP Bandwidth Indication sub-report block allows the
  Distribution Source to hide the actual group size from the
  receivers while still avoiding feedback implosion.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SRBT=12    |    Length     |     Average Packet Size       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Receiver Group Size                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Group size: 32 bits
   This field provides the Distribution Source's view of the number
   of receivers in a session. Note that the number of Media Senders
   is not explicitly reported since it can be derived by observing
   the RTCP SR packets forwarded by the Distribution Source. The
   group size is calculated according to the rules outlined in [1].
   When this sub-report block is included, this field MUST always be
   present.

Average RTCP packet size: 16 bits
   This field provides the Distribution Source's view of the average
   RTCP packet size as locally calculated following the rules
   defined in [1].  The value is an unsigned integer counting
   octets.  When this sub-report block is included, this field MUST
   always be present.

The Group and Average Packet Size sub-report block type (SRBT) is
12.

Ott et al.       Internet Draft - Expires April 2010          [Page 23]

                  RTCP with Unicast Feedback



7.2 Distribution Source behavior

In the Distribution Source Feedback Summary Model, the Distribution
Source (the unicast Feedback Target) MUST listen for unicast RTCP
packets sent to the RTCP port.  All RTCP packets received on this
port MUST be processed by the Distribution Source as described
below.  The processing MUST take place per Media Sender SSRC about
which receiver reports are received.

The Distribution Source acts like a regular RTCP receiver.  In
particular, it receives an RTP stream from each RTP Media Sender(s)
and MUST calculate the proper reception statistics for these RTP
streams.  It MUST transmit the resulting information as report
blocks contained in each RTCP packet it sends (in an RR packet).

     Note: This information may help to determine the transmission
     characteristics of the feed path from the RTP sender to the
     Distribution Source (if these are separate entities).

The Distribution Source is responsible for accepting RTCP packets
from the receivers, and interpreting and storing per-receiver
information as defined in [1].  The importance of providing these
functions is apparent when creating the RSI and sub-report block
reports, since incorrect information can have serious implications.
Section 11 addresses the security risks in detail.

As defined in [1], all RTCP reports from the Distribution Source
MUST start with an RR report followed by any relevant SDES fields.
Then, the Distribution Source MUST append an RSI header and sub-
reports containing any summarization specific data.  In addition,
either the Group and Average Packet size sub-report or the Receiver
RTCP Bandwidth sub-report block MUST be appended to the RSI header.

A Distribution Source has the option of masking the Group size by
including only an RTCP bandwidth sub-report.  If both sub-reports
are included, the receiver is expected to give precedence to the
information contained in the Receiver RTCP Bandwidth sub-report.

The Receiver RTCP Bandwidth sub-report block provides the
Distribution Source with the capability to control the amount of
feedback from the receivers and the bandwidth value MAY be increased
or decreased based upon the requirements of the Distribution Source.
Regardless of the value selected by the Distribution Source for the
Receiver RTCP Bandwidth sub-report block, the Distribution Source
MUST continue to forward Sender Reports and RSI packets at the rate
allowed by the total RTCP bandwidth allocation. See Section 9 for
further details about the frequency of reports.

A Distribution Source MAY start out reporting Group size and switch
to Receiver RTCP Bandwidth reporting later on and vice versa.  If
the Distribution Source does so, it SHOULD ensure that the


Ott et al.       Internet Draft - Expires April 2010          [Page 24]

                  RTCP with Unicast Feedback

correspondingly indicated values for the Receiver RTCP Bandwidth
roughly match, i.e., are at least the same order of magnitude.

In order to identify SSRC collisions, the Distribution 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 Distribution 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).


7.2.1 Receiver Report Aggregation

The Distribution Source is responsible for aggregating reception
quality information received in RR packets.  In doing so, the
Distribution Source MUST consider the report blocks received in
every RR packet and MUST NOT consider the report blocks of an SR
packet.

    Note: the receivers will get the information contained in the SR
    packets anyway by packet forwarding so that duplication of this
    information should be avoided.

For the optional sub-report blocks, the Distribution Source MAY
decide which are the most significant feedback values to convey and
MAY choose not to include any.  The packet format provides
flexibility in the amount of detail conveyed by the data points.
There is a tradeoff between the granularity of the data and the
accuracy of the data based on the multiplicative factor (MF), the
number of buckets, and the min and max values.  In order to focus on
a particular region of a distribution, the Distribution Source can
adjust the minimum and maximum values, and either increase the
number of buckets and possibly the factorization, or decrease the
number of buckets and provide more accurate values.  See Appendix B
for detailed examples on how to convey a summary of RTCP Receiver
Reports as RSI sub-report block information.

For each value the Distribution Source decides to include in an RSI
packet, it MUST adhere to the following measurement rules.

a)  If the Distribution Source intends to use a sub-report to convey
    a distribution of values (sections 7.1.3 to 7.1.7), it MUST keep
    per receiver state, i.e., remember the last value V reported by
    the respective receiver.  If a new value is reported by a
    receiver, the existing value MUST be replaced by the new one.
    The value MUST be deleted (along with the entire entry) if the

Ott et al.       Internet Draft - Expires April 2010          [Page 25]

                  RTCP with Unicast Feedback

    receiver is timed out (as per section 6.3.5 of [1]) or has sent
    a BYE packet (as per section 6.3.7 of [1]).

    All the values collected in this way MUST be included in the
    creation of the subsequent distribution sub-report block.

    The results should correspond as closely as possible to the
    values received during the interval since the last report.  The
    Distribution Source may stack as many sub-report blocks as
    required in order to convey different distributions.  If the
    distribution size exceeds the largest packet length (1008 bytes
    data portion), more packets MAY be stacked with additional
    information (but in total SHOULD NOT exceed the path MTU).

    All stacked sub-reports MUST be internally consistent, i.e.,
    generated from the same session data. Overlapping of
    distributions is therefore allowed, and variation in values
    should only occur as a result of data set granularity, with the
    more accurate bucket sizes taking precedence in the event that
    values differ. Non-divisible values MUST be rounded up or down
    to the closest bucket value, and the number of data buckets must
    always be an even number, padding where necessary with an
    additional zero bucket value to maintain consistency.

    Note: This intentionally provides persistent full coverage of
    the entire session membership to avoid oscillations due to
    changing membership samples.

    Scheduling the transmission of summarization reports is left to
    the discretion of the Distribution Source.  However, the
    Distribution Source MUST adhere to the bandwidth limitations for
    receiver reports as defined for the respective AV profile in
    use.

b)  If the Distribution Source intends to report a short summary
    using the General Statistics sub-report block format defined in
    section 7.1.10, for EACH of the values included in the report
    (AFL, HCNL, average interarrival jitter), it MUST keep a timer
    T_summary as well as a sufficient set of variables to calculate
    the summaries for the last three reporting intervals.  This MAY
    be achieved by keeping per-receiver state, i.e., remember the
    last value V reported by the respective receiver, or by
    maintaining summary variables for each of these intervals.

    The summary values are included here to reflect the current
    group situation. By recording the last three reporting intervals
    the Distribution Source incorporates reports from all members
    while allowing for individual RTCP receiver report packet
    losses.  The process of collecting these values also aims to
    avoid resetting any of the values and then having to send out an
    RSI report based upon just a few values collected.  If data is
    available for less than three reporting intervals (as will be
    the case for the first two reports sent), only those values
    available are considered.

Ott et al.       Internet Draft - Expires April 2010          [Page 26]

                  RTCP with Unicast Feedback


    The timer T_summary MUST be initialized as T_summary = 1.5*Td,
    where Td is the deterministic reporting interval, and MUST be
    updated following timer reconsideration whenever the group size
    or the average RTCP size ("avg_rtcp_size") changes.  This choice
    should allow each receiver to report once per interval.

          Td
         __^__
      t0/     \   t1        t2        t3        t4        t5
     ---+---------+---------+---------+---------+---------+------->
        \____ ____/         :         :         :         :
        :    V    :         :         :         :         :
        :T_summary:         :         :         :         :
        : =1.5*Td :         :         :         :         :
        \______________ ______________/         :         :
                  :    V    :                   :         :
                  : 3*T_summary                 :         :
                  :         :                   :         :
                  \______________ ______________/         :
                            :    V                        :
                            : 3*T_summary                 :
                            :                             :
                            \______________ ______________/
                                           V
                                        3*T_summary

    Figure 2: Overview of summarization reporting

    Figure 2 depicts how the summarization reporting shall be
    performed.  At time t3, the RTCP reports collected from t0
    through t3 are included in the RSI reporting, at time t4, those
    from t1 through t4, and so on.  The RSI summary report sent MUST
    NOT include any RTCP report from more than three reporting
    intervals ago; e.g., the one sent at time t5, must not include
    reports received at the Distribution Source prior to t2.


7.2.2 Handling Other RTCP Packets from RTP receivers

When following the Feedback Summary Model the Distribution Source
MAY reflect any other RTCP packets of potential relevance to the
receivers (such as APP, RTPFB, PSFB) to the receiver group and MAY
decide not to forward other RTCP packets not needed as such by the
receivers (such as BYE, RR, SDES because the Distribution Source
performs collision resolution, group size estimation, and RR
aggregation).  The Distribution Source MUST NOT forward RR packets
to the receiver group.

If the Distribution Source is able to interpret and aggregate
information contained in any RTCP packets other than RR, it MAY
include the aggregated information along with the RSI packet in its
own compound RTCP packet.


Ott et al.       Internet Draft - Expires April 2010          [Page 27]

                  RTCP with Unicast Feedback

Aggregation MAY be a null operation, i.e., the Distribution Source
MAY simply append one or more RTCP packets from receivers to the
compound RTCP packet (containing at least RR, SDES and RSI from the
Distribution Source).

     Note: This is likely to be useful only for a few cases, e.g.,
     to forward aggregated information from RTPFB Generic NACK
     packets and thereby maintain the damping property of [15].

     Note: This entire processing rule implies that the flow of
     information contained in non-RR RTCP packets may terminate at
     the Distribution Source depending on its capabilities and
     configuration.

The configuration of the RTCP SSM media session (expressed in SDP)
MUST specify explicitly which processing the Distribution Source
will apply to which RTCP packets.  See section 10.1 for details.


7.2.3 Receiver Report Forwarding

If the Media Sender(s) are not part of the SSM group for RTCP packet
reflection, the Distribution Source MUST explicitly inform the Media
Senders of the receiver group.  To achieve this, the Distribution
Source has two options: Either it forwards the RTCP RR and SDES
packets received from the receivers to the Media Sender(s).  Or, if
the Media Senders also support the RTCP RSI packet, the Distribution
Source sends the RSI packets not just to the receivers but also to
the Media Senders.

If the Distribution Source decides to forward RR and SDES packets
unchanged, it MAY also forward any other RTCP packets to the
senders.

If the Distribution Source decides to forward RSI packets to the
senders, the considerations of 7.2.2 apply.


7.2.4 Handling Sender Reports

The Distribution Source also receives RTCP (including SR) packets
from the RTP Media Senders.

The Distribution Source MUST forward all RTCP packets from the Media
Senders to the RTP receivers.

If there is more than one Media Sender and these Media Senders do
not communicate via ASM with the Distribution Source and each other,
the Distribution Source MUST forward each RTCP packet from any one
Media Sender to all other Media Senders.


7.2.5 RTCP Data Rate Calculation


Ott et al.       Internet Draft - Expires April 2010          [Page 28]

                  RTCP with Unicast Feedback

As noted above, the Distribution Source is a receiver from an RTP
perspective.  The Distribution Sources MUST calculate its
deterministic transmission interval Td as every other receiver,
however, it MAY adjust its available data rate depending on the
destination transport address and its local operation:

1. For sending its own RTCP reports to the SSM group towards the
   receivers, the Distribution Source MAY use up to the joint share
   of all receivers as it is forwarding summaries on behalf of all
   of them.  Thus, the Distribution Source MAY send its reports up
   to every Td/R time units, with R being the number of receivers.

2. For sending its own RTCP reports to the Media Senders only (i.e.,
   if the Media Senders are not part of the SSM group), the
   allocated rate depends on the operation of the Distribution
   Source:

a) If the Distribution Source only sends RSI packets along with its
   own RTCP RR packets, the same rate calculation applies as for 1
   above.

b) If the Distribution Source forwards RTCP packets from all other
   receivers to the Media Senders, then it MUST adhere to the same
   bandwidth share for its own transmissions as all other receivers
   and use the calculation as per [1].


7.2.6 Collision Resolution

A Distribution Source observing RTP packets from a Media Sender with
an SSRC that collides with its own chosen SSRC MUST change its own
SSRC following the procedures of [1] and MUST do so immediately
after noticing.

A Distribution Source MAY use out-of-band information about the
Media Sender SSRC(s) used in the media session when available to
avoid SSRC collisions with Media Senders.  Nevertheless, the
Distribution Source MUST monitor Sender Report (SR) packets to
detect any changes, observe collisions, and then follow the above
collision resolution procedure.

For collision resolution between the Distribution Source and
receivers or the Feedback Target(s) (if a separate entity as
described in the next subsection), the Distribution Source and the
Feedback Target (if separate) operate similar to ordinary receivers.


7.3 Disjoint Distribution Source and Feedback Target

If the Distribution Source and the Feedback Target are disjoint, the
processing of the Distribution Source is limited by the amount of
RTCP feedback information made available by the Feedback Target.



Ott et al.       Internet Draft - Expires April 2010          [Page 29]

                  RTCP with Unicast Feedback

The Feedback Target(s) MAY simply forward all RTCP packets incoming
from the RTP receivers to the Distribution Source in which case the
Distribution Source will have all the information available
necessary to perform all the functions described above.

The Feedback Target(s) MAY also perform aggregation of incoming RTCP
packets and send only aggregated information to the Distribution
Source.  In this case, the Feedback Target(s) MUST use correctly
formed RTCP packets to communicate with the Distribution Source and
they MUST operate in concert with the Distribution Source so that
the Distribution Source and the Feedback Target(s) appear operating
as a single entity.  The Feedback Target(s) MUST report their
observed receiver group size to the Distribution Source, either
explicitly by means of RSI packets or implicitly by forwarding all
RR packets.

     Note: For example, for detailed statistics reporting, the
     Distribution Source and the Feedback Target(s) may need to
     agree on a common reporting granularity so that the
     Distribution Source can aggregate the buckets incoming from
     various Feedback Targets into a coherent report sent to the
     receivers.

The joint behavior or Distribution Source and Feedback Target(s)
MUST be reflected in the (SDP-based) media session description as
per 7.2.2.

If the Feedback Target performs summarization functions, it MUST
also act as a receiver and choose a unique SSRC for its own
reporting towards the Distribution Source.  The collision resolution
considerations for receivers apply.


7.4 Receiver behavior

An RTP receiver MUST process RSI packets and adapt session
parameters such as the RTCP bandwidth based on the information
received.  The receiver no longer has a global view of the session,
and will therefore be unable to receive information from individual
receivers aside from itself.  However, the information conveyed by
the Distribution Source can be extremely detailed, providing the
receiver with an accurate view of the session quality overall,
without the processing overhead associated with listening to and
analyzing all Receiver Reports.

The RTP receiver MUST process the report blocks contained in any RTP
SR and RR packets to complete its view of the RTP session.

The SSRC collision list MUST be checked against the SSRC selected by
the receiver to ensure there are no collisions as MUST be incoming
RTP packets from the Media Senders.  A receiver observing RTP
packets from a Media Sender with an SSRC that collides with its own
chosen SSRC MUST change its own SSRC following the procedures of


Ott et al.       Internet Draft - Expires April 2010          [Page 30]

                  RTCP with Unicast Feedback

[1].  The receiver MUST do so immediately after noticing and before
sending any (further) RTCP feedback messages.

A Group and Average Packet size sub-report block is most likely to
be appended to the RSI header (either a Group size sub-report or an
RTCP Bandwidth sub-report MUST be included).  The Group size n
allows a receiver to calculate its share of the RTCP bandwidth, r.
Given R, the total available RTCP bandwidth share for receivers (in
the SSM RTP session) r = R/(n).  For the group size calculation, the
RTP receiver MUST NOT include the Distribution Source, i.e. the only
RTP receiver sending RSI packets.

The Receiver RTCP Bandwidth field MAY override this value.  If the
Receiver RTCP Bandwidth field is present, the receiver MUST use this
value as its own RTCP reporting bandwidth r.

If the RTCP Bandwidth field was used by the Distribution Source in
an RTCP session but this field was not included in the last five
RTCP RSI reports, the receiver MUST revert to calculating its
bandwidth share based upon the Group size information.

If the receiver has not received any RTCP RSI packets from the
Distribution Source for a period of five times the sender reporting
interval, it MUST cease transmitting RTCP receiver reports until the
next RTCP RSI packet is received.

The receiver can use the summarized data as desired.  This data is
most useful in providing the receiver with a more global view of the
conditions experienced by other receivers, and enables the client to
place itself within the distribution and establish the extent to
which its reported conditions correspond to the group reports as a
whole.  The appendix B (section 16) provides further information and
examples of data processing at the receiver.

The receiver SHOULD assume that any sub-report blocks in the same
packet correspond to the same data set received by the Distribution
Source during the last reporting time interval.  This applies to
packets with multiple blocks, where each block conveys a different
range of values.

A receiver MUST NOT rely on all of the RTCP packets it sends
reaching the Media Senders or any other receiver.  While RR
statistics will be aggregated, BYE packets processed, and SSRC
collisions usually be announced, processing and/or forwarding of
further RTCP packets is up to the discretion of the Distribution
Source and will be performed as specified in the session
description.

If a receiver has out-of-band information available about the Media
Sender SSRC(s) used in the media session, it MUST NOT use the same
SSRC for itself.  The receiver MUST be aware that such out-of-band
information may be outdated (i.e., that the sender SSRC(s) have
changed, and MUST follow the above collision resolution procedure if
necessary.

Ott et al.       Internet Draft - Expires April 2010          [Page 31]

                  RTCP with Unicast Feedback


A receiver MAY use such Media Sender SSRC information when available
but MUST beware of potential changes to the SSRC (which can only be
learned from Sender Report (SR) packets).


7.5 Media Sender Behavior

Media Senders listen on a unicast or multicast transport address for
RTCP reports sent by the receivers (and forwarded by the
Distribution Source) or other Media Senders (optionally forwarded by
the Distribution Source).

Unlike in the case of the simple forwarding model, Media Senders
MUST be able to process RSI packets from the Distribution Source to
determine the group size and their own RTCP bandwidth share.  Media
Senders MUST also be capable of determining the group size (and
their corresponding RTCP bandwidth share) from listening to
(forwarded) RTCP RR and SR packets (as mandated in [1]).

As long as they send RTP packets they MUST also send RTCP SRs as
defined in [1].

A Media Sender that observes an SSRC collision with another entity
that is not also a Media Sender MAY delay its own collision
resolution actions as per [1] by 5*1.5*Td with Td being the
deterministic calculated reporting interval for receivers to see
whether the conflict still exists.  SSRC collisions with other Media
Senders MUST be acted upon immediately.

     Note: This gives precedence to Media Senders and places the
     burden of collision resolution on RTP receivers.

Sender SSRC information MAY be communicated out-of-band, e.g., by
means of SDP media descriptions.  Therefore, senders SHOULD NOT
eagerly change their own SSRC eagerly or unnecessarily.


8. Mixer/Translator issues

The original RTP specification allows a session to use mixers and
translators to help 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 document apply
equally to either a mixer or translator, the latter 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

Ott et al.       Internet Draft - Expires April 2010          [Page 32]

                  RTCP with Unicast Feedback

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 [5] for the
single source session (Section 11) and use the feedback mechanism
indicated. Implementers of receivers SHOULD be aware, when a mixer-
translator is present in the session, more than one Media Sender may
be active since the mixer-translator may be forwarding traffic to
the SSM receivers from either multiple unicast sources or from an
ASM session. Receivers SHOULD still forward unicast RTCP reports in
the usual manner to their assigned Feedback Target/Distribution
Source, which -- by assumption -- 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 + summarization reporting between more
than one source may be complicated unless the mixer-translator is
capable of summarization.


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 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 and subsequent unicast feedback to the source,
where the mixer-translator is not acting as the Distribution Source,
is only allowed if the mixer-translator can conduct the same source
authentication as required by the receivers. A translator MAY
forward unicast packets on behalf of a client, but SHOULD NOT
translate between multicast-to-unicast flows towards the source
without authenticating the source of the feedback address
information.


9. Transmission interval calculation

The Control Traffic Bandwidth referred to in [1] is an arbitrary
amount that is intended to be supplied by a session management
application (e.g., sdr [21]) or decided based upon the bandwidth of
a single sender in a session.

The RTCP transmission interval calculation remains the same as in
the original RTP specification [1] or uses the algorithm in [10]
when bandwidth modifiers have been specified for the session.

Ott et al.       Internet Draft - Expires April 2010          [Page 33]

                  RTCP with Unicast Feedback



9.1 Receiver RTCP Transmission

If the Distribution Source is operating in Simple Feedback mode
(which may be indicated in the corresponding session description for
the media session but which the receiver also notices from the
absence of RTCP RSI packets), a receiver MUST calculate the number
of other members in a session based upon its own SSRC count derived
from the forwarded Sender and Receiver Reports it receives. The
receiver MUST calculate the average RTCP packet size from all the
RTCP packets it receives.

If the Distribution Source is operating in Distribution Source
Feedback Summary mode, the receiver MUST use either the Group size
field and the average RTCP packet size field, or the Receiver
Bandwidth Field from the respective sub-report blocks appended to
the RSI packet.

A receiver uses these values as input to the calculation of the
deterministic calculated interval as per [1] and [10].


9.2 Distribution Source RTCP Transmission

If operating in Simple Feedback mode, the Distribution Source MUST
calculate the transmission interval for its Receiver Reports and
associated RTCP packets based upon the above control traffic
bandwidth and MUST count itself as RTP receiver.  Receiver Reports
will be forwarded as they arrive without further consideration.  The
Distribution Source MAY choose to validate that all or selected
receivers roughly adhere to the calculated bandwidth constraints and
MAY choose to drop excess packets for receivers that do not.  In all
cases, the average RTCP packet size is determined from the Media
Senders' and receivers' RTCP packets forwarded and those originated
by the Distribution Source.

If operating in Distribution Source Feedback Summary mode, the
Distribution Source does not share the forward RTCP bandwidth with
any of the receivers.  Therefore, the Distribution Source SHOULD use
the full RTCP bandwidth for its receiver reports and associated RTCP
packets, as well as RTCP RSI packets.  In this case, the average
RTCP packet size is only determined from the RTCP packets originated
by the Distribution Source.

The Distribution Source uses these values as input to the
calculation of the deterministic calculated interval as per [1] and
[10].


9.3 Media Senders RTCP Transmission

In Simple Feedback Mode, the Media Senders obtain all RTCP SRs and
RRs as they would in an ASM session, except that the packets are

Ott et al.       Internet Draft - Expires April 2010          [Page 34]

                  RTCP with Unicast Feedback

forwarded by the Distribution Source.  They MUST perform their RTCP
group size estimate and calculation of the deterministic
transmission interval as per [1] and [10].

In Distribution Source Feedback Summary Mode, the Media Senders
obtain all RTCP SRs as they would in an ASM session.  They receive
either RTCP RR reports as in ASM (in case these packets are
forwarded by the Distribution Source) or RSI packets containing
summaries.  In the former case, they MUST perform their RTCP group
size estimate and calculation of the deterministic transmission
interval as per [1] and [10].  In the latter case, they MUST combine
the information obtained from the Sender Reports and the RSI packets
to create a complete view of the group size and the average RTCP
packet size and perform the calculation of the deterministic
transmission interval as per [1] and [10] based upon these input
values.


9.4 Operation in conjunction with AVPF and SAVPF

If the RTP session is an AVPF session [15] or an SAVPF session [28]
(as opposed to a regular AVP [6] session) the receivers MAY modify
their RTCP report scheduling as defined in [15].  Use of AVPF or
SAVPF does not affect the Distribution Source's RTCP transmission or
forwarding behavior.

It is RECOMMENDED that a Distribution Source and possible separate
Feedback Target(s) be configured to forward AVPF/SAVPF-specific RTCP
packets in order not to counteract the damping mechanism built into
AVPF; optionally, they MAY aggregate the feedback information from
the receivers as per section 7.2.2.  If only generic feedback
packets are in use that are understood by the Distribution Source
and that can easily be aggregated, the Distribution MAY combine
several incoming RTCP feedback packets and forward the aggregate
along with its next RTCP RR/RSI packet.  In any case, the
Distribution Source and Feedback Target(s) SHOULD minimize the extra
delay when forwarding feedback information but the Distribution
Source MUST stay within its RTCP bandwidth constraints.

In the event that specific APP packets without a format and
summarization mechanism understood by the Feedback Target(s) and/or
the Distribution Source are to be used, it is RECOMMENDED that such
packets are forwarded with minimal delay.  Otherwise, the capability
of receiver to send timely feedback messages is likely to be
affected.


10. SDP Extensions

The Session Description Protocol (SDP) [5] is used as a means to
describe media sessions in terms of their transport addresses,
codecs, and other attributes. Signaling that RTCP feedback will be
provided via unicast as specified in this document requires another
session parameter in the session description. Similarly, other SSM

Ott et al.       Internet Draft - Expires April 2010          [Page 35]

                  RTCP with Unicast Feedback

RTCP feedback parameters need to be provided, such as the
summarization 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
document (and that also need to be registered with IANA).


10.1 SSM RTCP Session Identification

A new session level attribute MUST be used to indicate the use of
unicast instead of multicast feedback: "rtcp-unicast".

This attribute uses one parameter to specify the mode of operation.
An optional set of parameters specifies the behavior for RTCP packet
types (and subtypes).

rtcp-unicast:reflection

     This attribute MUST be used to indicate the "Simple Feedback"
     mode of operation where packet reflection is used by the
     Distribution Source (without further processing).

rtcp-unicast:rsi *(SP <processing>:<rtcp-type>])

     This attribute MUST be used to indicate the "Distribution
     Source Feedback Summary" mode of operation.  In this mode, a
     list or parameters may be used to explicitly specify how RTCP
     packets originated by receivers are handled.  Options for
     processing a given RTCP packet type are:

     aggr:    The Distribution Source has means for aggregating the
              contents of the RTCP packets and will do so.

     forward: The Distribution Source will forward the RTCP packet
              unchanged.

     term:    The Distribution Source will terminate the RTCP
              packet.

    The default rules applying if no parameters are specified are as
    follows:

    RR and SDES packets MUST be aggregated and MUST lead to RSI
    packets being generated.  All other RTP packets MUST be
    terminated at the Distribution Source (or Feedback Target(s)).

    The SDP description needs only specify deviations from the
    default rules.  Aggregation of RR packets and forwarding of SR
    packet MUST NOT be changed.

The token for the new SDP attribute is "rtcp-unicast" and the formal
SDP ABNF syntax for the new attribute value is as follows:

att-value  = "reflection"

Ott et al.       Internet Draft - Expires April 2010          [Page 36]

                  RTCP with Unicast Feedback

           / "rsi" *(SP rsi-rule)

rsi-rule   = processing ":" rtcp-type

processing = "aggr" / "forward" / "term" / token ;keep it extensible

rtcp-type  = 3*3DIGIT    ;the RTCP type (192, 193, 202--208)


10.2 SSM Source Specification

In a Source-Specific Multicast RTCP session, the address of the
Distribution Source needs to be indicated both for source-specific
joins to the multicast group, and for addressing unicast RTCP
packets on the backchannel from receivers to the Distribution
Source.

This is achieved by following the proposal for SDP source filters
documented in [4]. According to the specification, for SSM RTCP only
the inclusion mode ("a=source-filter:incl") MUST be used.

There SHOULD be exactly one "a=source-filter:incl" attribute listing
the address of the Distribution Source.  The RTCP port MUST be
derived from the m= line of the media description.

An alternative Feedback Target address and port MAY be supplied
using the SDP RTCP attribute [7], e.g., a=rtcp:<port> IN IP4
192.0.2.1.  This attribute only defines the transport address of the
Feedback Target and does not affect the SSM group specification for
media stream reception.

Two "source-filter" attributes MAY be present to indicate an IPv4
and an IPv6 representation of the same Distribution Source.


10.3 RTP Source Identification

The SSRC information for the Media Sender(s) MAY be communicated
explicitly out of band (i.e., outside the RTP session).  One option
for doing so is the Session Description Protocol (SDP) [5].  If such
an indication is desired, the "ssrc" attribute [12] MUST be used for
this purpose.  As per [12], the "cname" Source Attribute MUST be
present.  Further Source Attributes MAY be specified as needed.

If used in an SDP session description of an RTCP-SSM session, the
ssrc MUST contain the SSRC intended to be used by the respective
Media Sender and the cname MUST equal the CNAME for the Media
Sender.  If present, the role SHOULD indicate the function of the
RTP entity identified by this line for which presently only the
"media-sender" is defined.

Example:

    a=ssrc:314159 cname:iptv-sender@example.com

Ott et al.       Internet Draft - Expires April 2010          [Page 37]

                  RTCP with Unicast Feedback


In the above example, the Media Sender is identified to use the SSRC
identifier 314159 and the CNAME iptv-sender@example.com.


11. Security Considerations

The level of security provided by the current RTP/RTCP model MUST
NOT be diminished by the introduction of unicast feedback to the
source. This section identifies the security weaknesses introduced
by the feedback mechanism, potential threats, and level of
protection that MUST be adopted. Any suggestions on increasing the
level of security provided to RTP sessions above the current
standard are RECOMMENDED but OPTIONAL. The final section outlines
some security frameworks that are suitable to conform to this
specification.


11.1 Assumptions

RTP/RTCP is a protocol that carries real-time multimedia traffic,
and therefore a main requirement is for any security framework to
maintain as low overhead as possible. This includes the overhead of
different applications and types of cryptographic operations, as
well as the overhead to deploy or to create security infrastructure
for large groups.

Although the distribution of session parameters, typically encoded
as SDP objects, through SAP [22], e-mail, or the web, is beyond the
scope of this document, it is RECOMMENDED that the distribution
method employs adequate security measures to ensure the integrity
and authenticity of the information. Suitable solutions that meet
the security requirements outlined here are included at the end of
this section.

In practice, the multicast and group distribution mechanism, e.g.,
the SSM routing tree, is not immune to source IP address spoofing or
traffic snooping, however such concerns are not discussed here. In
all the following discussions, security weaknesses are addressed
from the transport level or above.


11.2 Security threats

Attacks on media distribution and the feedback architecture proposed
in this document may take a variety of forms. An outline of the
types of attacks in detail:

a) Denial of Service (DoS)

   DoS is a major area of concern. Due to the nature of the
   communication architecture a DoS can be generated in a number of
   ways by using the unicast feedback channel to the attacker's
   advantage.

Ott et al.       Internet Draft - Expires April 2010          [Page 38]

                  RTCP with Unicast Feedback


b) Packet Forgery

   Another potential area for attack is packet forgery. In
   particular, it is essential to protect the integrity of certain
   influential packets since compromise could directly affect the
   transmission characteristics of the whole group.

c) Session Replay

   The potential for session recording and subsequent replay is an
   additional concern.  An attacker may not actually need to
   understand packet content, but simply have the ability to record
   the data stream and, at a later time, replay it to any receivers
   that are listening.

d) Eavesdropping on a session

   The consequences of an attacker eavesdropping on a session
   already constitutes a security weakness; in addition,
   eavesdropping might facilitate other types of attacks, and is
   therefore considered a potential threat. For example, an attacker
   might be able to use the eavesdropped information to perform an
   intelligent DoS attack.


11.3 Architectural Contexts

To better understand the requirements of the solution, the threats
outlined above are addressed for each of the three communication
contexts:

a) Source-to-Receiver communication

   The downstream communication channel, from the source to the
   receivers, is critical to protect as it controls the behavior of
   the group; it conveys the bandwidth allocation for each receiver
   and hence the rate at which the RTCP traffic is unicast directly
   back to the source. All traffic that is distributed over the
   downstream channel is generated by a single source. Both the RTP
   data stream and the RTCP control data from the source are
   included in this context, with the RTCP data generated by the
   source being indirectly influenced by the group feedback.

   The downstream channel is vulnerable to four types of attacks. A
   denial of service attack is possible, but less of a concern. The
   worst case effect would be the transmission of large volumes of
   traffic over the distribution channel with the potential to reach
   every receiver, but only on a one-to-one basis. Consequently,
   this threat is no more pronounced than the current multicast ASM
   model. The real danger of denial of service attacks in this
   context comes indirectly via compromise of the source RTCP
   traffic. If receivers are provided with an incorrect group size
   estimate or bandwidth allowance, the return traffic to the source

Ott et al.       Internet Draft - Expires April 2010          [Page 39]

                  RTCP with Unicast Feedback

   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 configuration (e.g.,
   typing) error, could directly create a denial of service attack
   on another host.

   An additional concern relating to Denial of Service attacks would
   come indirectly through the generation of fake BYE packets
   causing the source to adjust the advertised group size. A
   Distribution Source MUST follow the correct rules for timing out
   members in a session prior to reporting a change in the group
   size, which allows the authentic SSRC sufficient time to continue
   to report and consequently cancel the fake BYE report.

   The danger of Packet Forgery in the worst case may be to
   maliciously instigate a denial of service attack, e.g., if an
   attacker were capable of spoofing the source address and
   injecting incorrect packets into the data stream or intercepting
   the source RTCP traffic and modifying the fields.

   The Replay of a Session would have the effect of recreating the
   receiver feedback to the source address at a time when the source
   is not expecting additional traffic from a potentially large
   group. The consequence of this type of attack may be less
   effective on its own, but in combination with other attacks might
   be serious.

   Eavesdropping on the session would provide an attacker with
   information on the characteristics of the source-to-receiver
   traffic such as the frequency of RTCP traffic. If RTCP traffic is
   unencrypted, this might also provide valuable information on
   characteristics such as group size, Media Source SSRC(s) and
   transmission characteristics of the receivers back to the source.

b) Receiver-to-Distribution-Source communication

   The second context is the return traffic from the group to the
   Distribution Source. This traffic should only consist of RTCP
   packets, and should include receiver reports, SDES information,
   BYE reports, extended reports (XR), feedback messages (RTPFB,
   PSFB) and possibly Application specific packets. The effects of
   compromise on a single or subset of receivers are not likely to
   have as great an impact as in context (a), however much of the
   responsibility for detecting compromise of the source data stream
   relies on the receivers.

   The effects of compromise of critical Distribution Source control
   information can be seriously amplified in the present context. A
   large group of receivers may unwittingly generate a distributed
   DoS attack on the Distribution Source in the event that the
   integrity of the source RTCP channel has been compromised and the
   compromise is not detected by the individual receivers.



Ott et al.       Internet Draft - Expires April 2010          [Page 40]

                  RTCP with Unicast Feedback

   An attacker capable of instigating a Packet Forgery attack could
   introduce false RTCP traffic and create fake SSRC identifiers.
   Such attacks might slow down the overall control channel data
   rate, since an incorrect perception of the group size may be
   created. Similarly, the creation of fake BYE reports by an
   attacker would cause some group size instability, but should not
   be effective as long as the correct timeout rules are applied by
   the source in removing SSRC entries from its database.

   A replay attack on receiver return data to the source would have
   the same implications as the generation of false SSRC identifiers
   and RTCP traffic to the source. Therefore, ensuring authenticity
   and freshness of the data source is important.

   Eavesdropping in this context potentially provides an attacker
   with a great deal of potentially 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 allowances.

c) Receiver-to-Feedback-Target communication

   The third context is the return traffic from the group to the
   Feedback Target. It suffers from the same threats as the
   receiver-to-source context, with the difference being that now a
   large group of receivers may unwittingly generate a distributed
   DoS attack (DDos) on the Feedback Target, where it is impossible
   to discern if the DDoS is deliberate or due merely to a
   misconfiguation of the feedback target address.  While deliberate
   attacks can be mitigated by properly authenticating messages
   communicating the feedback target address -- i.e., the SDP
   session description and the Feedback Target Address sub-report
   block carried in RTCP --, a misconfigured address will originate
   from an authenticated source and hence cannot be prevented using
   security mechanisms.

   Furthermore, the Feedback Target is unable to communicate its
   predicament with either the session Source nor the session
   receivers.  From the feedback packets received, the Feedback
   Target cannot tell the SSM multicast group the feedback belongs
   to nor the Distribution Source, making further analysis and
   suppression difficult.  The Feedback Target may not even support
   RTCP or listen on the port number in question.

   Note that because the DDoS occurs inside of the RTCP session, and
   because the unicast receivers adhere to transmission interval
   calculations [1][10], the bandwidth misdirected toward the
   Feedback Target in the misconfigured case will be limited to a
   percentage of the session bandwidth, i.e., the Control Traffic
   Bandwidth established for the session.

11.4 Requirements in each context


Ott et al.       Internet Draft - Expires April 2010          [Page 41]

                  RTCP with Unicast Feedback

To address these threats, this section presents the security
requirements for each context.

a) The main threat in the source-to-receiver context concerns denial
   of service attacks through possible packet forgery. The forgery
   may take the form of interception and modification of packets
   from the source, or simply injecting false packets into the
   distribution channel. To combat these attacks, data integrity and
   source authenticity MUST be applied to source traffic. Since the
   consequences of eavesdropping do not affect the operation of the
   protocol, confidentiality is not a requirement in this context.
   However without confidentiality, access to personal and group
   characteristics information would be unrestricted to an external
   listener. Therefore confidentiality is RECOMMENDED.

b) The threats in the receiver-to-source context also concern the
   same kinds of attacks but are considered less important than the
   downstream traffic compromise. All the security weaknesses are
   also applicable to the current RTP/RTCP security model and
   therefore only recommendations are made towards protection from
   compromise. Data integrity is RECOMMENDED to ensure that
   interception and modification of an individual receiver's RTCP
   traffic can be detected. This would protect against the false
   influence of group control information and the potentially more
   serious compromise of future services provided by the
   distribution functionality. In order to ensure security, data
   integrity and authenticity of receiver traffic is therefore also
   RECOMMENDED. The same situation applies as in the first context
   with respect to data confidentiality, and it is RECOMMENDED that
   precautions should be taken to protect the privacy of the data.

c) The threats to the receiver-to-feedback-target context are
   similar to those in the receiver-to-source context, and thus the
   recommendations to protect against them are similar.

   However there are a couple situations with broader issues to
   solve, which are beyond the scope of this document.

   1. An endpoint experiencing DDoS or the side-effects of a
      misconfigured RTCP session may not even be a participant in
      the session, i.e., may not be listening on the respective port
      number and may even support RTCP, so it will be unable to
      react within RTCP. Determining that there is a problem will be
      up to network administrators and possibly anti-malware
      software that can perform correlation across receiver nodes.

   2. With misconfiguration, unfortunately the normally desirable
      usage of SRTP and SRTCP becomes undesirable. Because the
      packet content is encrypted, neither the misconfigured
      Feedback Target nor the network administrator have the ability
      to determine the root cause of the traffic.

   In the case where the misconfigured Feedback Target happens to be
   a node participating in the session or is an RTCP-enabled node,

Ott et al.       Internet Draft - Expires April 2010          [Page 42]

                  RTCP with Unicast Feedback

   the Feedback Target Address block provides a dynamic mechanism
   for the Distribution Source to signal an alternative unicast RTCP
   feedback address to the receivers. As this type of packet MUST be
   included in every RTCP packet originated by the Distribution
   Source, all receivers would be able to obtain the corrected
   Feedback Target information.  In this manner, receiver behavior
   should remain consistent even in the face of packet loss or when
   there are late session arrivals. The only caveat is that the
   misconfigured Feedback Target is largely uninvolved in the repair
   of this situation, and thus relies on others for the detection of
   the problem.

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, SAP, or
other means. It is beyond the scope of this document to place any
strict requirements on the external communication of such
information, however suitably secure SDP communication approaches
are outlined in section 11.7.


11.5 Discussion of trust models

As identified in the previous sections, source authenticity is a
fundamental requirement of the protocol. However, it is important to
also clarify the model of trust that would be acceptable to achieve
this requirement. There are two fundamental models that apply in
this instance:

a) The shared- key model where all authorized group members share
   the same key and can equally encrypt/decrypt the data. This
   method assumes that an out-of-band method is applied to the
   distribution of the shared group key ensuring that every key-
   holder is individually authorized to receive the key, and in the
   event of member departures from the group, a re-keying exercise
   can occur. The advantage of this model is that the costly
   processing associated with one-way key authentication techniques
   is avoided, as well as the need to execute additional cipher
   operations with alternative key sets on the same data set, e.g.,
   in the event that data confidentiality is also applied. The
   disadvantage is that, for very large groups where the receiver
   set becomes effectively untrusted, a shared key does not offer
   much protection.

b) The public-key authentication model, using cryptosystems such as
   RSA-based or PGP authentication, provides a more secure method of
   source authentication at the expense of generating higher
   processing overhead. This is typically not recommended for Real-
   time data streams, but in the case of RTCP reports which are
   distributed with a minimum interval of 5 seconds, this may be a
   viable option (the processing overhead might still be too great
   for small, low-powered devices and should therefore be considered

Ott et al.       Internet Draft - Expires April 2010          [Page 43]

                  RTCP with Unicast Feedback

   with caution). Wherever possible, however, the use of public key
   source authentication is preferable to the shared key model
   identified above.

As concerns requirements for protocol acceptability, either model is
acceptable, although it is RECOMMENDED that the more secure public-
key based options should be applied wherever possible.


11.6 Recommended security solutions

This section presents some existing security mechanisms that are
RECOMMENDED to suitably address the requirements outlined in section
11.5. This is only intended as a guideline and it is acknowledged
that there are other solutions that would also be suitable to be
compliant with the specification.


11.6.1 Secure Distribution of SDP Parameters

a) SAP, HTTPS, Email -- Initial distribution of the SDP parameters
   for the session SHOULD use a secure mechanism such as the SAP
   authentication framework which allows an authentication
   certificate to be attached to the session announcements. Other
   methods might involve HTTPS or signed email content from a
   trusted source. However, some more commonly used techniques for
   distributing session information and starting media streams are
   RTSP [25] and SIP [14].

b) RTSP -- RTSP provides a client or server initiated stream control
   mechanism for real-time multimedia streams. The session
   parameters are conveyed using SDP syntax and may adopt standard
   HTTP authentication mechanisms in combination with suitable
   network (e.g. IPsec) or transport (e.g. TLS) level security.

c) SIP -- A typical use of SIP involving a unicast feedback
   identifier might be a client wishing to dynamically join a multi-
   party call on a multicast address using unicast RTCP feedback.
   The client would be required to authenticate the SDP session
   descriptor information returned by the SIP server. The
   recommended method for this, as outlined in the SIP specification
   [14], is to use an S/MIME message body containing the session
   parameters signed with an acceptable certificate.

For the purposes of this profile, it is acceptable to use any
suitably secure authentication mechanism which establishes the
identity and integrity of the information provided to the client.


11.6.2 Suitable Security Solutions for RTP Sessions with Unicast
Feedback

a) SRTP -- SRTP [3] is the recommended AVT security framework for
RTP sessions. It specifies the general packet formats and cipher

Ott et al.       Internet Draft - Expires April 2010          [Page 44]

                  RTCP with Unicast Feedback

operations that are used, and provides the flexibility to select
different stream ciphers based on preference/requirements. It can
provide confidentiality of the RTP and RTCP packets as well as
protection against integrity compromise and replay attacks. It
provides authentication of the data stream using the shared- key
trust model. Any suitable key-distribution mechanism can be used in
parallel to the SRTP streams.

b) IPSEC -- A more general group security profile which might be
used is the Group Domain of Interpretation [23], 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 using a shared key or
individually through public-key mechanisms. It should be noted that
using IPSec would break the 'transport independent' condition of RTP
and would therefore not be useable for anything other than IP based
communication.

c) TESLA - TESLA [24] 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 lower than other standard
public-key mechanisms and therefore may be more suited to small or
energy-restricted devices.


11.6.3 Secure Key Distribution Mechanisms

a) MIKEY -- MIKEY [29] is the preferred solution for SRTP sessions
   providing a shared group key distribution mechanism and intra-
   session rekeying facilities.  If a partly protected communication
   channel exists, keys may also be conveyed using SDP as per [27].

b) GSAKMP -- GSAKMP is the general solution favored for Multicast
   Secure group key distribution. It is the recommended key
   distribution solution for GDOI sessions.

11.7 Troubleshooting Misconfiguration

As noted above, the security mechanisms in place will not help in
case an authorized source spreads properly authenticated and integer
yet incorrect information about the Feedback Target.  In this case,
the accidentally communicated Feedback Target will receive a RTCP
packets from a potentially large group of receiver, the RTCP rate
fortunately limited by the RTCP timing rules.



Ott et al.       Internet Draft - Expires April 2010          [Page 45]

                  RTCP with Unicast Feedback

Yet, the RTCP packets do not provide much context information and,
if encrypted, do not provide any context making it difficult for the
entity running the (network with) the Feedback Target to debug and
correct this problem, e.g., by tracking down and informing the
origin of the misconfiguration.

One suitable approach may be to provide explicit context information
in RTCP packets that would allow determining the source.  While such
an RTCP packet could be defined in this specification, it would be
of no use when using SRTP/SRTCP and encryption of RTCP reports.
Therefore, and because the extensions in this document may not be
the only case that may face such a problem, it is desirable find a
solution that is applicable to RTP at large.  Such mechanisms are
for further study in the AVT WG.


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 Media Sender(s)
that continue to enable 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 redistribute the traffic either by
simple reflection or through summaries 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 mechanisms, the RTCP traffic may still reach
the group, in the event that an ASM distribution network is used, in
which case there may be some duplication of traffic due to the
reflection channel, but this should be ignored. It is anticipated,
however, that typically the distribution network will not enable the
receiver to multicast RTCP traffic, in which case the data will be
lost, and the RTCP calculations will not include those receivers. It
is RECOMMENDED that any session that may involve non-unicast capable
clients should always use the simple packet reflection mechanism to
ensure that the packets received can be understood by all clients.


13. IANA Considerations

The following contact information shall be used for all
registrations included here:

  Contact:      Joerg Ott
                mailto:jo@acm.org
                tel:+358-9-451-2460

Based on the guidelines suggested in [2], this document proposes 1
new RTCP packet format to be registered with the RTCP Control Packet
type (PT) Registry:




Ott et al.       Internet Draft - Expires April 2010          [Page 46]

                  RTCP with Unicast Feedback

  Name:           RSI
  Long name:      Receiver Summary Information
  Value:          208
  Reference:      This document.

This document defines a substructure for RTCP RSI packets.  A new
sub-registry needs to be set up for the sub-report block type (SRBT)
values for the RSI packet, with the following registrations created
initially:

  Name:           IPv4 Address
  Long name:      IPv4 Feedback Target Address
  Value:          0
  Reference:      This document.

  Name:           IPv6 Address
  Long name:      IPv6 Feedback Target Address
  Value:          1
  Reference:      This document.

  Name:           DNS Name
  Long name:      DNS Name indicating Feedback Target Address
  Value:          2
  Reference:      This document.

  Name:           Loss
  Long name:      Loss distribution
  Value:          4
  Reference:      This document.

  Name:           Jitter
  Long name:      Jitter Distribution
  Value:          5
  Reference:      This document.

  Name:           RTT
  Long name:      Round-trip time distribution
  Value:          6
  Reference:      This document.

  Name:           Cumulative loss
  Long name:      Cumulative loss distribution
  Value:          7
  Reference:      This document.

  Name:           Collisions
  Long name:      SSRC Collision list
  Value:          8
  Reference:      This document.






Ott et al.       Internet Draft - Expires April 2010          [Page 47]

                  RTCP with Unicast Feedback

  Name:           Stats
  Long name:      General statistics
  Value:          10
  Reference:      This document.

  Name:           RTCP BW
  Long name:      RTCP Bandwidth indication
  Value:          11
  Reference:      This document.

  Name:           Group Info
  Long name:      RTCP Group and Average Packet size
  Value:          12
  Reference:      This document.

  The value 3 shall be reserved for a further way of specifying a
  feedback target address.  The value 3 MUST only be allocated for a
  use defined in an IETF Standards Track document.

  Further values may be registered on a first-come first-serve
  basis.  For each new registration, it is mandatory that a
  permanent, stable, and publicly accessible document exists that
  specifies the semantics of the registered parameter as well as the
  syntax and semantics of the associated sub-report block.  The
  general registration procedures of [5] apply.

In the registry for SDP parameters, the attribute names "unicast-
rtcp" need to be registered as follows:

SDP Attribute ("att-field"):

  Attribute Name:     unicast-rtcp
  Long form:          RTCP Unicast feedback address
  Type of name:       att-field
  Type of attribute:  Media level only
  Subject to charset: No
  Purpose:            RFC XXXX
  Reference:          RFC XXXX
  Values:             See this document.


14. Bibliography

14.1 Normative References

[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP -
    A Transport Protocol for Real-time Applications," RFC 3550 (STD
    64), July 2003.

[2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
    Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.




Ott et al.       Internet Draft - Expires April 2010          [Page 48]

                  RTCP with Unicast Feedback

[3] M. Baugher, D. McGrew, D. Oran, R. Blom, E. Carrara, M. Naslund,
    and K. Norrman, "The Secure Real Time Transport Protocol", RFC
    3711, March 2004.

[4] B. Quinn, R. Finlayson, "SDP Source-Filters", RFC 4570, July
    2006.

[5] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session
    Description Protocol", RFC 4566, July 2006.

[6] H. Schulzrinne, S. Casner, "RTP Profile for Audio and Video
    Conferences with Minimal Control", RFC 3551 (STD 65), July 2003.

[7] C. Huitema, "RTCP Attribute in SDP", RFC 3605, October 2003.

[8] D. Meyer, R. Rockell, G. Shepherd, "Source-Specific Protocol
    Independent Multicast in 232/8", RFC 4608, August 2006.

[9] H. Holbrook, B. Cain, B. Haberman, "Using Internet Group
    Management Protocol Version 3 (IGMPv3) and Multicast Listener
    Discovery Protocol Version 2 (MLDv2) for Source-Specific
    Multicast", RFC 4604, August 2006.

[10] S. Casner, "Session Description Protocol (SDP) Bandwidth
    Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
    July 2003.

[11] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
    3629, November 2003.

[12] J. Lennox, J. Ott, and T, Schierl, "Source-specific Media
    Attributes in the Session Description Protocol (SDP)," RFC 5576,
    June 2009.

[13] Bradner, S, "Key words for use in RFCs to Indicate Requirement
     Levels," RFC 2119, March 1997.

14.2 Informative References

[14] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
    Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session
    Initiation Protocol", RFC 3261, June 2002.

[15] J. Ott, S. Wenger, N. Sato, C. Burmeister, and J. Rey, "
    Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)", RFC
    4585, July 2006.

[16] Pusateri, T, "Distance Vector Multicast Routing Protocol",
    Internet Draft draft-ietf-idmr-dvmrp-v3-11.txt, Work in
    Progress, October 2003.

[17] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
    Independent Multicast - Sparse Mode (PIM-SM): Protocol
    Specification (Revised)", RFC 4601, August 2006.

Ott et al.       Internet Draft - Expires April 2010          [Page 49]

                  RTCP with Unicast Feedback


[18] Adams, A, Nicholas, J, Siadak, W, "Protocol Independent
    Multicast- Dense Mode (PIM-DM)", RFC 3973, January 2005.

[19] Bates, T, Chandra, R, Katz, D, Rekhter, Y, "Multiprotocol
    Extension of BGP-4", RFC 4760, January 2007.

[20] D. Meyer, B. Fenner, "Multicast Source Discovery Protocol
    (MSDP)", Experimental RFC 3618, October 2003.

[21] Session Directory Rendez-vous (SDR), developed at University
    College London by Mark Handley and the Multimedia Research
    Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/.

[22] M. Handley, C. Perkins, E. Whelan, "Session Announcement
    Protocol (SAP)", RFC 2974, October 2000.

[23] M. Baugher, T. Hardjono, H. Harney, and B. Weis, "The Group
    Domain of Interpretation", RFC 3547, July 2003.

[24] A. Perrig, D. Song, R. Canetti, D. Tygar, B. Briscoe, "TESLA:
    Multicast Source Authentication Transform Introduction", RFC
    4082, June 2005.

[25] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
    Protocol (RTSP)", RFC 2326, April 1998.

[26] T. Friedman, R. Caceres, and A. Clark (eds), "RTCP Reporting
    Extensions", RFC 3611, November 2003.

[27] F. Andreasen, M. Baugher, and D. Wing, "Session Description
    Protocol Security Descriptions for Media Streams", RFC 4568,
    July 2006.

[28] J. Ott and E. Cararra, "Extended Secure RTP Profile for RTCP-
    based Feedback (RTP/SAVPF)", RFC 5124, February 2008.

[29] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. Norrman,
    "MIKEY: Multimedia Internet Keying", RFC 3830, August 2004.
















Ott et al.       Internet Draft - Expires April 2010          [Page 50]

                  RTCP with Unicast Feedback

15. Appendix A: Examples for Sender Side Configurations

This appendix describes a few common setups focusing on the
contribution side, i.e., the communications between the Media
Sender(s) and the Distribution Source.  In all cases, the same
session description may be used for the distribution side as defined
in the main part of this document.  This is because this
specification defines only the media stream setup between the
Distribution Source and the receivers.

15.1 One Media Sender identical to the Distribution Source

  In the simplest case, the Distribution Source is identical to the
  Media Sender as depicted in figure 2.  Obviously, no further
  configuration for the interaction between the Media Sender and the
  Distribution Source is necessary.

                          Source-specific
         +--------+          Multicast
         |        |     +----------------> R(1)
         |M   D S |     |                    |
         |E   I O |  +--+                    |
         |D   S U |  |  |                    |
         |I   T R |  |  +-----------> R(2)   |
         |A   R C |->+-----  :          |    |
         |  = I E |  |  +------> R(n-1) |    |
         |S   B   |  |  |          |    |    |
         |E   U   |  +--+--> R(n)  |    |    |
         |N   T   |          |     |    |    |
         |D   I   |<---------+     |    |    |
         |E   O   |<---------------+    |    |
         |R   N   |<--------------------+    |
         |        |<-------------------------+
         +--------+            Unicast


  Figure 2: Media Source == Distribution Source

15.2 One Media Sender

  In a slightly more complex scenario, the Media Sender and the
  Distribution Source are separate entities running on the same or
  different machines.  Hence, the Media Sender needs to deliver the
  media stream(s) to the Distribution Source.  This can be done
  either via unicasting the RTP stream, via ASM multicast, or via
  SSM.  In this case, the Distribution Source is responsible for
  forwarding the RTP packets comprising the media stream and the
  RTCP sender reports towards the receivers and conveying feedback
  from the receivers, as well as from itself, to the Media Sender.

  This scenario is depicted in figure 3.  The communication setup
  between the Media Sender and the Distribution Source may be
  statically configured or SDP may be used in conjunction with some
  signaling protocol to convey the session parameters.  Note that it

Ott et al.       Internet Draft - Expires April 2010          [Page 51]

                  RTCP with Unicast Feedback

  is a local configuration matter of the Distribution Source how to
  associate a session between the Media Sender and itself (the
  Contribution session) with the corresponding session between
  itself and the receivers (the Distribution session).

                                   Source-specific
                     +-----+          Multicast
                     |     |     +----------------> R(1)
                     | D S |     |                    |
                     | I O |  +--+                    |
                     | S U |  |  |                    |
     +--------+      | T R |  |  +-----------> R(2)   |
     | Media  |<---->| R C |->+-----  :          |    |
     | Sender |      | I E |  |  +------> R(n-1) |    |
     +--------+      | B   |  |  |          |    |    |
                     | U   |  +--+--> R(n)  |    |    |
                     | T   |          |     |    |    |
                     | I   |<---------+     |    |    |
                     | O   |<---------------+    |    |
                     | N   |<--------------------+    |
                     |     |<-------------------------+
                     +-----+            Unicast

        Contribution               Distribution
          Session                    Session
      (unicast or ASM)                 (SSM)

   Figure 3: One Media Sender Separate from Distribution Source


15.3 Three Media Senders, Unicast Contribution

Similar considerations apply if three Media Senders transmit to an
SSM multicast group via the Distribution Source and individually
send their media stream RTP packets via unicast to the Distribution
Source.

In this case, the responsibilities of the Distribution Source are a
superset to the previous case: the Distribution Source also needs to
relay media traffic from each Media Sender to the receivers and to
forward (aggregated) feedback from the receivers to the Media
Senders.  In addition, the Distribution Source relays RTCP packets
(SRs) from each Media Sender to the other two.

The configuration of the Media Senders is identical to the previous
case.  It is just the Distribution Source that must be aware that
there are multiple senders and then perform the necessary relaying.
The transport address for the RTP session at the Distribution Source
may be identical for all Media Senders (which may make correlation
easier) or different addresses may be used.

This setup is depicted in figure 4.



Ott et al.       Internet Draft - Expires April 2010          [Page 52]

                  RTCP with Unicast Feedback

                                Source-specific
                  +-----+          Multicast
  +--------+      |     |     +----------------> R(1)
  | Media  |<---->| D S |     |                    |
  |Sender 1|      | I O |  +--+                    |
  +--------+      | S U |  |  |                    |
                  | T R |  |  +-----------> R(2)   |
  +--------+      | R C |->+-----  :          |    |
  | Media  |<---->| I E |  |  +------> R(n-1) |    |
  |Sender 2|      | B   |  |  |          |    |    |
  +--------+      | U   |  +--+--> R(n)  |    |    |
                  | T   |          |     |    |    |
  +--------+      | I   |<---------+     |    |    |
  | Media  |<---->| O   |<---------------+    |    |
  |Sender 3|      | N   |<--------------------+    |
  +--------+      |     |<-------------------------+
                  +-----+            Unicast

        Contribution               Distribution
          Session                    Session
         (unicast)                    (SSM)

  Figure 4: Three Media Senders, unicast contribution


15.4 Three Media Senders, ASM Contribution Group

  In this final example, the individual unicast contribution
  sessions between the Media Senders and the Distribution Source are
  replaced by a single ASM contribution group (i.e., a single common
  RTP session).  Consequently, all Media Senders receive each
  other's traffic by means of IP-layer multicast and the
  Distribution Source no longer needs to perform explicit forwarding
  between the Media Senders.  Of course, the Distribution Source
  still forwards feedback information received from the receivers
  (optionally as summaries) to the ASM contribution group.

  The ASM contribution group may be statically configured or the
  necessary information can be communicated using a standard SDP
  session description for a multicast session.  Again, it is up to
  the implementation of the Distribution Source to properly
  associate the ASM contribution session and the SSM distribution
  sessions.

  Figure 5 shows this scenario.










Ott et al.       Internet Draft - Expires April 2010          [Page 53]

                  RTCP with Unicast Feedback


                 _                   Source-specific
                / \    +-----+          Multicast
  +--------+   |   |   |     |     +----------------> R(1)
  | Media  |<->| A |   | D S |     |                    |
  |Sender 1|   | S |   | I O |  +--+                    |
  +--------+   | M |   | S U |  |  |                    |
               |   |   | T R |  |  +-----------> R(2)   |
  +--------+   | G |   | R C |->+-----  :          |    |
  | Media  |<->| r |<->| I E |  |  +------> R(n-1) |    |
  |Sender 2|   | o |   | B   |  |  |          |    |    |
  +--------+   | u |   | U   |  +--+--> R(n)  |    |    |
               | p |   | T   |          |     |    |    |
  +--------+   |   |   | I   |<---------+     |    |    |
  | Media  |<->|   |   | O   |<---------------+    |    |
  |Sender 3|    \_/    | N   |<--------------------+    |
  +--------+           |     |<-------------------------+
                       +-----+            Unicast

           Contribution            Distribution
             Session                  Session
              (ASM)                   (SSM)


      Figure 5: Three Media Sender in ASM Group






























Ott et al.       Internet Draft - Expires April 2010          [Page 54]

                  RTCP with Unicast Feedback

16. Appendix B: Distribution Report processing at the receiver

16.1 Algorithm

Example processing of Loss Distribution Values
X values represent the loss percentage.
Y values represent the number of receivers.

Number of x values is the NDB value
xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV)
First data point = MnDV,first ydata
then
For each ydata => xdata += (MnDV + (xrange / NDB))

16.2 Pseudo-code

Packet Variables -> factor,NDB,MnDVL,MaDV
Code variables -> xrange, ydata[NDB],x,y

xrange = MaDV - MnDV
x = MnDV;

for(i=0;i<NDB;i++) {
     y = (ydata[i] * factor);
     /*OUTPUT x and y values*/
     x += (xrange / NDB);
}


16.3 Application Uses and Scenarios

Providing a distribution function in a feedback message has a number
of uses for different types of applications. Although this section
enumerates potential uses for the distribution scheme, it is
anticipated that future applications might benefit from it in ways
not addressed in this document. Due to the flexible nature of the
summarization 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

Ott et al.       Internet Draft - Expires April 2010          [Page 55]

                  RTCP with Unicast Feedback

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.


16.4 Distribution Sub-report creation at the source

The following example demonstrates two different ways to convey loss
data using the generic format of a Loss sub-report block (section
7.1.4). The same techniques could also be applied to representing
other distribution types.

1) The first method attempts to represent the data in as few bytes
as possible.


Ott et al.       Internet Draft - Expires April 2010          [Page 56]

                  RTCP with Unicast Feedback

2) The second method conveys all values without providing any
savings in bandwidth.


Data Set
X values indicate loss percentage reported, Y values indicate the
number of receivers reporting that loss percentage

     X -  0  |  1  | 2 |  3   |   4  |  5   |  6   |  7   |  8  |  9
     Y - 1000| 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 | 103

     X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19
     Y - 74 | 21 | 30 | 65 | 60 | 80 |  6 |  7 |  4 |  5

     X - 20 | 21 | 22  |  23  |  24  | 25  | 26  | 27  | 28  | 29
     Y - 2  | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 | 205


     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
represents loss data.


Example: 1st Method

Description
The minimal method of conveying data, i.e., small amount of
bytes used to convey the values.

Algorithm
Attempt to fit the data set into a small sub-report size, selected
length 8 Octets

Can we split the range (0 - 39) into 16 4-bit values?
The largest bucket value would in this case the bucket for X values 5
- 7.5, the sum of which is 5970. An MF value of 9 will generate a
multiplicative factor of 2^9, or 512 which multiplied by the max
bucket value produces a maximum real value of 7680.


The packet fields will contain the values:
Header distribution Block
Distribution Type:                       1
Number of Data Buckets:                  16
Multiplicative Factor:                   9
Packet Length field:                     5 (5 * 4 => 20 Bytes)
Minimum Data Value:                      0

Ott et al.       Internet Draft - Expires April 2010          [Page 57]

                  RTCP with Unicast Feedback

Maximum Data Value:                      39
Data Bucket values:                      (each value is 16-bits)

Results, 4-bit buckets:


     X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10
    (Y -   1803  |   4403  |   5970  |   853 )  ACTUAL
     Y -    4    |    9    |    12   |    2

     X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20
    (Y -     110   |    140    |    89.5   |    12.5)  ACTUAL
     Y -      0    |     0     |     0     |      0

     X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 30
    (Y -    447    |    3897   |    609.5  |   506.5)  ACTUAL
     Y -     1     |     8     |      1    |     1

     X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40
    (Y -   388.5   |    221.5  |   159.5   |    85.5)  ACTUAL
     Y -    1      |      0    |     0     |     0





Example: 2nd Method

Description
This demonstrates the most accurate method for representing the data
set. This method doesn't attempt to optimise any values.

Algorithm
Identify the highest value and select buckets large enough to convey
the exact values, i.e. no multiplicative factor.

The highest value is 3120. This requires 12 bits (closest 2 bit
boundary) to represent, therefore it will use 60 bytes to represent
the entire distribution. This is within the max packet size,
therefore all data will fit within one sub-report block. The
multiplicative value will be 1.

The packet fields will contain the values:

Header Distribution Block
Distribution Type:                        1
Number of Data Buckets:                   40
Multiplicative Factor:                    0
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.

Ott et al.       Internet Draft - Expires April 2010          [Page 58]

                  RTCP with Unicast Feedback


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.


18. ACKNOWLEDGEMENTS

The authors would like to thank Magnus Westerlund, Dave Oran, Tom
Taylor and Colin Perkins for detailed reviews and valuable comments.


19. AUTHORS' ADDRESSES

Joerg Ott
Helsinki University of Technology
Department of Communications and Networking
PO Box 3000
FIN-02015 TKK
jo@acm.org

Julian Chesterfield
University of Cambridge
Computer Laboratory,
15 JJ Thompson Avenue
Cambridge
CB3 0FD
UK
Julian.chesterfield@cl.cam.ac.uk

Eve Schooler
Intel Research / CTL
MS RNB6-61
2200 Mission College Blvd.
Santa Clara, CA, USA 95054-1537
eve_(underscore) schooler (at) acm.org














Ott et al.       Internet Draft - Expires April 2010          [Page 59]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/