]> Ericsson

ingemar.s.johansson@ericsson.com

Ericsson

magnus.westerlund@ericsson.com

Ericsson

mirja.kuehlewind@ericsson.com

WIT CCWG This memo describes Self-Clocked Rate Adaptation for Multimedia version 2 (SCReAMv2), an update to SCReAM congestion control for media streams such as RTP . SCReAMv2 includes several algorithm simplifications and adds support for L4S. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR goggles. This specification obsoletes RFC 8298. About This Document Status information for this document may be found at . Discussion of this document takes place on the Congestion Control Working Group (ccwg) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This memo describes Self-Clocked Rate Adaptation for Multimedia version 2 (SCReAMv2). This specification replaces the previous experimental version of SCReAM with SCReAMv2. There are many and fairly significant changes to the original SCReAM algorithm as described in . Both SCReAM and SCReAMv2 estimates the forward queue delay in the same way as Low Extra Delay Background Transport (LEDBAT) . However, while SCReAM is based on the self-clocking principle of TCP, SCReAMv2 is not entirely self-clocked as it augments self-clocking with pacing and a minimum send rate. Further, SCReAMv2 can take advantage of Explicit Congestion Notification (ECN) and Low Latency Low Loss and Scalable throughput (L4S) in cases where ECN or L4S is supported by the network and the hosts. However, ECN or L4S is not required for the basic congestion control functionality in SCReAMv2.

Updates Compared to SCReAM (version 1) The algorithm in this memo differs considerably compared to the previous version of SCReAM in . The main differences are:

• L4S support added. The L4S algorithm has many similarities with the DCTCP and Prague congestion control but has a few extra modifications to make it work well with periodic sources such as video.
• The delay-based congestion control is changed to implement a pseudo-L4S approach, this simplifies the delay-based congestion control.
• The fast increase mode is removed. The reference window additive increase is replaced with an adaptive multiplicative increase to enhance convergence speed.
• The algorithm is more rate based than self-clocked:
  • The calculated congestion window is mainly used to calculate proper media bitrates. Bytes in flight is however allowed to exceed the reference window. Therefore, the term reference window is used instead of congestion window, as the reference window does not set an absolute limit on the bytes in flight.
    • The self-clocking now acts more like an emergency break as bytes in flight can exceed the reference window only to a certain degree. The rationale is to be able to transmit large video frames and avoid that they are unnecessarily queued up on the sender side, but still prevent a large network queue.
• The media bitrate calculation is dramatically changed and simplified. In practice it is manifested with a relatively simple relation between the reference window and RTT.
• Additional compensation is added to make SCReAMv2 handle cases such as large changing frame sizes.

Requirements on the Media and Feedback Protocol SCReAM was originally designed to be used with RTP + RTCP where was used as recommended feedback. RTP offers unique packet indication with the sequence number and offers timestamps of received packets and the status of the ECN bits. SCReAM is however not limited to RTP as long as some requirements are fulfilled:

• Media data is split in data units that when encapsulated in IP packets fit in the network MTU.
• Each data unit can be uniquely identified.
• Data units can be queued up in a packet queue before transmission.
• Feedback can indicate reception time for each data units, or a group of data units.
• Feedback can indicate packets that are ECN-CE marked. Unique ECN bits indication for each packet is not necessary. An ECN-CE counter similar to what is defined in is sufficient.

Comparison with LEDBAT and TFWC in TCP The core SCReAM algorithm, which is still similar in SCReAMv2, has similarities to the concepts of self-clocking used in TCP-friendly window-based congestion control and follows the packet conservation principle. The packet conservation principle is described as a key factor behind the protection of networks from congestion . The reference window decrease is determined in a way similar to LEDBAT . However, the window increase is not based on delay estimates but uses both a linear increase and multiplicative increase function depending on the time since the last congestion event and introduces use of inflection points in the reference window increase calculation to achieve reduced delay jitter. Further, unlike LEDBAT which is a scavenger congestion control mostly designed for low priority background traffic, SCReAM adjusts the qdelay target to compete with other loss-based congestion-controlled flows. SCReAMv2 adds a new reference window validation technique, as the reference window is used as a basis for the target bitrate calculation. For that reason, various actions are taken to avoid that the reference window grows too much beyond the bytes in flight. Additional contraints are applied when in congested state and when the maximum target bitrate is reached. The SCReAM/SCReAMv2 congestion control method uses techniques similar to LEDBAT to measure the qdelay. As is the case with LEDBAT, it is not necessary to use synchronized clocks in the sender and receiver in order to compute the qdelay. However, it is necessary that they use the same clock frequency, or that the clock frequency at the receiver can be inferred reliably by the sender. Failure to meet this requirement leads to malfunction in the SCReAM/SCReAMv2 congestion control algorithm due to incorrect estimation of the network queue delay. Use of as feedback ensures that the same time base is used in sender and receiver.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Overview of SCReAMv2 Algorithm SCReAMv2 consists of three main parts: network congestion control, sender transmission control, and media rate control. All of these parts reside at the sender side while the receiver is assumed to provide acknowledgements of received data units and indication of ECN-CE marking, either as an accumulated bytes counter, or per individual data unit. The sender implements media rate control and a data unit queue for each media type or source, where data units containing encoded media frames are temporarily stored for transmission. Figure 1 shows the details when a single media source (or stream) is used. Scheduling and prioritization of multiple streams is not covered in this document. However, if multiple flows are sent, each data unit queue can be served based on some defined priority or simply in a round-robin fashion. Alternatively, a similar approach as coupled congestion control can be applied.

Sender Functional View | Sender | | Congestion | ref_wnd | Transmission | | Control |-------------------------->| Control | +------------+ Bytes in flight +------+-------+ ^ | | | Congestion Feedback Data unit Bytes in flight | | v +------+-------------------------------------------------+ | UDP socket | +--------------------------------------------------------+ ]]>

Media frames are encoded and forwarded to the data unit queue in . The data units are sent by the sender transmission controller from the data unit queue. The sender transmission controller (in case of multiple flows a transmission scheduler) sends the data units to the UDP socket. The sender transmission controller limits the sending rate so that the number of bytes in flight is less than the reference window albeit with a slack to avoid that packets are unnecessarily delayed in the Data Units Queue. The slack avoids unnecessary delays in the Data Units Queue when the link is uncongested. The bytes in flight, however, become more restrained in congested situations to avoid large variations in queue delay and bitrate. A pacing rate is calculated based on the target bitrate provided by the media rate controller. Feedback about the received bytes as well as metadata to estimate the congestion level or queuing delay are provided to the network congestion controller. The network congestion controller calculates the reference window and provides it together with the bytes in flight to the sender transmission control. The reference window and the estimated RTT is further provided to the media rate control to compute the appropriate target bitrate. The target bitrate is updated whenever the reference window is updated. Additional parameters are also communicated to make the rate control more stable when the congestion window is very small or when L4S is not active.

