Self-Clocked Rate Adaptation for Multimedia

1.1. Wireless (LTE and 5G) Access Properties

[RFC8869] describes the complications that can be observed in wireless environments. Wireless access such as LTE and 5G typically cannot guarantee a given bandwidth; this is true especially for default bearers. The network throughput can vary considerably, for instance, in cases where the wireless terminal is moving around. Even though 5G can support bitrates above 1 Gbps, there are cases when the available bitrate can be much lower (less than 10 Mbps); examples are situations with high network load and poor coverage. An additional complication is that the network throughput can drop for short time intervals (e.g., at handover); these short glitches are initially very difficult to distinguish from more permanent reductions in throughput.¶

Unlike wireline bottlenecks with large statistical multiplexing, it is typically not possible to try to maintain a given bitrate when congestion is detected with the hope that other flows will yield. This is because there are generally few other flows competing for the same bottleneck. Each user gets its own variable throughput bottleneck, where the throughput depends on factors like channel quality, network load, and historical throughput. The bottom line is, if the throughput drops, the sender has no other option than to reduce the bitrate. Once the radio scheduler has reduced the resource allocation for a bearer, a flow in that bearer aims to reduce the sending rate quite quickly (within one RTT) in order to avoid excessive queuing delay or packet loss. This has the consenquence that L4S capable 5G radio bearers will build a queue unless these are prioritized over other bearers. This differs from e.g DualQ [RFC9332], which prioritizes L4S traffic in a weighted scheduler and achives fairness with additional marking for the L4S flows.¶

1.2. Why is it a self-clocked algorithm?

Self-clocked congestion control algorithms provide a benefit over their rate-based counterparts in that the former consists of two adaptation mechanisms:¶

• A reference window computation that evolves over a longer timescale (several RTTs) especially when the reference window evolution is dictated by estimated delay (to minimize vulnerability to, e.g., short-term delay variations). 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.¶

• A fine-grained congestion control given by the self-clocking; it operates on a shorter time scale (1 RTT). The benefits of self-clocking are also elaborated upon in [TFWC]. The self-clocking however 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.¶

A rate-based congestion control algorithm typically adjusts the rate based on delay and loss. The congestion detection needs to be done with a certain time lag to avoid overreaction to spurious congestion events such as delay spikes. Despite the fact that there are two or more congestion indications, the outcome is that there is still only one mechanism to adjust the sending rate. This makes it difficult to reach the goals of high throughput and prompt reaction to congestion.¶

1.3. Requirements on media and feedback protocol

SCReAM was originally designed to with with RTP + RTCP where [RFC8888] was used as recommended feedback. RTP offers unique packet indication with the sequence number and [RFC8888] 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 [RFC9000] is sufficient.¶

1.4. 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 [TFWC] and follows the packet conservation principle. The packet conservation principle is described as a key factor behind the protection of networks from congestion [Packet-conservation].¶

The reference window is determined in a way similar to the congestion window in LEDBAT [RFC6817]. LEDBAT is a congestion control algorithm that uses send and receive timestamps to estimate the queuing delay (from now on denoted "qdelay") along the transmission path. This information is used to adjust the congestion window. The general problem described in the paper is that the base delay is offset by LEDBAT's own queue buildup. The big difference with using LEDBAT in the SCReAM context lies in the facts that the source is rate limited and that the data unit queue must be kept short (preferably empty). In addition, the output from a video encoder is rarely constant bitrate; static content (talking heads, for instance) gives almost zero video bitrate. This yields two useful properties when LEDBAT's delay-based rate estimation techniques are used as part of SCReAM; they help to avoid the issues described in [LEDBAT-delay-impact]:¶

1. There is always a certain probability that SCReAM is short of data to transmit; this means that the network queue will become empty every once in a while.¶

2. The max video bitrate can be lower than the link capacity. If the max video bitrate is 5 Mbps and the capacity is 10 Mbps, then the network queue will become empty.¶

