Skip to main content

3.5. AVPF RTCP Scheduling Algorithm

Let S0 be an active sender (out of S senders) and let N be the number of receivers with R being one of these receivers.

Assume that R has verified that using feedback mechanisms is reasonable at the current constellation (which is highly application specific and hence not specified in this document).

Assume further that T_rr_interval is 0, if no minimal interval between Regular RTCP packets is to be enforced, or T_rr_interval is set to some meaningful value, as given by the application. This value then denotes the minimal interval between Regular RTCP packets.

With this, a receiver R MUST use the following rules for transmitting one or more FB messages as minimal or full compound RTCP packet.

3.5.1. Initialization

Initially, R MUST set allow_early = TRUE and t_rr_last = NaN (Not-a-Number, i.e., some invalid value that can be distinguished from a valid time).

Furthermore, the initialization of the RTCP variables as per [1] applies except for the initial value for Tmin. For a point-to-point session, the initial Tmin is set to 0. For a multiparty session, Tmin is initialized to 1.0 seconds.

3.5.2. Early Feedback Transmission

Assume that R had scheduled the last Regular RTCP RR packet for transmission at tp (and sent or suppressed this packet at tp) and has scheduled the next transmission (including possible reconsideration as per [1]) for tn = tp + T_rr. Assume also that the last Regular RTCP packet transmission has occurred at t_rr_last.

The Early Feedback algorithm then comprises the following steps:

  1. At time t0, R detects the need to transmit one or more FB messages, e.g., because media "units" need to be ACKed or NACKed, and finds that providing the feedback information is potentially useful for the sender.

  2. R first checks whether there is already a compound RTCP packet containing one or more FB messages scheduled for transmission (either as Early or as Regular RTCP packet).

    2a) If so, the new FB message MUST be included in the scheduled packet; the scheduling of the waiting compound RTCP packet MUST remain unchanged. When doing so, the available feedback information SHOULD be merged to produce as few FB messages as possible. This completes the course of immediate actions to be taken.

    2b) If no compound RTCP packet is already scheduled for transmission, a new (minimal or full) compound RTCP packet MUST be created and the minimal interval for T_dither_max MUST be chosen as follows:

    i) If the session is a point-to-point session, then

    T_dither_max = 0.

    ii) If the session is a multiparty session, then

    T_dither_max = l * T_rr

    with l=0.5.

    The value for T_dither_max MAY be calculated differently (e.g., based upon RTT), which MUST then be specified in a future document. Such a future specification MUST ensure that all RTP receivers use the same mechanism to calculate T_dither_max.

    The values given above for T_dither_max are minimal values. Application-specific feedback considerations may make it worthwhile to increase T_dither_max beyond this value. This is up to the discretion of the implementer.

  3. Then, R MUST check whether its next Regular RTCP packet would be within the time bounds for the Early RTCP packet triggered at t0, i.e., if t0 + T_dither_max > tn.

    3a) If so, an Early RTCP packet MUST NOT be scheduled; instead, the FB message(s) MUST be stored to be included in the Regular RTCP packet scheduled for tn. This completes the course of immediate actions to be taken.

    3b) Otherwise, the following steps are carried out.

  4. R MUST check whether it is allowed to transmit an Early RTCP packet, i.e., allow_early == TRUE, or not.

    4a) If allow_early == FALSE, then R MUST check the time for the next scheduled Regular RTCP packet:

    1. If tn - t0 < T_max_fb_delay, then the feedback could still be useful for the sender, despite the late reporting. Hence, R MAY create an RTCP FB message to be included in the Regular RTCP packet for transmission at tn.

    2. Otherwise, R MUST discard the RTCP FB message.

    This completes the immediate course of actions to be taken.

    4b) If allow_early == TRUE, then R MUST schedule an Early RTCP packet for te = t0 + RND * T_dither_max with RND being a pseudo random function evenly distributed between 0 and 1.

  5. R MUST detect overlaps in FB messages received from other members of the RTP session and the FB messages R wants to send. Therefore, while a member of the RTP session, R MUST continuously monitor the arrival of (minimal) compound RTCP packets and store each FB message contained in these RTCP packets for at least T_retention. When scheduling the transmission of its own FB message following steps 1 through 4 above, R MUST check each of the stored and newly received FB messages from the RTCP packets received during the interval [t0 - T_retention ; te] and act as follows:

    5a) If R understands the received FB message's semantics and the message contents is a superset of the feedback R wanted to send, then R MUST discard its own FB message and MUST re-schedule the next Regular RTCP packet transmission for tn (as calculated before).

    5b) If R understands the received FB message's semantics and the message contents is not a superset of the feedback R wanted to send, then R SHOULD transmit its own FB message as scheduled. If there is an overlap between the feedback information to send and the feedback information received, the amount of feedback transmitted is up to R: R MAY leave its feedback information to be sent unchanged, R MAY as well eliminate any redundancy between its own feedback and the feedback received so far from other session members.

    5c) If R does not understand the received FB message's semantics, R MAY keep its own FB message scheduled as an Early RTCP packet, or R MAY re-schedule the next Regular RTCP packet transmission for tn (as calculated before) and MAY append the FB message to the now regularly scheduled RTCP message.

    Note: With 5c), receiving unknown FB messages may not lead to feedback suppression at a particular receiver. As a consequence, a given event may cause M different types of FB messages (which are all appropriate but not mutually understood) to be scheduled, so that a "large" receiver group may effectively be partitioned into at most M groups. Among members of each of these M groups, feedback suppression will occur following 5a and 5b but no suppression will happen across groups. As a result, O(M) RTCP FB messages may be received by the sender. Hence, there is a chance for a very limited feedback implosion. However, as sender(s) and all receivers make up the same application using the same (set of) codecs in the same RTP session, only little divergence in semantics for FB messages can safely be assumed and, therefore, M is assumed to be small in the general case.

    Given further that the O(M) FB messages are randomly distributed over a time interval of T_dither_max, we find that the resulting limited number of extra compound RTCP packets (a) is assumed not to overwhelm the sender and (b) should be conveyed as all contain complementary pieces of information.

  6. If R's FB message(s) was not suppressed by other receiver FB messages as per 5, when te is reached, R MUST transmit the (minimal) compound RTCP packet containing its FB message(s). R then MUST set allow_early = FALSE, MUST recalculate tn = tp + 2*T_rr, and MUST set tp to the previous tn. As soon as the newly calculated tn is reached, regardless whether R sends its next Regular RTCP packet or suppresses it because of T_rr_interval, it MUST set allow_early = TRUE again.