Network Congestion Control The network congestion control sets reference window (ref_wnd) which puts an upper limit on how many bytes can be in flight, i.e., transmitted but not yet acknowledged. The reference window is however not an absolute limit as slack is given to efficiently transmit temporary larger media objects, such as video frames. This means that the algorithm prefers to build up a queue in the network rather than on the sender side. Additional congestion that this causes will reflect back and cause a reduction of the reference window. The reference window is reduced if congestion is detected. Similar to LEDBAT, the reference window is reduced either by a fixed fraction in case of packet loss or Classic ECN marking, or if the estimated queue delay exceeds a given threshold, depending on how much the delay exceeds the threshold. SCReAMv2 reduces the reference window in proportion to the fraction of marked packets if L4S is used (scalable congestion control). In each RTT ref_wnd will be reduced at most once if congestion is detected based on the following conditions: a) on loss: ref_wnd *= LOSS_BETA b) classic ECN CE: ref_wnd *= ECN_BETA b) on L4S ECN CE or increased delay: ref_wnd *= 1.0 - l4sAlpha / 2.0 Independent of the congestion detection, ref_wnd is increased by a fix increment for each RTT. The reference window increases multiplicatively after a number of congestion free RTTs, this enables a faster convergence to a higher link speed. The increase factor is also adjusted relative to a previous max value.

Sender Transmission Control The sender transmission control limits sending rate based on the relation of the estimated link throughput (bytes in flight) and the reference window. The respective sending rate is achieved by applying packet pacing: Even if the send window allows for the transmission of a number of packets, these packets are not transmitted immediately; rather, they are transmitted in intervals given by the packet size and the estimated link throughput. Packets are generally paced at a higher rate than the target bitrate, this makes it possible to transmit occasionally larger video frames in a timely manner. Further, this mitigates issues with ACK compression that can cause increased jitter and/or packet loss in the media traffic.

Media Rate Control The media rate control calculates the media rate based on the reference window and RTT. The media rate needs to ramp up quickly enough to get a fair share of the system resources when link throughput increases. Further, the reaction to reduced throughput must be prompt to avoid getting too much data queued in the data unit queue(s) in the sender. For the case that multiple streams are enabled, the media rate among the streams are distributed according to relative priorities. In cases where the sender's frame queues increase rapidly, such as in the case of a Radio Access Type (RAT) handover, the SCReAMv2 sender MAY implement additional actions, such as discarding of encoded media frames or frame skipping to ensure that the data unit queues are drained quickly. Frame skipping results in the frame rate being temporarily reduced. Which method to use is a design choice and is outside the scope of this algorithm description as the actual strategy depends on the application. For instance for a video conferencing application it can be better to avoid discarding media frames even though they are late, whereas a remote controlled application benefits from low end to end delay, in which case it is better to discard late frames and generate a new keyframe to maintain correct media coder state.

Detailed Description of SCReAMv2 Sender Algorithm This section describes the sender-side algorithm in more detail. It is split between the network congestion control, sender transmission control, and media rate control.

Sender Side State The sender needs to maintain sending state and state about the received feedback, as explained in the following subsections.

Status Update When Sending Data SCReAMv2 is a window-based and byte-oriented congestion control protocol, where the number of bytes transmitted is inferred from the size of the transmitted data units. Thus, a list of transmitted data units and their respective transmission times (wall-clock time) MUST be kept for further calculation. Further the following variables are needed:

• data_unit_size (0): Size [byte] of the last transmitted data unit.
• bytes_in_flight: The number of bytes in flight is computed as the sum of the sizes of the data units ranging from the data unit most recently transmitted, down to but not including the acknowledged data unit with the highest sequence number.
• bytes_in_flight_prev (0): Number of bytes in flight from previous round [byte].

bytes_in_flight can be also seen as the difference between the highest transmitted byte sequence number and the highest acknowledged byte sequence number. As an example: If a data unit with sequence number SN is transmitted and the last acknowledgement indicates SN-5 as the highest received sequence number, then bytes_in_flight is computed as the sum of the size of data units with sequence number SN-4, SN-3, SN-2, SN-1, and SN. It does not matter if, for instance, the data unit with sequence number SN-3 was lost -- the size of data unit with sequence number SN-3 will still be considered in the computation of bytes_in_flight.

• ref_wnd_ratio (0.0): Ratio between MSS and ref_wnd capped to not exceed 1.0 (min(1.0, MSS / ref_wnd)).
• max_bytes_in_flight (0): The maximum number of bytes in flight in the current round trip [byte].
• max_bytes_in_flight_prev (0): The maximum number of bytes in flight in previous round trip [byte].

As bytes_in_flight can spike when congestion occurs, using the minimum of max_bytes_in_flight and max_bytes_in_flight_prev makes it more likely that an uncongested bytes_in_flight is used.

Status Update on Receiving Feedback The feedback from the receiver is assumed to consist of the following elements:

• The receiver wall-clock timestamp corresponding to the reception time of the data unit with the highest sequence number.
• data_units_acked: A list of received data units' sequence numbers.
• data_units_acked_ce: An indication if data units are ECN-CE marked. The ECN status can be either per data unit or an accumulated count of ECN-CE marked data units.
• bytes_newly_acked (0): Number of bytes newly ACKed, reset to 0 when congestion window is updated [byte].
• bytes_newly_acked_ce (0): Number of bytes newly ACKed and CE marked, reset to 0 when reference window is updated [byte].

bytes_newly_acked is incremented with a value corresponding to how much the highest sequence number has increased since the last feedback. As an example: If the previous acknowledgement indicated the highest sequence number N and the new acknowledgement indicated N+3, then bytes_newly_acked is incremented by a value equal to the sum of the sizes of data units with sequence number N+1, N+2, and N+3. Data units that are lost are also included, which means that even though, e.g., data unit N+2 was lost, its size is still included in the update of bytes_newly_acked. The bytes_newly_acked_ce is, similar to bytes_newly_acked, a counter of bytes newly acked with the extra condition that they are ECN-CE marked. The bytes_newly_acked and bytes_newly_acked_ce are reset to zero after a ref_wnd update.

Network Congestion Control This section explains the network congestion control, which calculates the reference window. The reference window gives an upper limit to the number of bytes in flight.

Congestion Detection: Delay, Data Unit Loss and ECN-CE Congestion is detected based on three different indicators:

• Lost data units detected.
• ECN-CE marked data units detected either for classic ECN or L4S.
• Estimated queue delay exceeds a threshold.

A congestion event occurs if any of the above indicators are true AND it is at least min(VIRTUAL_RTT, s_rtt) since the last congestion event. This ensures that the reference window is reduced at most once per smoothed RTT.

Detecting Lost Data Units The reference window backoff due to loss events is deliberately a bit less than is the case with TCP Reno, for example. TCP is generally used to transmit whole files; the file is then like a source with an infinite bitrate until the whole file has been transmitted. SCReAMv2, on the other hand, has a source which rate is limited to a value close to the available transmit rate and often below that value; the effect is that SCReAMv2 has less opportunity to grab free capacity than a TCP-based file transfer. To compensate for this, it is RECOMMENDED to let SCReAMv2 reduce the reference window less than what is the case with TCP when loss events occur. Lost data unit detection is based on the received sequence number list. A reordering window SHOULD be applied to prevent data unit reordering from triggering loss events. The reordering window is specified as a time unit, like the ideas behind Recent ACKnowledgement (RACK) . The computation of the reordering window is made possible by means of a lost flag in the list of transmitted data units. This flag is set if the received sequence number list indicates that the given data unit is missing. If later feedback indicates that a previously lost marked data unit was indeed received, then the reordering window is updated to reflect the reordering delay. The reordering window is given by the difference in time between the event that the data unit was marked as lost and the event that it was indicated as successfully received. Loss is detected if a given data unit is not acknowledged within a time window (indicated by the reordering window) after a data unit with a higher sequence number was acknowledged.

