Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8298

Self-Clocked Rate Adaptation for Multimedia

Pages: 36
Part 1 of 2 – Pages 1 to 14
None   None   Next

Top   ToC   RFC8298 - Page 1
Internet Engineering Task Force (IETF)                      I. Johansson
Request for Comments: 8298                                     Z. Sarker
Category: Experimental                                       Ericsson AB
ISSN: 2070-1721                                            December 2017

              Self-Clocked Rate Adaptation for Multimedia


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. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at
Top   ToC   RFC8298 - Page 2
Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
Top   ToC   RFC8298 - Page 3

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Wireless (LTE) Access Properties . . . . . . . . . . . . 4 1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 6 3.1. Network Congestion Control . . . . . . . . . . . . . . . 8 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 9 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 9 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 10 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Constants and Parameter Values . . . . . . . . . . . 10 Constants . . . . . . . . . . . . . . . . . . . . 11 State Variables . . . . . . . . . . . . . . . . . 12 4.1.2. Network Congestion Control . . . . . . . . . . . . . 14 Reaction to Packet Loss and ECN . . . . . . . . . 17 Congestion Window Update . . . . . . . . . . . . 17 Competing Flows Compensation . . . . . . . . . . 20 Lost Packet Detection . . . . . . . . . . . . . . 22 Send Window Calculation . . . . . . . . . . . . . 23 Packet Pacing . . . . . . . . . . . . . . . . . . 24 Resuming Fast Increase Mode . . . . . . . . . . . 24 Stream Prioritization . . . . . . . . . . . . . . 24 4.1.3. Media Rate Control . . . . . . . . . . . . . . . . . 25 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 28 4.2.1. Requirements on Feedback Elements . . . . . . . . . . 28 4.2.2. Requirements on Feedback Intensity . . . . . . . . . 30 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.1. Normative References . . . . . . . . . . . . . . . . . . 33 9.2. Informative References . . . . . . . . . . . . . . . . . 34 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
Top   ToC   RFC8298 - Page 4

1. Introduction

Congestion in the Internet occurs when the transmitted bitrate is higher than the available capacity over a given transmission path. Applications that are deployed in the Internet have to employ congestion control to achieve robust performance and to avoid congestion collapse in the Internet. Interactive real-time communication imposes a lot of requirements on the transport; therefore, a robust, efficient rate adaptation for all access types is an important part of interactive real-time communications, as the transmission channel bandwidth can vary over time. Wireless access such as LTE, which is an integral part of the current Internet, increases the importance of rate adaptation as the channel bandwidth of a default LTE bearer [QoS-3GPP] can change considerably in a very short time frame. Thus, a rate adaptation solution for interactive real-time media, such as WebRTC [RFC7478], should be both quick and be able to operate over a large range in channel capacity. This memo describes Self-Clocked Rate Adaptation for Multimedia (SCReAM), a solution that implements congestion control for RTP streams [RFC3550]. While SCReAM was originally devised for WebRTC, it can also be used for other applications where congestion control of RTP streams is necessary. SCReAM is based on the self-clocking principle of TCP and uses techniques similar to what is used in the rate adaptation algorithm based on Low Extra Delay Background Transport (LEDBAT) [RFC6817]. SCReAM is not entirely self-clocked as it augments self-clocking with pacing and a minimum send rate. SCReAM can take advantage of Explicit Congestion Notification (ECN) in cases where ECN is supported by the network and the hosts. However, ECN is not required for the basic congestion control functionality in SCReAM.

1.1. Wireless (LTE) Access Properties

[WIRELESS-TESTS] describes the complications that can be observed in wireless environments. Wireless access such as LTE 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 LTE can support bitrates well above 100 Mbps, there are cases when the available bitrate can be much lower; 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 not possible to try to maintain a given bitrate when congestion is detected with the hope that other flows will yield. This is because
Top   ToC   RFC8298 - Page 5
   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 (which is using RTP Media Congestion
   Avoidance Techniques (RMCAT)) in that bearer aims to reduce the
   sending rate quite quickly (within one RTT) in order to avoid
   excessive queuing delay or packet loss.

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

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Top   ToC   RFC8298 - Page 6

3. Overview of SCReAM Algorithm