It is sufficient that any of the two conditions above is fulfilled to make the base delay update properly. Furthermore, [LEDBAT-delay-impact] describes an issue with short-lived competing flows. In SCReAM, these short-lived flows will cause the self-clocking to slow down, thereby building up the data unit queue; in turn, this results in a reduced media video bitrate. Thus, SCReAM slows the bitrate more when there are competing short-lived flows than the traditional use of LEDBAT does. The basic functionality in the use of LEDBAT in SCReAM is quite simple; however, there are a few steps in order to make the concept work with conversational media:¶

• Addition of a media rate control function.¶

• Reference window validation techniques. 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 max target bitrate is reached.¶

• Use of inflection points in the reference window calculation to achieve reduced delay jitter.¶

• Adjustment of qdelay target for better performance when competing with other loss-based congestion-controlled flows.¶

The above-mentioned features will be described in more detail in Section Section 4.¶

The SCReAM/SCReAMv2 congestion control method uses techniques similar to LEDBAT [RFC6817] 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 [RFC8888] as feedback ensures that the same time base is used in sender and receiver.¶

3.1. Network Congestion Control

The network congestion control sets an upper limit on how much data can be in the network (bytes in flight); this limit is called reference window (ref_wnd) and is used in the sender transmission control.¶

The sender calculates the reference window based on the feedback from the data receiver. The feedback from the receiver is timestamp and individual data units or group of data units and ECN status per data unit or an accumulated ECN-CE count. The sender keeps a list of transmitted packets, their respective sizes, and the time they were transmitted. This information is used to determine the number of bytes that can be transmitted at any given time instant. A reference window 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 a slack is given to efficiently transmit temporary larger media objects, such as video frames.¶

The reference window seeks to increase by one segment per RTT and this increase regardless congestion occurs or not, the reference window increase is restriced or relaxed based on the current value of the reference window relative to a previous max value and the time elapsed since last congestion event. The reference window update is increased by one MSS (maximum known data unit size) per RTT with some variation based on reference window size and time elapsed since the last congestion event. Multiplicative increase allows the congestion to increase by a fraction of ref_wnd when congestion has not occured for a while. The reference window is thus an adaptive multiplicative increase that is mainly additive increase when steady state is reached but allows a faster convergence to a higher link speed.¶

Reference window reduction is triggered by:¶

• Packet loss or Classic ECN marking is detected : The reference window is reduced by a predetermined fraction.¶

• Estimated queue delay exceeds a given threshold : The reference window is reduced given by how much the delay exceeds the threshold.¶

• L4S ECN marking detected : The reference window is reduced in proportion to the fraction of packets that are marked (scalable congestion control).¶

3.2. Sender Transmission Control

The sender transmission control limits the output of data, given by the relation between the number of bytes in flight and the reference window. The congestion window is however not a hard limit, additional slack is given to avoid that data units are queued up unnecessarily on the sender side. This means that the algoritm 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. Packet pacing is used to mitigate issues with ACK compression that MAY cause increased jitter and/or packet loss in the media traffic. Packet pacing limits the packet transmission rate given by the estimated link throughput. 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.¶

3.3. Media Rate Control

The media rate control serves to adjust the media bitrate to ramp up quickly enough to get a fair share of the system resources when link throughput increases.¶

The reaction to reduced throughput must be prompt in order to avoid getting too much data queued in the data unit queue(s) in the sender. The media rate is calculated based on the reference window and RTT. For the case that multiple streams are enabled, the media rate among the streams is distrubuted 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 in order 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.¶

4.1. Constants and variables

Constants and state variables are listed in this section. Temporary variables are not listed; instead, they are appended with '_t' in the pseudocode to indicate their local scope.¶

4.2. Network Congestion Control

This section explains the network congestion control, which performs two main functions:¶

• Computation of reference window at the sender: This gives an upper limit to the number of bytes in flight.¶

• Calculation 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.¶

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.¶