Receiving ECN-CE with classic ECN In classic ECN mode the ref_wnd is scaled by a fixed value (BETA_ECN). The reference window backoff due to an ECN event MAY be smaller than if a loss event occurs. This is in line with the idea outlined in to enable ECN marking thresholds lower than the corresponding data unit drop thresholds.

Receiving ECN-CE for L4S The ref_wnd is scaled down in proportion to the fraction of marked data units per RTT. The scale down proportion is given by l4s_alpha, which is an Exponentially Weighted Moving Average (EWMA) filtered version of the fraction of marked data units per RTT. This is inline with how DCTCP works . Additional methods are applied to make the reference window reduction reasonably stable, especially when the reference window is only a few MSS. In addition, because SCReAMv2 can quite often be source limited, additional steps are taken to restore the reference window to a proper value after a long period without congestion. l4s_alpha is calculated based in number of data units delivered (and marked) the following way: = min(0.01, s_rtt)) # l4s_alpha is calculated from data_units marked istf bytes marked fraction_marked_t = data_units_marked_this_rtt/ data_units_delivered_this_rtt # Apply EWMA filtering of fraction_marked_t l4s_alpha = L4S_AVG_G * fraction_marked_t + (1.0 - L4S_AVG_G) * l4S_alpha last_update_l4s_alpha_time = now data_units_delivered_this_rtt = 0 data_units_marked_this_rtt = 0 last_fraction_marked = fraction_marked_t end ]]> This makes calculation of L4S alpha more accurate at very low bitrates, given that the tail data unit in e.g. a video frame is often smaller than MSS. The following variables are used:

• l4s_alpha (0.0): Average fraction of marked data units per RTT.
• last_update_l4s_alpha_time (0.0): Last time l4s_alpha was updated [s].
• data_units_delivered_this_rtt (0): Counter for delivered data units.
• data_units_marked_this_rtt (0): Counter delivered and ECN-CE marked data units.
• last_fraction_marked (0.0): fraction marked data units in last update

The following constants are used:

• L4S_AVG_G (1.0/16): Exponentially Weighted Moving Average (EWMA) factor

Detecting Increased Queue Delay SCReAMv2 implements a delay-based congestion control approach where it mimics L4S congestion marking when the averaged queue delay exceeds a target threshold. This threshold is set to qdelay_target/2 and the congestion backoff factor (l4s_alpha_v) increases linearly from 0 to 100% as qdelay_avg goes from qdelay_target/2 to qdelay_target. The averaged qdelay (qdelay_avg) is used to avoid that the SCReAMv2 congestion control over-reacts to scheduling jitter, sudden delay spikes due to e.g. handover or link layer retransmissions. qdelay_avg is updated with a slow attack, fast decay EWMA filter as described below. = min(virtual_rtt, s_rtt)) # Calculate qdelay_avg if (qdelay < qdelay_avg) qdelay_avg = qdelay else qdelay_avg = QDELAY_AVG_G * qdelay + (1.0 - QDELAY_AVG_G) * qdelay_avg end # Optional code to calculate the variation on queue delay, which is an # Indication of congestion or near congestion. if (REDUCE_JITTER == true) calculate_latency_diff_avg() end last_update_qdelay_avg_time = now end ]]> The following variables are used:

• qdelay (0.0): When the sender receives feedback, the qdelay [s] is calculated as outlined in . A qdelay sample is obtained for each received acknowledgement. It is typically sufficient with one update per received acknowledgement.
• qdelay_avg(0.0): The average qdelay [s].
• qdelay_avg_prev(0.0): The qdelay_avg from previous update [s].
• last_update_qdelay_avg_time (0.0): Last time qdelay_avg was updated [s]
• s_rtt (0.0): Smoothed RTT [s], computed with a similar method to that described in

The following constants are used:

• QDELAY_AVG_G (1.0/4): Exponentially Weighted Moving Average (EWMA) factor for qdelay_avg
• REDUCE_JITTER (false): (optional) config knob to enable jitter filtering

The SCReAM algorithm can be further improved for a greater rate stability by taking variations in qdelay into consideration. The goal is to react less to delay variations, caused by e.g. link layer related scheduling and retransmissions, but still be reactive to actual queue delay, caused by congestion. The code below provides a example implementation but more advanced statistical analysis can be considered. The variable latency_diff_avg tracks the difference between a short and long average of the qdelay. A positive delta indicates increased latency and increased latency_diff_avg and vice versa. The use of long and short average gives some robustness against e.g. scheduling jitter. 0.0) # Increase latency_diff_avg with additional restriction if qdelay is low tmp_t = min(1.0, qdelay_avg/LATENCY_DIFF_MARGIN_2) latency_diff_avg += LATENCY_DIFF_UP_GAIN*diff_t*tmp_t else # Decrease latency_diff_avg latency_diff_avg += LATENCY_DIFF_DOWN_GAIN*diff_t end latency_diff_avg = max(0.0, min(1.0, latency_diff_avg)) else qdelay_long_avg = qdelay_short_avg end end ]]> The following variables are used:

• qdelay_short_avg (0.0): Short average queue delay [s], needed only if REDUCE_JITTER==true
• qdelay_long_avg (0.0): Long average queue delay [s], needed only if REDUCE_JITTER==true
• latency_diff_avg (0.0): indicates how much the queue delay varies[s]

The following constants are used:

• QDELAY_SHORT_AVG_G (1.0/5): Exponentially Weighted Moving Average (EWMA) factor for qdelay_short_avg
• QDELAY_LONG_AVG_G (1.0/50): Exponentially Weighted Moving Average (EWMA) factor for qdelay_long_avg
• LATENCY_DIFF_MARGIN_1 (0.001): Latency margin for increasing latency_diff_avg [s]
• LATENCY_DIFF_MARGIN_2 (0.01): Additional margin to avoid over-sensitivity when qdelay is low [s]
• LATENCY_DIFF_UP_GAIN (20.0): Gain factor for increased latency
• LATENCY_DIFF_DOWN_GAIN (2.0): Gain factor for decreased latency

Reference Window Update The reference window update contains two parts. One that reduces the reference window when congestion events (listed above) occur, and one part that continuously increases the reference window. The reference window is reduced whenever a congestion event is detected. A congestion event is either packet loss, ECN-CE marked packets or increased queue delay. The reference window reduction is applied at most once every (smoothed RTT) or, to improve fairness to other flows with a different RTT, at least very VIRTUAL_RTT second. The reference window is increased once per smother RTT (s_rtt). The reference window can also increase even when a congestion event occurs. Their provided the L4S scalable congestion control property where a one-MSS-increase of the reference window per RTT is offset by two marked packets per RTT. The following variables are defined:

• ref_wnd (MIN_REF_WND): Reference window [byte].
• ref_wnd_i (1): Reference window inflection point [byte].
• qdelay_target (QDELAY_TARGET_LO): qdelay target [s], a variable qdelay target is introduced to manage cases where a fixed qdelay target would otherwise starve the data flow under such circumstances (e.g., FTP competes for the bandwidth over the same bottleneck). The qdelay target is allowed to vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI.
• last_congestion_detected_time (0.0): Last time congestion detected [s].
• is_congestion_detected (false): True if congestion has been detected.
• last_reaction_to_congestion_time (0.0): Last time congestion avoidance occurred [s].
• ref_wnd_i_update_allowed (true): Allow update of ref_wnd_i.
• ref_wnd_i_update_time (0.0): Last time ref_wnd_i was updated [s].
• ref_wnd_lowest (0): Lowest reference window during a congestion epoch [byte].