The core SCReAM algorithm 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]. In SCReAM, the receiver of the media echoes a list of received RTP packets and the timestamp of the RTP packet with the highest sequence number back to the sender in feedback packets. 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 congestion window puts an upper limit on how many bytes can be in flight, i.e., transmitted but not yet acknowledged. The congestion window is determined in a way similar to 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 use of LEDBAT ensures that the end-to-end latency is kept low. [LEDBAT-delay-impact] shows that LEDBAT has certain inherent issues that make it counteract its purpose of achieving low delay. 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 RTP 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 is used with 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 RTP queue; in turn, this results in a reduced media video bitrate. Thus, SCReAM slows
Top   ToC   RFC8298 - Page 7
   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:

   o  Congestion window validation techniques.  These are similar to the
      method described in [RFC7661].  Congestion window validation
      ensures that the congestion window is limited by the actual number
      bytes in flight; this is important especially in the context of
      rate-limited sources such as video.  Lack of congestion window
      validation would lead to a slow reaction to congestion as the
      congestion window does not properly reflect the congestion state
      in the network.  The allowed idle period in this memo is shorter
      than in [RFC7661]; this to avoid excessive delays in the cases
      where, e.g., wireless throughput has decreased during a period
      where the output bitrate from the media coder has been low (for
      instance, due to inactivity).  Furthermore, this memo allows for
      more relaxed rules for when the congestion window is allowed to
      grow; this is necessary as the variable output bitrate generally
      means that the congestion window is often underutilized.

   o  Fast increase mode makes the bitrate increase faster when no
      congestion is detected.  It makes the media bitrate ramp up within
      5 to 10 seconds.  The behavior is similar to TCP slowstart.  Fast
      increase mode is exited when congestion is detected.  However,
      fast increase mode can resume if the congestion level is low; this
      enables a reasonably quick rate increase in case link throughput

   o  A qdelay trend is computed for earlier detection of incipient
      congestion; as a result, it reduces jitter.

   o  Addition of a media rate control function.

   o  Use of inflection points in the media rate calculation to achieve
      reduced jitter.

   o  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
   Sections 3.1 to 3.3.  The full details are described in Section 4.
Top   ToC   RFC8298 - Page 8
                    |        Media encoder      |
                        ^                  |
                        |                  |(1)
                        |(3)              RTP
                        |                  V
                        |            +-----------+
                   +---------+       |           |
                   | Media   |  (2)  |   Queue   |
                   | rate    |<------|           |
                   | control |       |RTP packets|
                   +---------+       |           |
              +------------+       +--------------+
              |  Network   |  (7)  |    Sender    |
          +-->| congestion |------>| Transmission |
          |   |  control   |       |   Control    |
          |   +------------+       +--------------+
          |                                |
          |-------------RTCP----------|    |(5)
              (6)                     |   RTP
                                      |    v
                                  |     UDP    |
                                  |   socket   |

                  Figure 1: SCReAM Sender Functional View

   The SCReAM algorithm consists of three main parts: network congestion
   control, sender transmission control, and media rate control.  All of
   these parts reside at the sender side.  Figure 1 shows the functional
   overview of a SCReAM sender.  The receiver-side algorithm is very
   simple in comparison, as it only generates feedback containing
   acknowledgements of received RTP packets and an ECN count.

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 CWND (congestion window) and is used in the sender transmission control.
Top   ToC   RFC8298 - Page 9
   The SCReAM 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 congestion
   control algorithm due to incorrect estimation of the network queue

   The SCReAM sender calculates the congestion window based on the
   feedback from the SCReAM receiver.  The congestion window is allowed
   to increase if the qdelay is below a predefined qdelay target;
   otherwise, the congestion window decreases.  The qdelay target is
   typically set to 50-100 ms.  This ensures that the queuing delay is
   kept low.  The reaction to loss or ECN events leads to an instant
   reduction of CWND.  Note that the source rate-limited nature of real-
   time media, such as video, typically means that the queuing delay
   will mostly be below the given delay target.  This is contrary to the
   case where large files are transmitted using LEDBAT congestion
   control and the queuing delay will stay close to the delay target.

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

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 RTP packet queue(s) in the sender. The media bitrate is decreased if the RTP queue size exceeds a threshold. In cases where the sender's frame queues increase rapidly, such as in the case of a Radio Access Type (RAT) handover, the SCReAM sender MAY implement additional actions, such as discarding of encoded media
Top   ToC   RFC8298 - Page 10
   frames or frame skipping in order to ensure that the RTP 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. Detailed Description of SCReAM

4.1. SCReAM Sender

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. A SCReAM sender implements media rate control and an RTP queue for each media type or source, where RTP packets containing encoded media frames are temporarily stored for transmission. Figure 1 shows the details when a single media source (or stream) is used. A transmission scheduler (not shown in the figure) is added to support multiple streams. The transmission scheduler can enforce differing priorities between the streams and act like a coupled congestion controller for multiple flows. Support for multiple streams is implemented in [SCReAM-CPP-implementation]. Media frames are encoded and forwarded to the RTP queue (1) in Figure 1. The media rate adaptation adapts to the size of the RTP queue (2) and provides a target rate for the media encoder (3). The RTP packets are picked from the RTP queue (4), for multiple flows from each RTP queue based on some defined priority order or simply in a round-robin fashion, by the sender transmission controller. The sender transmission controller (in case of multiple flows a transmission scheduler) sends the RTP packets to the UDP socket (5). In the general case, all media SHOULD go through the sender transmission controller and is limited so that the number of bytes in flight is less than the congestion window. RTCP packets are received (6) and the information about the bytes in flight and congestion window is exchanged between the network congestion control and the sender transmission control (7).