3.5.3. Regular RTCP Transmission

Full compound RTCP packets MUST be sent in regular intervals. These packets MAY also contain one or more FB messages. Transmission of Regular RTCP packets is scheduled as follows:

If T_rr_interval == 0, then the transmission MUST follow the rules as specified in Sections 3.2 and 3.4 of this document and MUST adhere to the adjustments of tn specified in Section 3.5.2 (i.e., skip one regular transmission if an Early RTCP packet transmission has occurred). Timer reconsideration takes place when tn is reached as per [1]. The Regular RTCP packet is transmitted after timer reconsideration. Whenever a Regular RTCP packet is sent or suppressed, allow_early MUST be set to TRUE and tp, tn MUST be updated as per [1]. After the first transmission of a Regular RTCP packet, Tmin MUST be set to 0.

If T_rr_interval != 0, then the calculation for the transmission times MUST follow the rules as specified in Sections 3.2 and 3.4 of this document and MUST adhere to the adjustments of tn specified in Section 3.5.2 (i.e., skip one regular transmission if an Early RTCP transmission has occurred). Timer reconsideration takes place when tn is reached as per [1]. After timer reconsideration, the following actions are taken:

  1. If no Regular RTCP packet has been sent before (i.e., if t_rr_last == NaN), then a Regular RTCP packet MUST be scheduled. Stored FB messages MAY be included in the Regular RTCP packet. After the scheduled packet has been sent, t_rr_last MUST be set to tn. Tmin MUST be set to 0.

  2. Otherwise, a temporary value T_rr_current_interval is calculated as follows:

    T_rr_current_interval = RND*T_rr_interval

    with RND being a pseudo random function evenly distributed between 0.5 and 1.5. This dithered value is used to determine one of the following alternatives:

    2a) If t_rr_last + T_rr_current_interval <= tn, then a Regular RTCP packet MUST be scheduled. Stored RTCP FB messages MAY be included in the Regular RTCP packet. After the scheduled packet has been sent, t_rr_last MUST be set to tn.

    2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB messages have been stored and are awaiting transmission, an RTCP packet MUST be scheduled for transmission at tn. This RTCP packet MAY be a minimal or a Regular RTCP packet (at the discretion of the implementer), and the compound RTCP packet MUST include the stored RTCP FB message(s). t_rr_last MUST remain unchanged.

    2c) Otherwise (if t_rr_last + T_rr_current_interval > tn but no stored RTCP FB messages are awaiting transmission), the compound RTCP packet MUST be suppressed (i.e., it MUST NOT be scheduled). t_rr_last MUST remain unchanged.

In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST be set to TRUE (possibly after sending the Regular RTCP packet) and tp and tn MUST be updated following the rules of [1] except for the five second minimum.

3.5.4. Other Considerations

If T_rr_interval != 0, then the timeout calculation for RTP/AVPF entities (Section 6.3.5 of [1]) MUST be modified to use T_rr_interval instead of Tmin for computing Td and thus M*Td for timing out RTP entities.

Whenever a compound RTCP packet is sent or received -- minimal or full compound, Early or Regular -- the avg_rtcp_size variable MUST be updated accordingly (see [1]) and subsequent computations of tn MUST use the new avg_rtcp_size.