Further the following constants are used (the RECOMMENDED values, within parentheses "()", for the constants are deduced from experiments):

• QDELAY_TARGET_LO (0.06): Target value for the minimum qdelay [s].
• QDELAY_TARGET_HI (0.4): Target value for the maximum qdelay [s]. This parameter provides an upper limit to how much the target qdelay (qdelay_target) can be increased in order to cope with competing loss-based flows. However, the target qdelay does not have to be initialized to this high value, as it would increase end-to-end delay and also make the rate control and congestion control loops sluggish.
• MIN_REF_WND (3000): Minimum reference window [byte].
• BYTES_IN_FLIGHT_HEAD_ROOM (1.5): Extra headroom for bytes in flight.
• BETA_LOSS (0.7): ref_wnd scale factor due to loss event.
• BETA_ECN (0.8): ref_wnd scale factor due to ECN event.
• MSS (1000): Maximum segment size = Max data unit size [byte].
• POST_CONGESTION_DELAY_RTT (100): Determines how many RTTs after a congestion event the reference window growth should be cautious.
• MUL_INCREASE_FACTOR (0.02): Determines how much (as a fraction of ref_wnd) that the ref_wnd can increase per RTT.
• IS_L4S (false): Congestion control operates in L4S mode.
• VIRTUAL_RTT (0.025): Virtual RTT [s]. This mimics Prague's RTT fairness such that flows with RTT below VIRTUAL_RTT should get a roughly equal share over an L4S path.
• REF_WND_I_UPDATE_MAX_HOLD_RTTS (50): Max number of RTTs that ref_wnd_i is held for update.

Reference Window Reduction ref_wnd_i && scl_t < 1.0) # Restrict ref_wnd increase when ref_wnd > ref_wnd_i and # queue delay varies scl_t = max(0.2, scl_t * latency_diff_ref_wnd_scale_t) end if (loss_detected || data_units_marked) last_congestion_detected_time = now end # The reference window is updated every s_rtt if (now - last_reaction_to_congestion_time >= s_rtt if (loss_detected) is_loss_t = true else if (data_units_marked) is_ce_t = true else if (qdelay_avg > qdelay_target / 2 && qdelay_avg >= qdelay_avg_prev && !(is_ce_t || is_loss_t)) # The calculation of l4s_alpha_v_t is based on qdelay_avg to reduce # sensitivity to sudden non-congestion related delay spikes that can # occur due to lower protocol retransmissions or cell change. # Congestion is not signalled if qdelay_avg shows a tendency to decrease. l4s_alpha_v_t = min(1.0, max(0.0, (qdelay_avg - qdelay_target / 2) / (qdelay_target / 2))) is_virtual_ce_t = true last_congestion_detected_time = now end end qdelay_avg_prev = qdelay_avg if (is_loss_t || is_ce_t || is_virtual_ce_t) is_congestion_detected = true # Update ref_wnd_i if possible if (ref_wnd > max(ref_wnd_lowest+MSS, ref_wnd_lowest*1.05) || now - ref_wnd_i_update_time > REF_WND_I_UPDATE_MAX_HOLD_RTTS*s_rtt) # Allow update of ref_wnd_i only if ref_wnd has increased sufficiently (5%) above the # lowest ref_wnd or the hold time has expired. # This prevents that ref_wnd_i is wrongly stepped down during a period of congestion. ref_wnd_i_update_allowed = true end if (ref_wnd_i_update_allowed) # Update ref_wnd_i ref_wnd_i = ref_wnd ref_wnd_i_update_allowed = false ref_wnd_i_update_time = now end end # Either loss, ECN mark or increased qdelay is detected if (is_loss_t) # Loss is detected ref_wnd = ref_wnd * BETA_LOSS end if (is_ce_t) # ECN-CE detected if (IS_L4S) # L4S mode backoff_t = l4s_alpha / 2 # Jitter is considered large if the qdelay is larger than qdelay_target/4 # when L4S is enabled if (qdelay_avg < qdelay_target * 0.25) # Scale down backoff if close to the last known max reference window # This is complemented with a scale down of the reference window increase backoff_t *= scl_t end if (now - last_reaction_to_congestion_time > 100 * s_rtt) # A long time (>100 RTTs) since last congested because # link throughput exceeds max video bitrate. # There is a certain risk that ref_wnd has increased way above # bytes in flight, so we reduce it here to get it better on # track and thus the congestion episode is shortened ref_wnd = min(ref_wnd, max_bytes_in_flight_prev) end ref_wnd = (1.0 - backoff_t) * ref_wnd else # Classic ECN mode ref_wnd = ref_wnd * BETA_ECN end end if (is_virtual_ce_t) backoff_t = l4s_alpha_v_t / 2 ref_wnd = (1.0 - backoff_t) * ref_wnd end ref_wnd = max(MIN_REF_WND, ref_wnd) ref_wnd_lowest = ref_wnd if (is_loss_t || is_ce_t || is_virtual_ce_t) last_reaction_to_congestion_time = now end ]]> The reference window reduction, when congestion is detected due to L4S marking or increased delay, is constrained by a number of factors:

• For cases that the target rate is lower than the acknowledged bitrate, it is likely that the target bitrate is already reduced because of an increased RTT. A further (large) decrease of the reference window would then only lead to an unnecessary undershoot.
• For large RTTs, a restriction attenuates variations in the reference window
• When the reference window is close to the last known max value, this reduces large variations
• When ref_wnd_delay_scale is small

Link layer losses, i.e. losses that are not congestion related can lead to unwarranted congestion back-off. One method is to apply congestion backoff only when an average loss rate exceeds a threshold. A suggested modification to the code above is found in .

Reference Window Increase 1.0) tmp_t = 1.0 + (tmp_t - 1.0) * post_congestion_scale_t end increment_t *= tmp_t ref_wnd_prev_ = ref_wnd # Increase ref_wnd only if bytes in flight is large enough # Quite a lot of slack is allowed here to avoid that bitrate # locks to low values. # Increase is inhibited if max target bitrate is reached. max_allowed_t = MSS + max(max_bytes_in_flight, max_bytes_in_flight_prev) * BYTES_IN_FLIGHT_HEAD_ROOM int ref_wnd_t = ref_wnd + increment_t if (ref_wnd_t <= max_allowed_t && target_bitrate < TARGET_BITRATE_MAX) ref_wnd = ref_wnd_t end ]]> The latency_diff_ref_wnd_scale_t scales the reference window increase. Firstly the increase is downscaled to target between 0.5 and 2.0 (L4S) marked packets per RTT. For L4S this reflects that larger queue delay spikes lead to that the L4S marking saturates at 100% with the consequence that the congestion is under estimated. Secondly an additional restriction is applied when L4S is not enabled to make non-L4S rate adaptation more stable. The multiplicative increase is restricted directly after a congestion event and the restriction is gradually relaxed as the time since last congested increased. The restriction makes the reference window growth to be no faster than additive increase when congestion continuously occurs. For L4S operation this means that the SCReAMv2 algorithm will adhere to the 2 marked data units per RTT equilibrium at steady state congestion, with the exception of the case below. The reference window increase is restricted to values as small as 0.25MSS/RTT when the reference window is close to the last known max value (ref_wnd_i). This increases stability and reduces periodic overshoot. It is particularly important that the reference window reflects the transmitted bitrate especially in L4S mode operation. An inflated ref_wnd takes extra RTTs to bring down to a correct value upon congestion and thus causes unnecessary queue buildup. At the same time the reference window must be allowed to be large enough to avoid that the SCReAMv2 algorithm begins to limit itself, given that the target bitrate is calculated based on the ref_wnd. Two mechanisms are used to manage this:

• Restore correct value of ref_wnd upon congestion. This is done if is a prolonged time since the link was congested. A typical example is that SCReAMv2 has been rate limited, i.e. the target bitrate has reached the TARGET_BITRATE_MAX.
• Limit ref_wnd when the target_bitrate has reached TARGET_BITRATE_MAX. The ref_wnd is restricted based on a history of the last max_bytes_in_flight values. See for details.

The two mechanisms complement one another.

Sender Transmission Control The Sender Transmission control calculates of send window at the sender. Data units are transmitted if allowed by the relation between the number of bytes in flight and the reference window. This is controlled by the send window:

• send_wnd (0): Upper limit to how many bytes can currently be transmitted. Updated when ref_wnd is updated and when data unit is transmitted [byte].

The sender transmission control is executed for each transmitted packet, the send interval is dictated by the pacing but is restricted by the send window. In practice it, however, can be more practical to transmit packets in small burst to save processing power, or alternatively, to offload the pacing to OS kernel function.

Send Window Calculation The basic design principle behind data unit transmission in SCReAM was to allow transmission only if the number of bytes in flight is less than the congestion window. There are, however, two reasons why this strict rule will not work optimally:

• Bitrate variations: Media sources such as video encoders generally produce frames whose size always vary to a larger or smaller extent. The data unit queue absorbs the natural variations in frame sizes. However, the data unit queue should be as short as possible to prevent the end-to-end delay from increasing. A strict 'send only when bytes in flight is less than the reference window' rule can cause the data unit queue to grow simply because the send window is limited. The consequence is that the reference window will not increase, or will increase very slowly, because the reference window is only allowed to increase when there is a sufficient amount of data in flight. The final effect is that the media bitrate increases very slowly or not at all.
• Reverse (feedback) path congestion: Especially in transport over buffer-bloated networks, the one-way delay in the reverse direction can jump due to congestion. The effect is that the acknowledgements are delayed, and the self-clocking is temporarily halted, even though the forward path is not congested. The ref_wnd_overhead allows for some degree of reverse path congestion as the bytes in flight is allowed to exceed ref_wnd.

In SCReAMv2, the send window is given by the relation between the adjusted reference window and the amount of bytes in flight according to the pseudocode below. The multiplication of ref_wnd with ref_wnd_overhead has the effect that bytes in flight is 'around' the ref_wnd rather than limited by the ref_wnd. The implementation allows the data unit queue to be small even when the frame sizes vary and thus, increased e2e delay can be avoided. A min window of 2*MSS is applied to avoid that the ACK clocking stalls in case MIN_REF_WND is set very low, for cases when SCReAM is used to congestion control at very low bitrates. The send window is updated whenever a data unit is transmitted or an feedback messaged is received. The ref_wnd_overhead is adjusted dynamically. A large overhead is beneficial when the network link is uncongested as it allows to transmit large media frames with little transmission delay. A large overhead is also beneficial for cases where network links use virtual queue marking or can temporarily absorb bursts from L4S capable flows. If, on the other hand the network link is congested, then it is better to restrict how much bytes in flight exceeds the reference window because is not possible to push data faster than the reference window allows. This restriction reduces variations in RTT caused by self-congestion and improves performance for the cases where media encoders are slow to react to changes in target rate. The following constants are used (the RECOMMENDED values, within parentheses "()", for the constants are deduced from experiments):

• REF_WND_OVERHEAD_MIN (1.5): Indicates a lower limit how much bytes in flight is allowed to exceed ref_wnd.
• REF_WND_OVERHEAD_MAX (3.0): Indicates an upper limit how much bytes in flight is allowed to exceed ref_wnd. This is roughly equal to MAX_RELAXED_PACING_FACTOR to allow that media frames can be transmitted quickly when the transmission channel is uncongested.

The ref_wnd_overhead is calculated as:

Packet Pacing Packet pacing is used in order to mitigate coalescing, i.e., when packets are transmitted in bursts, with the risks of increased jitter and potentially increased packet loss. Packet pacing is also highly recommended to be used with L4S and also mitigates possible issues with queue overflow due to key-frame generation in video coders. However, when the link is uncongested, it is beneficial to relax the packet pacing and allow frames to be transmitted faster, to reduce end to end delay on the application layer.

• pace_bitrate (1e6): Data unit pacing rate [bps].
• t_pace (1e-6): Pacing interval between data units [s].

The following constants are used by the packet pacing:

• RATE_PACE_MIN (50000): Minimum pacing rate in [bps].
• PACKET_PACING_HEADROOM (1.5): Headroom for packet pacing.
• MAX_RELAXED_PACING_FACTOR (4.0): Max extra packet pacing when the media coder reaches the max bitrate. This should be roughly equal to REF_WND_OVERHEAD_MAX.
• RELAXED_PACING_LIMIT_LOW (0.8): Nominal bitrate fraction of TARGET_BITRATE_MAX at which the pacing should be increasingly relaxed.

The time interval between consecutive data unit transmissions is greater than or equal to t_pace, where t_pace is given by the equations below: data_unit_size is the size of the last transmitted data unit. RATE_PACE_MIN is the minimum pacing rate.

Media Rate Control The media rate control algorithm is executed whenever the reference window is updated and calculates the target bitrate. It is, however, not necessary to execute this part more often than the frame period of the media encoder.

• target_bitrate (0): Media target bitrate [bps].
• rate_adjust_factor (0.0): Adjustment factor to avoid unnecessary media queue buildup.
• frame_size_dev (0.0): Frame size deviation.
• frame_period (0.02): An estimated frame period.

The following constants are used by the media rate control:

• PACKET_OVERHEAD (20): Estimated packetization overhead [byte].
• TARGET_BITRATE_MIN: Minimum target bitrate in [bps] (bits per second).
• TARGET_BITRATE_MAX: Maximum target bitrate in [bps].
• RATE_ADJUST_GAIN (1.0/16): Adjustment gain for rate adjustment to compensate for media queue buildup.
• FRAME_SIZE_DEV_ALPHA (1.0/64): Time constant to compensate for varying frame sizes.

The target bitrate is essentially based on the reference window ref_wnd and the (smoothed) RTT s_rtt according to The role of the media rate control is to strike a reasonable balance between a low amount of queuing in the data unit queue(s) and a sufficient amount of data to send in order to keep the data path busy. Because the reference window is updated based on loss, ECN-CE and delay, so does the target rate also update. The code above however needs some modifications to work fine in a number of scenarios

• ref_wnd is very small, just a few MSS or smaller
• The media queue grows large, which can result in large e2e delay
• The frame sizes vary much, which can result in larger e2e delay if not compensated for

The rate_adjust_factor helps to reduce the target rate when the delay in the data unit increases beyond frame_period/4, this allows for some modest queue buildup to ensure a good link utilization. The frame_size_dev calculates the positive deviation in frame sizes from the nominal, this helps compensate for larger variations in frame size, systematic errors in media encoder output bitrate and also to some extent sluggish media rate control loops where the media coder rate lags behind the target bitrate. The complete pseudo code for adjustment of the target bitrate is shown below. The algorithm parts for rate_adjust_factor and frame_size_dev are suggested examples how to compensate for that frame sizes deviate from the nominal.