4.1.1. Constants and Parameter Values

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.
Top   ToC   RFC8298 - Page 11 Constants
The RECOMMENDED values, within parentheses "()", for the constants are deduced from experiments. QDELAY_TARGET_LO (0.1 s) Target value for the minimum qdelay. QDELAY_TARGET_HI (0.4 s) Target value for the maximum qdelay. 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. QDELAY_WEIGHT (0.1) Averaging factor for qdelay_fraction_avg. QDELAY_TREND_TH (0.2) Threshold for the detection of incipient congestion. MIN_CWND (3000 bytes) Minimum congestion window. MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1) Headroom for the limitation of CWND. GAIN (1.0) Gain factor for congestion window adjustment. BETA_LOSS (0.8) CWND scale factor due to loss event. BETA_ECN (0.9) CWND scale factor due to ECN event. BETA_R (0.9) Scale factor for target rate due to loss event. MSS (1000 byte) Maximum segment size = Max RTP packet size. RATE_ADJUST_INTERVAL (0.2 s) Interval between media bitrate adjustments. TARGET_BITRATE_MIN Minimum target bitrate in bps (bits per second).
Top   ToC   RFC8298 - Page 12
     Maximum target bitrate in bps.

   RAMP_UP_SPEED (200000 bps/s)
     Maximum allowed rate increase speed.

     Guard factor against early congestion onset.  A higher value gives
     less jitter, possibly at the expense of a lower link utilization.
     This value MAY be subject to tuning depending on e.g., media coder
     characteristics.  Experiments with H264 and VP8 indicate that 0.1
     is a suitable value.  See [SCReAM-CPP-implementation] and
     [SCReAM-implementation-experience] for evaluation of a real

   TX_QUEUE_SIZE_FACTOR (0.0..2.0)
     Guard factor against RTP queue buildup.  This value MAY be subject
     to tuning depending on, e.g., media coder characteristics.
     Experiments with H264 and VP8 indicate that 1.0 is a suitable
     value.  See [SCReAM-CPP-implementation] and
     [SCReAM-implementation-experience] for evaluation of a real

   RTP_QDELAY_TH (0.02 s)  RTP queue delay threshold for a target rate

   TARGET_RATE_SCALE_RTP_QDELAY (0.95)  Scale factor for target rate
     when RTP qdelay threshold exceeds RTP_QDELAY_TH.

   QDELAY_TREND_LO (0.2)  Threshold value for qdelay_trend.

   T_RESUME_FAST_INCREASE (5 s)  Time span until fast increase mode can
     be resumed, given that the qdelay_trend is below QDELAY_TREND_LO.

   RATE_PACE_MIN (50000 bps)  Minimum pacing rate. State Variables
The values within parentheses "()" indicate initial values. qdelay_target (QDELAY_TARGET_LO) qdelay target, a variable qdelay target is introduced to manage cases where a fixed qdelay target would otherwise starve the RMCAT 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.
Top   ToC   RFC8298 - Page 13
   qdelay_fraction_avg (0.0)
     Fractional qdelay filtered by the Exponentially Weighted Moving
     Average (EWMA).

   qdelay_fraction_hist[20] ({0,..,0})
     Vector of the last 20 fractional qdelay samples.

   qdelay_trend (0.0)
     qdelay trend; indicates incipient congestion.

   qdelay_trend_mem (0.0)
     Low-pass filtered version of qdelay_trend.

   qdelay_norm_hist[100] ({0,..,0})
     Vector of the last 100 normalized qdelay samples.

   in_fast_increase (true)
     True if in fast increase mode.

   cwnd (MIN_CWND)
     Congestion window.

   bytes_newly_acked (0)
     The number of bytes that was acknowledged with the last received
     acknowledgement, i.e., bytes acknowledged since the last CWND

   max_bytes_in_flight (0)
     The maximum number of bytes in flight over a sliding time window,
     i.e., transmitted but not yet acknowledged bytes.

   send_wnd (0)
     Upper limit to how many bytes can currently be transmitted.
     Updated when cwnd is updated and when RTP packet is transmitted.

   target_bitrate (0 bps)
     Media target bitrate.

   target_bitrate_last_max (1 bps)
     Inflection point of the media target bitrate, i.e., the last known
     highest target_bitrate.  Used to limit bitrate increase speed close
     to the last known congestion point.

   rate_transmit (0.0 bps)
     Measured transmit bitrate.

   rate_ack (0.0 bps)
     Measured throughput based on received acknowledgements.
Top   ToC   RFC8298 - Page 14
   rate_media (0.0 bps)
     Measured bitrate from the media encoder.

   rate_media_median (0.0 bps)
     Median value of rate_media, computed over more than 10 s.

   s_rtt (0.0s)
     Smoothed RTT (in seconds), computed with a similar method to that
     described in [RFC6298].

   rtp_queue_size (0 bits)
     Sum of the sizes of RTP packets in queue.

   rtp_size (0 byte)
     Size of the last transmitted RTP packet.

   loss_event_rate (0.0)
     The estimated fraction of RTTs with lost packets detected.

(page 14 continued on part 2)

Next Section