Skip to main content

3.4. Definitions and Algorithm Overview

The following pieces of state information need to be maintained per receiver (largely taken from [1]). Note that all variables (except in item h) below) are calculated independently at each receiver. Therefore, their local values may differ at any given point in time.

a) Let senders be the number of active senders in the RTP session.

b) Let members be the current estimate of the number of receivers in the RTP session.

c) Let tn and tp be the time for the next (last) scheduled RTCP RR transmission calculated prior to timer reconsideration.

d) Let Tmin be the minimal interval between RTCP packets as per [1]. Unlike in [1], the initial Tmin is set to 1 second to allow for some group size sampling before sending the first RTCP packet. After the first RTCP packet is sent, Tmin is set to 0.

e) Let T_rr be the interval after which, having just sent a regularly scheduled RTCP packet, a receiver would schedule the transmission of its next Regular RTCP packet. This value is obtained following the rules of [1] but with Tmin as defined in this document: T_rr = T (the "calculated interval" as defined in [1]) with tn = tp + T. T_rr always refers to the last value of T that has been computed (because of reconsideration or to determine tn). T_rr is also referred to as Regular RTCP interval in this document.

f) Let t0 be the time at which an event that is to be reported is detected by a receiver.

g) Let T_dither_max be the maximum interval for which an RTCP feedback packet MAY be additionally delayed to prevent implosions in multiparty sessions; the value for T_dither_max is dynamically calculated based upon T_rr (or may be derived by means of another mechanism common across all RTP receivers to be specified in the future). For point-to-point sessions (i.e., sessions with exactly two members with no change in the group size expected, e.g., unicast streaming sessions), T_dither_max is set to 0.

h) Let T_max_fb_delay be the upper bound within which feedback to an event needs to be reported back to the sender to be useful at all. This value is application specific, and no values are defined in this document.

i) Let te be the time for which a feedback packet is scheduled.

j) Let T_fd be the actual (randomized) delay for the transmission of FB message in response to an event at time t0.

k) Let allow_early be a Boolean variable that indicates whether the receiver currently may transmit FB messages prior to its next regularly scheduled RTCP interval tn. This variable is used to throttle the feedback sent by a single receiver. allow_early is set to FALSE after Early feedback transmission and is set to TRUE as soon as the next Regular RTCP transmission takes place.

l) Let avg_rtcp_size be the moving average on the RTCP packet size as defined in [1].

m) Let T_rr_interval be an OPTIONAL minimal interval to be used between Regular RTCP packets. If T_rr_interval == 0, then this variable does not have any impact on the overall operation of the RTCP feedback algorithm. If T_rr_interval != 0, then the next Regular RTCP packet will not be scheduled T_rr after the last Regular RTCP transmission (i.e., at tp+T_rr). Instead, the next Regular RTCP packet will be delayed until at least T_rr_interval after the last Regular RTCP transmission, i.e., it will be scheduled at or later than tp+T_rr_interval. Note that T_rr_interval does not affect the calculation of T_rr and tp; instead, Regular RTCP packets scheduled for transmission before tp+T_rr_interval will be suppressed if, for example, they do not contain any FB messages. The T_rr_interval does not affect transmission scheduling of Early RTCP packets.

Note: Providing T_rr_interval as an independent variable is meant to minimize Regular RTCP feedback (and thus bandwidth consumption) as needed by the application while additionally allowing the use of more frequent Early RTCP packets to provide timely feedback. This goal could not be achieved by reducing the overall RTCP bandwidth as RTCP bandwidth reduction would also impact the frequency of Early feedback.

n) Let t_rr_last be the point in time at which the last Regular RTCP packet has been scheduled and sent, i.e., has not been suppressed due to T_rr_interval.

o) Let T_retention be the time window for which past FB messages are stored by an AVPF entity. This is to ensure that feedback suppression also works for entities that have received FB messages from other entities prior to noticing the feedback event itself. T_retention MUST be set to at least 2 seconds.

p) Let M*Td be the timeout value for a receiver to be considered inactive (as defined in [1]).

The feedback situation for an event to report at a receiver is depicted in Figure 2 below. At time t0, such an event (e.g., a packet loss) is detected at the receiver. The receiver decides -- based upon current bandwidth, group size, and other application-specific parameters -- that an FB message needs to be sent back to the sender.

To avoid an implosion of feedback packets in multiparty sessions, the receiver MUST delay the transmission of the RTCP feedback packet by a random amount of time T_fd (with the random number evenly distributed in the interval [0, T_dither_max]). Transmission of the compound RTCP packet MUST then be scheduled for te = t0 + T_fd.

The T_dither_max parameter is derived from the Regular RTCP interval, T_rr, which, in turn, is based upon the group size. A future document may also specify other calculations for T_dither_max (e.g., based upon RTT) if it can be assured that all RTP receivers will use the same mechanism for calculating T_dither_max.

For a certain application scenario, a receiver may determine an upper bound for the acceptable local delay of FB messages: T_max_fb_delay. If an a priori estimation or the actual calculation of T_dither_max indicates that this upper bound MAY be violated (e.g., because T_dither_max > T_max_fb_delay), the receiver MAY decide not to send any feedback at all because the achievable gain is considered insufficient.

If an Early RTCP packet is scheduled, the time slot for the next Regular RTCP packet MUST be updated accordingly to have a new tn (tn=tp+2*T_rr) and a new tp (tp=tp+T_rr) afterwards. This is to ensure that the short-term average RTCP bandwidth used with Early feedback does not exceed the bandwidth used without Early feedback.

            event to
            report
            detected
               |
               |  RTCP feedback range
               |   (T_max_fb_delay)
               vXXXXXXXXXXXXXXXXXXXXXXXXXXX     ) )
|---+--------+-------------+-----+------------| |--------+--->
    |        |             |     |            ( (        |
    |       t0            te                             |
    tp                                                   tn
              \_______  ________/
                      \/
                T_dither_max

     Figure 2: Event report and parameters for Early RTCP scheduling
Last updated on