Additional functions This section covers additional functionality that is not critical for the function of the SCReAM congestion control algorithm, but can nevertheless, improve the performance.

Clock drift issues and remedies SCReAM can suffer from the same issues with clock drift as is the case with LEDBAT . However, Appendix A.2 in describes ways to mitigate issues with clock drift. A clock drift compensation method is also implemented in . The SCReAM implementation resets base delay history when it is determined that clock drift or skip becomes too large. This is achieved by reducing the target bitrate for a few RTTs. The variables and constants are: * delay_min_avg (0): A long term averaged min queue delay [s].

• qdelay_min (MAX_VALUE): The min queue delay measured during an RTT [s], initialized to a very high value.
• QDELAY_MIN_AVG_ALPHA (1.0/256): Slow EWMA time constant for delay_min_avg.

The steps for the clock drift compensation is as follows:

• Store the min qdelay (qdelay_min) during one RTT.
• When an RTT has elapsed:

qdelay_target / 4 qdelay_min_avg = 0 # Implement the following actions # 1. Reset queue delay history # 2. Scale down target bitrate by 50% for a period of max(5 * s_rtt, 0.2) end ]]>

Link layer losses Link layer losses, i.e. losses that are not congestion related can lead to unwarranted congestion backoff. One method is to apply a conditional loss backoff only when an average loss rate exceeds a threshold. This increases robustness against non-congestion related losses. One problem is that such a method can also increase congestion related packet loss which can be detrimental for real time media such as video. This is resolved in that immediate loss backoff is triggered when the queue delay increases. While the conditional loss backoff increases robustness against link layer losses, it is inevitable that the algorithm can delay congestion backoff and thus cause increased packet loss rate. The constant LOSS_RATE_THRESHOLD should therefore be set low enough, with the objective to increase robustness to link layer losses only. A loss rate is calculated for each packet with an average value reflecting the number of packets send with in two RTTs or 4/LOSS_RATE_THRESHOLD packets for small ref_win values. This avoids that multiple consecutive link layer losses cause the loss rate to increase too quickly. The averaging is selected to be slow enough to avoid that single packet drops cause backoff, provided that the queue delay is low, and fast enough to avoid excessive packet loss in the presence of very shallow queues. The following variables and constants are used:

• loss_rate (0.0): Average loss rate.
• packet_is_lost: Set to true if a packet is determined to be lost.
• LOSS_RATE_THRESHOLD (0.01): Threshold for triggering loss based reference window backoff.

The code below modifies the 'if (loss_detected)' part in LOSS_RATE_THRESHOLD || qdelay_avg > qdelay_target / 4) is_loss_t = true end .. ]]>

Reference window undershoot at congestion The reference window can in certain cases undershoot when congestion occurs, one such case is when the RTT increases at the same time that the reference window is reduced. The RTT increase can push down the target rate faster then the reference window is reduced. An additional reduction of the reference window can be superfluous in some cases. One method to determine if additional reduction is unnecessary is to inspect how the acknowledged bitrate relates to the target bitrate. If the target rate is well below the ACKed bitrate, then additional reduction of the reference window is unnecessary. This is implemented as additional code that modifies the reference window backoff in . The variables and constants are:

• ACKED_BITRATE_MARGIN (0.8): Safety margin for triggering of downscaling of backoff for cases where target bitrate is already low.
• BACKOFF_SCALE_LOW_TARGETRATE (0.25): Downscaling of backoff when target rate is already low compared to the ACKnowledged bitrate.
• acked_bitrate (0.0): A running average of the ACKnowledged bitrate [bps]. The averaging time should be around one RTT. For periodic media such as video it is beneficial to calculate the acked_bitrate over two frame periods for a reasonably accurate value.

Competing Flows Compensation It is likely that a flow will have to share congested bottlenecks with other flows that use a more aggressive congestion control algorithm (for example, large FTP flows using loss-based congestion control). The worst condition occurs when the bottleneck queues are of tail-drop type with a large buffer size. SCReAMv2 takes care of such situations by adjusting the qdelay_target when loss-based flows are detected, as shown in the optional pseudocode below. 0.002) # Data unit losses detected qdelay_target = 1.5 * new_target_t else if (qdelay_norm_var_t < 0.2) # Reasonably safe to set target qdelay qdelay_target = new_target_t else # Check if target delay can be reduced; this helps prevent # the target delay from being locked to high values forever if (new_target_t < QDELAY_TARGET_LO) # Decrease target delay quickly, as measured queuing # delay is lower than target qdelay_target = max(qdelay_target * 0.5, new_target_t) else # Decrease target delay slowly qdelay_target *= 0.9 end end end # Apply limits qdelay_target = min(QDELAY_TARGET_HI, qdelay_target) qdelay_target = max(QDELAY_TARGET_LO, qdelay_target) ]]> The following variable is used:

• loss_event_rate (0.0): The estimated fraction of RTTs with lost data units detected.

Two temporary variables are calculated. qdelay_norm_avg_t is the long-term average queue delay, qdelay_norm_var_t is the long-term variance of the queue delay. A high qdelay_norm_var_t indicates that the queue delay changes; this can be an indication that bottleneck bandwidth is reduced or that a competing flow has just entered. Thus, it indicates that it is not safe to adjust the queue delay target. A low qdelay_norm_var_t indicates that the queue delay is relatively stable. The reason could be that the queue delay is low, but it could also be that a competing flow is causing the bottleneck to reach the point that data unit losses start to occur, in which case the queue delay will stay relatively high for a longer time. The queue delay target is allowed to be increased if either the loss event rate is above a given threshold or qdelay_norm_var_t is low. Both these conditions indicate that a competing flow may be present. In all other cases, the queue delay target is decreased. The function that adjusts the qdelay_target is simple and could produce false positives and false negatives. The case that self-inflicted congestion by the SCReAMv2 algorithm may be falsely interpreted as the presence of competing loss-based FTP flows is a false positive. The opposite case -- where the algorithm fails to detect the presence of a competing FTP flow -- is a false negative. Extensive simulations have shown that the algorithm performs well in LTE and 5G test cases and that it also performs well in simple bandwidth-limited bottleneck test cases with competing FTP flows. However, the potential failure of the algorithm cannot be completely ruled out. A false positive (i.e., when self-inflicted congestion is mistakenly identified as competing flows) is especially problematic when it leads to increasing the target queue delay, which can cause the end-to-end delay to increase dramatically. If it is deemed unlikely that competing flows occur over the same bottleneck, the algorithm described in this section MAY be turned off. One such case is QoS-enabled bearers in 3GPP-based access such as LTE and 5G. However, when sending over the Internet, often the network conditions are not known for sure, so in general it is not possible to make safe assumptions on how a network is used and whether or not competing flows share the same bottleneck. Therefore, turning this algorithm off must be considered with caution, as it can lead to basically zero throughput if competing with loss-based traffic.