The number of bytes in flight (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. This can be translated to 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.¶

bytes_in_flight_ratio is calculated as the ratio between bytes_flight and ref_wnd. This value should be computed at the beginning of the ACK processing. ref_wnd_ratio is computed as the relation between MSS and ref_wnd.¶

Furthermore, a variable 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.¶

The feedback from the receiver is assumed to consist of the following elements.¶

• A list of received data units' sequence numbers. With 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.¶

• The wall-clock timestamp corresponding to the received data unit with the highest sequence number.¶

When the sender receives RTCP feedback, the qdelay is calculated as outlined in [RFC6817]. A qdelay sample is obtained for each received acknowledgement. A number of variables are updated as illustrated by the pseudocode below; temporary variables are appended with '_t'. Division operation is always floating point unless otherwise noted. l4s_alpha is calculated based in number of data units delivered (and marked). 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 smoothed RTT (s_rtt) is computed in a way similar to [RFC6298].¶

data_units_delivered_this_rtt += data_units_acked
data_units_marked_this_rtt += data_units_acked_ce
# l4s_alpha is updated at least every 10ms
if (now - last_update_l4s_alpha_time >= 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

  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

if (now - last_update_qdelay_avg_time >= s_rtt)
  # qdelay_avg is updated with a slow attack, fast decay EWMA filter
  if (qdelay < qdelay_avg)
    qdelay_avg = qdelay
  else
    qdelay_avg = QDELAY_AVG_G*qdelay + (1.0-QDELAY_AVG_G)*qdelay_avg
  end
  last_update_qdelay_avg_time = now
end

# The reference window is updated at least every VIRTUAL_RTT
if (now - last_congestion_detected_time >= min(VIRTUAL_RTT,s_rtt)
  if (loss detected)
    is_loss_t = true
  end
  if (data units marked)
    is_ce_t = true
  end
  if (qdelay > qdelay_target/2)
    # It is expected that l4s_alpha is below a given value,
    l4_alpha_lim_t = 2 / target_bitrate * MSS * 8 / s_rtt
    if (l4s_alpha < l4_alpha_lim_t || !l4s_active)
      # L4S does not seem to be active
      l4s_alpha_v_t = min(1.0, max(0.0,
         (qdelay_avg - qdelay_target / 2) /
         (qdelay_target / 2)));
      is_virtual_ce_t = true
    end
  end
end

if (is_loss_t || is_ce_t || is_virtual_ce_t)
  if (now - last_ref_wnd_i_update_time > 10*s_rtt)
    # Update ref_wnd_i, no more often than every 10 RTTs
    # Additional median filtering over more congestion epochs
    # may improve accuracy of ref_wnd_i
    last_ref_wnd_i_update_time = now
    ref_wnd_i = ref_wnd
  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

    # Increase stability for very small ref_wnd
    backOff_t *= max(0.5, 1.0 - ref_wnd_ratio)

    if (now - last_congestion_detected_time >
        100*max(VIRTUAL_RTT,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)

      # Also, we back off a little extra if needed
      # because alpha is quite likely very low
      # This can in some cases be an over-reaction
      # but as this function should kick in relatively seldom
      # it should not be to too big concern
      backoff_t = max(backoff_t, 0.25)

      # In addition, bump up l4sAlpha to a more credible value
      # This may over react but it is better than
      # excessive queue delay
      l4sAlpha = 0.25
    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)

if (is_loss_t || is_ce_t || is_virtual_ce_t)
  last_congestion_detected_time = now
end

# Delay factor for multiplicative reference window increase
# after congestion

post_congestion_scale_t = max(0.0, min(1.0,
 (now - last_congestion_detected_time) /
  (POST_CONGESTION_DELAY_RTTS * max(VIRTUAL_RTT, s_rtt))))

# Scale factor for ref_wnd update
ref_wnd_scale_factor_t = 1.0 + (MUL_INCREASE_FACTOR  * ref_wnd) / MSS)


# Calculate bytes acked that are not CE marked
# For the case that only accumulated number of CE marked packets is
# reported by the feedback, it is necessary to make an approximation
# of bytes_newly_acked_ce based on average data unit size.
bytes_newly_acked_minus_ce_t = bytes_newly_acked-
                               bytes_newly_acked_ce

increment_t = bytes_newly_acked_minus_ce_t*ref_wnd_ratio

# Reduce increment for small RTTs
tmp_t = min(1.0, s_rtt / VIRTUAL_RTT)
increment_t *= tmp_t * tmp_t

# Apply limit to reference window growth when close to last
# known max value before congestion
scl_t = (ref_wnd-ref_wnd_i) / ref_wnd_i
scl_t *= 4
scl_t = scl_t * scl_t
scl_t = max(0.1, min(1.0, scl_t))
if (!is_l4s_active)
  increment_t *= scl_t
end

# Limit on CWND growth speed further for small CWND
# This is complemented with a corresponding restriction on CWND
# reduction
increment_t *= max(0.5,1.0-ref_wnd_ratio)

# Scale up increment with multiplicative increase
# Limit multiplicative increase when congestion occured
# recently and when reference window is close to the last
# known max value
float tmp_t = ref_wnd_scale_factor_t
if (tmp_t > 1.0)
  tmp_t = 1.0 + (tmp_t - 1.0) * post_congestion_scale_t * scl_t;
end
increment *= tmp_t

# 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.
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)
  ref_wnd = ref_wnd_t
end

send_wnd = ref_wnd * REF_WND_OVERHEAD * rel_framesize_high -
           bytes_in_flight

# frame_size is that frame size for the last encoded frame
tmp_t = frame_size / (target_bitrate * frame_period / 8)

if (tmp_t > 1.0)
  # Insert sample into histogram
  insert_into_histogram(tmp_t)
  # Get high percentile
  rel_framesize_high = get_histogram_high_percentile()
end

pace_bitrate = max(RATE_PACE_MIN, target_bitrate) *
               PACKET_PACING_HEADROOM
t_pace = data_unit_size * 8 / pace_bitrate

4.3. Media Rate Control

The media rate control algorithm is executed whenever the reference window is updated and updates the target bitrate. The target bitrate is essentiatlly based on the reference window and the (smoothed) RTT according to¶

target_bitrate = 8 * ref_wnd / s_rtt

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¶

• L4S is inactive, i.e L4S is either not enabled or congested bottlenecks do not L4S mark data units¶

• ref_wnd is very small, just a few MSS or smaller¶

The complete pseudo code for adjustment of the target bitrate is shown below¶

tmp_t = 1.0

# limit bitrate if bytes in flight exceeds is close to or
# exceeds ref_wnd. This helps to avoid large rate fluctiations and
# variations in RTT
# Only applied when L4S is inactive
if (!l4s_active && bytes_in_flight_ratio > BYTES_IN_FLIGHT_LIMIT)
  tmp_t /= min(BYTES_IN_FLIGHT_LIMIT_COMPENSATION,
    bytesInFlightRatio / BYTES_IN_FLIGHT_LIMIT)
end

# Scale down rate slighty when the reference window is very
# small compared to MSS
tmp_t *= 1.0 - min(0.2, max(0.0, ref_wnd_ratio - 0.1))

# Additional compensation for packetization overhead,
# important when MSS is small
tmp_t_ *= mss/(mss + PACKET_OVERHEAD)

# Calculate target bitrate and limit to min and max allowed
# values
target_bitrate = tmp_t * 8 * ref_wnd / s_rtt
target_bitrate = min(TARGET_BITRATE_MAX,
  max(TARGET_BITRATE_MIN,target_bitrate))

4.4. 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 pseudocode below.¶

adjust_qdelay_target(qdelay)
  qdelay_norm_t = qdelay / QDELAY_TARGET_LOW
  update_qdelay_norm_history(qdelay_norm_t)
  # Compute variance
  qdelay_norm_var_t = VARIANCE(qdelay_norm_history(200))
  # Compensation for competing traffic
  # Compute average
  qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50))
  # Compute upper limit to target delay
  new_target_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t)
  new_target_t *= QDELAY_TARGET_LO
  if (loss_event_rate > 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)

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.¶

