RTP is designed to allow an application to scale automatically over
session sizes ranging from a few participants to thousands. For
example, in an audio conference the data traffic is inherently self-
limiting because only one or two people will speak at a time, so with
multicast distribution the data rate on any given link remains
relatively constant independent of the number of participants.
However, the control traffic is not self-limiting. If the reception
reports from each participant were sent at a constant rate, the
control traffic would grow linearly with the number of participants.
Therefore, the rate must be scaled down.
For each session, it is assumed that the data traffic is subject to
an aggregate limit called the "session bandwidth" to be divided among
the participants. This bandwidth might be reserved and the limit
enforced by the network, or it might just be a reasonable share. The
session bandwidth may be chosen based or some cost or a priori
knowledge of the available network bandwidth for the session. It is
somewhat independent of the media encoding, but the encoding choice
may be limited by the session bandwidth. The session bandwidth
parameter is expected to be supplied by a session management
application when it invokes a media application, but media
applications may also set a default based on the single-sender data
bandwidth for the encoding selected for the session. The application
may also enforce bandwidth limits based on multicast scope rules or
other criteria.
Bandwidth calculations for control and data traffic include lower-
layer transport and network protocols (e.g., UDP and IP) since that
is what the resource reservation system would need to know. The
application can also be expected to know which of these protocols are
in use. Link level headers are not included in the calculation since
the packet will be encapsulated with different link level headers as
it travels.
The control traffic should be limited to a small and known fraction
of the session bandwidth: small so that the primary function of the
transport protocol to carry data is not impaired; known so that the
control traffic can be included in the bandwidth specification given
to a resource reservation protocol, and so that each participant can
independently calculate its share. It is suggested that the fraction
of the session bandwidth allocated to RTCP be fixed at 5%. While the
value of this and other constants in the interval calculation is not
critical, all participants in the session must use the same values so
the same interval will be calculated. Therefore, these constants
should be fixed for a particular profile.
The algorithm described in Appendix A.7 was designed to meet the
goals outlined above. It calculates the interval between sending
compound RTCP packets to divide the allowed control traffic bandwidth
among the participants. This allows an application to provide fast
response for small sessions where, for example, identification of all
participants is important, yet automatically adapt to large sessions.
The algorithm incorporates the following characteristics:
Senders are collectively allocated at least 1/4 of the control
traffic bandwidth so that in sessions with a large number of
receivers but a small number of senders, newly joining
participants will more quickly receive the CNAME for the
sending sites.
The calculated interval between RTCP packets is required to be
greater than a minimum of 5 seconds to avoid having bursts of
RTCP packets exceed the allowed bandwidth when the number of
participants is small and the traffic isn't smoothed according
to the law of large numbers.
The interval between RTCP packets is varied randomly over the
range [0.5,1.5] times the calculated interval to avoid
unintended synchronization of all participants [10]. The first
RTCP packet sent after joining a session is also delayed by a
random variation of half the minimum RTCP interval in case the
application is started at multiple sites simultaneously, for
example as initiated by a session announcement.
A dynamic estimate of the average compound RTCP packet size is
calculated, including all those received and sent, to
automatically adapt to changes in the amount of control
information carried.
This algorithm may be used for sessions in which all participants are
allowed to send. In that case, the session bandwidth parameter is the
product of the individual sender's bandwidth times the number of
participants, and the RTCP bandwidth is 5% of that.