Receiver Requirements on Feedback Intensity The simple task of the receiver is to feedback acknowledgements with time stamp and ECN bits indication for received data units to the sender. Upon reception of each data unit, the receiver MUST maintain enough information to send the aforementioned values to the sender via an RTCP transport- layer feedback message. The frequency of the feedback message depends on the available RTCP bandwidth. The requirements on the feedback elements and the feedback interval are described below. SCReAMv2 benefits from relatively frequent feedback. It is RECOMMENDED that a SCReAMv2 implementation follows the guidelines below. Feedback should forcibly be transmitted in any of these cases:

• More than N data units received since last feedback has been transmitted. N=16 has been tested with good results.
• A data unit with marker bit set or other last data unit for media frame is received.
• A max defined interval between feedback reports. Values such as 40 ms has been tested with good results.

The feedback interval depends on the media bitrate. At low bitrates, it is sufficient with feedback every frame; while at high bitrates, a shorter feedback interval is recommended to keep the self-clocking in SCReAMv2 working well. One indication that feedback is too sparse is that the SCReAMv2 implementation cannot reach high bitrates, even in uncongested links. More frequent feedback can solve this issue. The transmission interval is not critical. So, in the case of multi-stream handling between two hosts, the feedback for two or more synchronization sources (SSRCs) can be bundled to save UDP/IP overhead. SCReAMv2 works with AVPF regular mode; immediate or early mode is not required by SCReAMv2 but can nonetheless be useful for RTCP messages not directly related to SCReAMv2, such as those specified in . It is RECOMMENDED to use reduced-size RTCP , where regular full compound RTCP transmission is controlled by trr-int as described in . While the guidelines above are somewhat RTCP specific, similar principles apply to for instance QUIC.

Discussion This section covers a few discussion points.

• The target bitrate given by SCReAMv2 is the bitrate including the data unit and Forward Error Correction (FEC) overhead. The media encoder SHOULD take this overhead into account when the media bitrate is set. This means that the media coder bitrate SHOULD be computed as: media_rate = target_bitrate - data_unit_plus_fec_overhead_bitrate It is not necessary to make a 100% perfect compensation for the overhead, as the SCReAM algorithm will inherently compensate for moderate errors. Under-compensating for the overhead has the effect of increasing jitter, while overcompensating will cause the bottleneck link to become underutilized.
• The link utilization with SCReAMv2 can be lower than 100%. There are several possible reasons to this:
  • Large variations in frame sizes: Large variations in frame size makes SCReAMv2 push down the target_bitrate to give sufficient headroom and avoid queue buildup in the network. It is in general recommended to operate video coders in low latency mode and enable GDR (Gradual Decoding Refresh) if possible, to minimize frame size variations.
  • Link layer properties: Media transport in 5G in uplink typically requires to transmit a scheduling request (SR) to get permission to transmit data. Because transmission of video is frame based, there is a high likelihood that the channel becomes idle between frames (especially with L4S), in which case a new SR/grant exchange is needed. This potentially means that uplink transmission slots are unused with a lower link utilization as a result.
• Packet pacing is recommended. It is however possible to operate SCReAMv2 with packet pacing disabled, this can however give a reduced link utilization over L4S enabled paths. Additional packet pacing headroom can be beneficial if unusually large media frames are generated; this can reduce unnecessary queue build-up in the data unit queue.
• Feedback issues: RTCP feedback packets can be lost, this means that the loss detection in SCReAMv2 may trigger even though packets arrive safely on the receiver side. solves this by using overlapping RTCP feedback, i.e. RTCP feedback is transmitted no more seldom than every 16th packet, and where each RTCP feedback spans the last 32 received packets. This however creates unnecessary overhead. RR (Receiver Reports) can possibly be another solution to achieve better robustness with less overhead. QUIC overcomes this issue because of inherent design.
• SCReAM has been designed to target two marked packets per RTT in steady state when L4S is enabled. However, SCReAM can settle for a lower number of marked packets per RTT in steady state due to measures taken in the calculation of the ref_wnd and the target_bitrate that are necessary to get a stable bitrate and lower queue delay. In those cases, SCReAM may get a lower share of the link capacity when competing against e.g. a large file transfer with TCP Prague congestion control.
• SCReAM has over time been evaluated in a number of different experiments, a few examples are found in .
• SCReAM (+L4S) is currently being integrated in chrome for performance evaluation and comparison against GCC, nightly Chrome Canary builds are available at .
• The addition of the optional latency_diff_avg related restriction on ref_wnd increase can cause the rate increase to go slower when the non-congestion related jitter is high. Non-congestion related jitter can occur for instance in 5G where the amount of scheduling delay jitter depends on factors like TDD (Time Division Duplex) patterns an overall load in a cell. The algorithm is somewhat robust to scheduling jitter as it calculates latency_diff_avg based on the difference between a short and long average of the queue delay. Still, there can be cases where large amounts of scheduling jitter can give a slow ramp up of the bitrate.
• Rate policers can cause loss bursts. These loss bursts are particularly harmful for real time media transmission and it is problematic to detect the existence of rate policers in the transmission path. The best cure is that the use of rate policers is avoided in access networks.
• The competing flows compensation described in has an inherent risk of false positives, the outcome would be that an increased delay is met by an increased to delay, something that can self-amplify. The algorithm was devised already for when access links could become bloated. Things have however changed since 2017 when RFC8298 was published. Firstly, bufferbloat and remedies to it is better understood. Secondly, more recent congestion control algorithms are designed to not bloat access links that lack active queue management. Thirdly, the algorithm in that addresses clock-drift addresses this issue inherently as a competing flow still adds an offset in queue delay when SCReAM temporarily reduces its target rate temporarily. The need for competing flows compensation would therefore need to be investigated further.
• CPU limitation can lead to a case that SCReAM cannot push packets as fast as the congestion control would allow. This can lead to that ref_wnd increases due to lack of congestion signals. Even though ref_wnd increase is restricted by BYTES_IN_FLIGHT_HEAD_ROOM, the result can be that the target rate becomes overestimated, resulting in an RTP queue build-up. The not too controversial advice is therefore to limit the max target bitrate to levels that are supported by the device.
• The calculation of the target bitrate based on the reference window and the average RTT can lead to over-optimistic target rate values for instance when the source becomes idle or delivers a media bitrate that is lower than the target bitrate. To resolve this issue, it is recommended to update the average RTT with a longer time constant when bytes in flight is lower than the reference window by some margin.
• Video encoders can in some cases output a lower bitrate than the target bitrate, one example is for instance a video encoder pipeline that initiates with a low resolution or frame rate. Because ref_wnd is limited by the bytes in flight multiplied by BYTES_IN_FLIGHT_HEAD_ROOM the result can be that the bitrate is stuck at a low value. WebRTC exploits padding to overcome this issue. Unused target bitrate is filled up with duplicate transmitted packets and thus helps to increase the target bitrate enough to make the video encoder pipeline switch up the resolution and/or frame rate.
• Based on assessment by Kiro CLI, AI-tools can generate code based on the current draft version. What is mainly missing is the handling of the transport protocol specific parts such as RTP/RTCP or QUIC.

IANA Considerations This document does not require any IANA actions.

Security Considerations The feedback can be vulnerable to attacks similar to those that can affect TCP. It is therefore RECOMMENDED that the RTCP feedback is at least integrity protected. Furthermore, as SCReAM/SCReAMv2 is self-clocked, a malicious middlebox can drop RTCP feedback packets and thus cause the self-clocking to stall. However, this attack is mitigated by the minimum send rate maintained by SCReAM/SCReAMv2 when no feedback is received.