4.5. Handling of systematic errors in video coders

Some video encoders are prone to systematically generate an output bitrate that is systematically larger or smaller than the target bitrate. SCReAMv2 can handle some deviation inherently but for larger devation it becomes necessary to compensate for this. The algorithm for this is detailed in [SCReAM-CPP-implementation].¶

ToDo: A future draft version will describe this in more detail as it has been fully integrated into SCReAMv2.¶

10.1. Normative References

[RFC3168]

Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3550]

Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[RFC4585]

Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.

[RFC5506]

Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <https://www.rfc-editor.org/info/rfc5506>.

[RFC6298]

Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.

[RFC6817]

Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <https://www.rfc-editor.org/info/rfc6817>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9330]

Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. White, "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture", RFC 9330, DOI 10.17487/RFC9330, January 2023, <https://www.rfc-editor.org/info/rfc9330>.

10.2. Informative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC7478]

Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <https://www.rfc-editor.org/info/rfc7478>.

[RFC8298]

Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 2017, <https://www.rfc-editor.org/info/rfc8298>.

[RFC8511]

Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "TCP Alternative Backoff with ECN (ABE)", RFC 8511, DOI 10.17487/RFC8511, December 2018, <https://www.rfc-editor.org/info/rfc8511>.

[RFC8699]

Islam, S., Welzl, M., and S. Gjessing, "Coupled Congestion Control for RTP Media", RFC 8699, DOI 10.17487/RFC8699, January 2020, <https://www.rfc-editor.org/info/rfc8699>.