References Normative References This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK] This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK] This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK] Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows. This document defines an Experimental Protocol for the Internet community. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput. The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance. Informative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice. This document describes web-based real-time communication use cases. Requirements on the browser functionality are derived from the use cases. This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future. This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311. When multiple congestion-controlled Real-time Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the number of changes needed to existing RTP applications. This document also specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other congestion control algorithms. The Real-time Transport Protocol (RTP) is a common transport choice for interactive multimedia communication applications. The performance of these applications typically depends on a well-functioning congestion control algorithm. To ensure a seamless and robust user experience, a well-designed RTP-based congestion control algorithm should work well across all access network types. This document describes test cases for evaluating performances of candidate congestion control algorithms over cellular and Wi-Fi networks. This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has two parts. Recent Acknowledgment (RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DupAck threshold approach. This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures. An effective RTP congestion control algorithm requires more fine-grained feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets. This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This specification defines a framework for coupling the Active Queue Management (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for the Internet to transition from the scaling problems of standard TCP-Reno-friendly ('Classic') congestion controls to the family of 'Scalable' congestion controls. These are designed for consistently very low queuing latency, very low congestion loss, and scaling of per-flow throughput by using Explicit Congestion Notification (ECN) in a modified way. Until the Coupled Dual Queue (DualQ), these Scalable L4S congestion controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification first explains how a Coupled DualQ works. It then gives the normative requirements that are necessary for it to work well. All this is independent of which two AQMs are used, but pseudocode examples of specific AQMs are given in appendices. ACM SIGCOMM Computer Communication Review IEEE Communications Letters, Vol. 17, No. 5, 3GPP TS 23.203 n.d. n.d. n.d.

Acknowledgments Zaheduzzaman Sarker is co-author of RFC 8298, the previous version of SCReAM. We would like to thank the following people for their comments, questions, and support during the work that led to this memo: Per Kjellander, Björn Terelius.

Changes in the draft versions

Working group draft submissions

Draft version -00

• Same contents as individual draft -07

Changes in Draft version -01

• New reference window scaling which acts on difference between max and min queue delay replaces earlier algorithm.
• Additional conditional loss threshold added as optional to increase robustness against non-congestion related (e.g link layer) losses.
• Added note about method to detect the extistence of rate policers and to reduce packet losses when rate policers are applied in network nodes.
• Added rate policer remediation algorithm.
• Added discussion on code generation with AI-tools based on the draft.
• Added method to reduce ref_wnd undershoot when L4S or delay based congestion occurs.

Changes in Draft version -02

• Removed rate policer remediation algorithm based on feedback at IETF-126.
• Reference window increase scaling algorithm modified for increased robustness against scheduling delay jitter.
• Delay based congestion backoff inhibited when qdelay_avg decreases.
• send_wnd calculation updated to avoid stalling when ref_wnd is very low.
• Updated calculation of ref_wnd_i.
• Restriction on ref_wnd increase when qdelay varies is applied only when ref_wnd > ref_wnd_i
• ref_wnd reduction upon congestion is applied at most every s_rtt, the scaling based on virtual_rtt is thus removed
• Superfluous backoff downscaling when L4S congestion removed

Changes in Draft version -03

• Resubmit of -02 (which was not correctly updated)

Individual draft submissions

Changes in draft version -02 Algorithm changes in draft version -02 were:

• Slow down reference window growth when close to the last known maximum value is disabled and when L4S is active. This makes SCReAM adhere more closely to two marked packets per RTT at steady state.
• Reference window decrease and increase reduced by up to 50% when ref_wnd/mss is small. This reduces rate oscillations.
• Target bitrate down adjustment when ref_wnd/mss is small is modified to avoid that the data unit queue grows excessively in certain low bitrate cases.
• Timing set to multiples of RTTs instead of seconds.

Changes in Draft version -03 Draft version -03 is a major editorial pass including removal of some outdated or background information and reorganisation of several sections:

• Much shorter abstract and introduction focusing on what's new in SCReAMv2.
• Removal of Section 1.1. on "Wireless (LTE and 5G) Access Properties" and Section 1.2. on "Why is it a self-clocked algorithm?"
• New Section on "Updates compared to SCReAM (version 1)" in introduction based on old Section on "Algorithm Changes".
• Section updated and shortened.
• Overview Section revised; now also including the overview figure and the basic algorithms.
• Old section on "Constants and variables" removed; instead all variables are now listed in the respective sections that explain the code.
• New Section on "Sender Side State" explaining some basic variables.
• Pseudo code and the corresponding explanations in Section on "Network Congestion Control" moved into the respective subsections in section on "Congestion Detection".
• Separate section on "Sender Transmission Control" introduced.
• Section "Lost Data Unit Detection" merged into Section .
• Section "Stream Prioritization" removed.
• Section on "Competing Flows Compensation" moved into Section on "Congestion Detection".

Changes in Draft version -04

• Restructuring of code.
• Reduction of target rate when bytes_in_flight is higher than ref_wnd is done also when l4s_active, replaced with requirement that queue_delay is large.
• Additional constraint for increase of ref_wnd added.
• Discussion on when it is beneficial to reduce REF_WND_OVERHEAD added.

Changes in Draft version -05 Draft version -05 contains some clarifications based on a review by Per Kjellander and Björn Terelius plus some code modifications and text.

• l4s_active state removed as delay based congestion control is always active.
• ref_wnd reduction when long time since congested limited to only limit ref_wnd to last max_bytes_in_flight_prev.
• Calculation of l4s_alpha is modified to use a fast attack slow decay EWMA filter.
• Congestion backoff downscaling also for virtual L4S marking when ref_wnd is very small.
• Congestion backoff is reduced if RTT is higher than VIRTUAL_RTT.
• ref_wnd increase is reduced if L4S is likely non-active and queue delay increases.

Changes in Draft version -06

• Correction of typos.
• Correction of send_wnd calculation.
• Additional variable qdelay_dev_norm that indicated how much the queue delay varies.
• Additional ref_wnd_overhead varable to limit how much bytes in flight can exceed the reference window in congested situations.
• REF_WND_OVERHEAD replaced by REF_WND_OVERHEAD_MIN and REF_WND_OVERHEAD_MAX.
• Reference window increase is restricted additionally when queue delay varies a lot.
• rel_framesize_high calculation is removed.
• Reduction of target bitrate when bytes in flight is high is removed because it is not helpful when media coders are sluggish.
• Calculation of l4s_alpha_v_t simplified, l4s_alpha_lim_t removed.
• Bug in condition for calculation of l4s_alpha_v_t fixed.
• bytes_in_flight_ratio removed.
• Moved Changes per draft version to this appendix.

Changes in Draft version -07

• Additional restriction of ref_wnd increase and ref_wnd_overhead when ref_wnd/MSS is very low.
• Additional compensation for increased media queue delay and frame size variation when calculating target bitrate.
• Changes in text on feedback.
• Section on handling of systematic error in media encoder output bitrate removed as this is adressed in section Media Rate Control.
• Added section Clock drift issues and remedies.
• Removed '*= max(0.5,1.0-ref_wnd_ratio)' as this function is replaced by qdelay_dev_norm related restriction on reference window growth.
• Removed extra selective restriction on ref_wnd growth when L4S is not enabled as this function is replaced by qdelay_dev_norm related restriction on reference window growth.
• Additional wording on the improvement of the optional qdelay_dev_norm related restriction based on extimation of the non-congestion related delay jitter.