[RFC8869]

Sarker, Z., Zhu, X., and J. Fu, "Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks", RFC 8869, DOI 10.17487/RFC8869, January 2021, <https://www.rfc-editor.org/info/rfc8869>.

[RFC8985]

Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The RACK-TLP Loss Detection Algorithm for TCP", RFC 8985, DOI 10.17487/RFC8985, February 2021, <https://www.rfc-editor.org/info/rfc8985>.

[RFC8257]

Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, "Data Center TCP (DCTCP): TCP Congestion Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, October 2017, <https://www.rfc-editor.org/info/rfc8257>.

[RFC8888]

Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP Control Protocol (RTCP) Feedback for Congestion Control", RFC 8888, DOI 10.17487/RFC8888, January 2021, <https://www.rfc-editor.org/info/rfc8888>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC9332]

De Schepper, K., Briscoe, B., Ed., and G. White, "Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9332, DOI 10.17487/RFC9332, January 2023, <https://www.rfc-editor.org/info/rfc9332>.

[Packet-conservation]

Jacobson, V., "Congestion Avoidance and Control", ACM SIGCOMM Computer Communication Review, DOI 10.1145/52325.52356, August 1988, <https://doi.org/10.1145/52325.52356>.

[LEDBAT-delay-impact]

Ros, D. and M. Welzl, "Assessing LEDBAT's Delay Impact", IEEE Communications Letters, Vol. 17, No. 5,, DOI 10.1109/LCOMM.2013.040213.130137, May 2013, <http://home.ifi.uio.no/michawe/research/publications/ledbat-impact-letters.pdf>.

[QoS-3GPP]

"Policy and charging control architecture", 3GPP TS 23.203, July 2017, <http://www.3gpp.org/ftp/specs/archive/23_series/23.203/>.

[SCReAM-CPP-implementation]

Ericsson Research, "SCReAM - Mobile optimised congestion control algorithm", n.d., <https://github.com/EricssonResearch/scream>.

[SCReAM-evaluation-L4S]

Ericsson Research, "SCReAM - evaluations with L4S", n.d., <https://github.com/EricssonResearch/scream/blob/master/L4S-Results.pdf?raw=true>.

[TFWC]

Choi, S. and M. Handley, "Fairer TCP-Friendly Congestion Control Protocol for Multimedia Streaming Applications", DOI 10.1145/1364654.1364717, December 2007, <http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/tfwc-conext.pdf>.