RMCAT WG I. Johansson Internet-Draft Z. Sarker Intended status: Experimental Ericsson AB Expires: April 21, 2016 October 19, 2015 Self-Clocked Rate Adaptation for Multimedia draft-ietf-rmcat-scream-cc-02 Abstract This memo describes a rate adaptation algorithm for conversational media services such as 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 LTE (Long Term Evolution) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 21, 2016. Copyright Notice Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) 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 Johansson & Sarker Expires April 21, 2016 [Page 1] Internet-Draft SCReAM October 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4 3.1. Network Congestion Control . . . . . . . . . . . . . . . 7 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 7 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 7 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 8 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Constants and Parameter values . . . . . . . . . . . 8 4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 8 4.1.1.2. State variables . . . . . . . . . . . . . . . . . 10 4.1.2. Network congestion control . . . . . . . . . . . . . 11 4.1.2.1. Updating bytes_newly_acked . . . . . . . . . . . 14 4.1.2.2. Updating congestion window . . . . . . . . . . . 14 4.1.2.3. Compensation for competing flows . . . . . . . . 16 4.1.2.4. Send window calculation . . . . . . . . . . . . . 17 4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 18 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 18 4.1.3.1. FEC and packet overhead considerations . . . . . 22 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 22 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Implementation status . . . . . . . . . . . . . . . . . . . . 23 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 23 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 24 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Change history . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Additional features . . . . . . . . . . . . . . . . 28 A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 28 A.2. Computation of autocorrelation function . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Johansson & Sarker Expires April 21, 2016 [Page 2] Internet-Draft SCReAM October 2015 1. Introduction Congestion in the Internet is a reality and applications that are deployed in the Internet must have congestion control schemes in place not only for the robustness of the service that it provides but also to ensure the function of the currently deployed Internet. As the interactive realtime communication imposes a great deal of requirements on the transport, a robust, efficient rate adaptation for all access types is considered as an important part of interactive realtime communications as the transmission channel bandwidth may 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 realtime media, such as WebRTC, must be both quick and be able to operate over a large span in available channel bandwidth. This memo describes a solution,named SCReAM, that is based on the self-clocking principle of TCP and uses techniques similar to what is used in a new delay based rate adaptation algorithm, LEDBAT [RFC6817]. 1.1. Wireless (LTE) access properties [I-D.ietf-rmcat-wireless-tests] describes the complications that can be observed in wireless environments. Wireless access such as LTE can typically not guarantee a given bandwidth, this is true especially for default bearers. The network throughput may vary considerably for instance in cases where the wireless terminal is moving around. 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 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. In addition, the grace time, i.e. allowed reaction time from the time that the congestion is detected until a reaction in terms of a rate reduction is effected, is generally very short, in the order of one RTT (Round Trip Time). 1.2. Why is it a self-clocked algorithm? Self-clocked congestion control algorithm provides with a benefit over the rate based counterparts in that the former consists of two parts; the congestion window computation that evolves over a longer Johansson & Sarker Expires April 21, 2016 [Page 3] Internet-Draft SCReAM October 2015 timescale (several RTTs) especially when the congestion window evolution is dictated by estimated delay and; the fine grained congestion control given by the self-clocking which operates on a shorter time scale (1 RTT). A rate based congestion control has only one mechanism to adjust the sending rate and that makes it more problematic to reach the goal of prompt reaction to congestion and also high throughput when channel conditions are good. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119] 3. Overview of SCReAM Algorithm The core SCReAM algorithm has similarities to the concepts of self- clocking used in TFWC [TFWC] and follows the packet conservation principle. The packet conservation principle is described as an important key-factor behind the protection of networks from congestion [PACKET_CONSERVATION]. In case of SCReAM, the receiver of the media sends the highest received sequence number back to the sender, the sender keeps a list of transmitted packets and their respective sizes. This information is then used to determine the amount of bytes 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. This is how the packet conservation principle is realized. 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 along the transmission path. The use of LEDBAT ensures that the e2e latency is kept low. The basic functionality is quite simple, there are however a few steps to take to make the concept work with conversational media. In a few words they are: o Congestion window validation techniques. These are similar in action as the method described in [I-D.ietf-tcpm-newcwv]. The allowed idle period in this draft is shorter than in the reference, this to avoid excessive delays in the cases where e.g. wireless throughput has decreased during a period where the output bitrate has been low. Furthermore, this draft allows for more relaxed rules when the congestion window is allowed to grow, this Johansson & Sarker Expires April 21, 2016 [Page 4] Internet-Draft SCReAM October 2015 is necessary as the variable output bitrate generally means that the congestion window is often under-utilized. o Fast increase for quicker bitrate increase. It makes the media bitrate ramp-up within 5 to 10 seconds. The behavior is similar to TCP slowstart. The fast increase is exited when congestion is detected. The fast increase state can be however be resumed if the congestion level is low, this to enable a reasonably quick rate increase in case link throughput increases. o A delay trend is computed for earlier detection of incipient congestion and as a result it reduces jitter. o Addition of media a rate control function. o Use of inflection points to calculate congestion window and media rate to achieve reduced jitter. o Adjustment of delay 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 Section 3.1 to Section 3.3. Johansson & Sarker Expires April 21, 2016 [Page 5] Internet-Draft SCReAM October 2015 +---------------------------+ | Media encoder | +---------------------------+ ^ | (3)| (1)| | RTP | V | +-----------+ +---------+ | | | Media | (2) | Queue | | rate |<------| | | control | |RTP packets| +---------+ | | +-----------+ | | (4)| RTP | v +------------+ +--------------+ | Network | (7) | Sender | +-->| congestion |------>| Transmission | | | control | | Control | | +------------+ +--------------+ | | | (6) |(5) |-------------RTCP----------| RTP | | | v +------------+ | UDP | | socket | +------------+ Figure 1: SCReAM sender functional view The SCReAM algorithm constitutes mainly of three parts: network congestion control, sender transmission control and media rate adaptation. All these three 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 to received RTP packets, loss count and ECN [RFC6679] count. Johansson & Sarker Expires April 21, 2016 [Page 6] Internet-Draft SCReAM October 2015 3.1. Network Congestion Control The 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. The SCReAM congestion control method, uses LEDBAT [RFC6817] to measure the one-way delay (OWD). The OWD can be expressed as the estimated queuing delay. Similar to LEDBAT, it is not necessary to use synchronized clocks in sender and receiver in order to compute the one way delay. It is however necessary that they use the same clock frequency, or that the clock frequency at the receiver can be inferred reliably by the sender. The SCReAM sender calculates the congestion window based on the feedback from the SCReAM receiver. The congestion window is allowed to increase if the OWD is below a predefined target, otherwise the congestion window decreases. The delay target is typically set to 50-100ms. This ensures that the OWD is kept low on the average. The reaction to loss 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, in which case the queuing delay will stay close to the delay target. 3.2. Sender Transmission Control 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. 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 up in the RTP packet queues at the sender. The media bitrate is decreased if the RTP queue size exceeds a threshold. In cases where the sender frame queues increase rapidly such as the case of a RAT (Radio Access Type) handover it may be necessary to implement additional actions, such as discarding of encoded media frames or frame skipping in order to ensure that the RTP queues are Johansson & Sarker Expires April 21, 2016 [Page 7] Internet-Draft SCReAM October 2015 drained quickly. Frame skipping means that the frame rate is temporarily reduced. Which method to use is a design consideration and 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 a split between the network congestion control and the media rate adaptation. A SCReAM sender implements media rate control and a 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 single media sources (a.k.a streams) are used. However, multiple media sources are also supported in the design, in that case the sender transmission control will include a transmission scheduler. The transmission scheduler can then enforce the priorities for the different streams and act like a coupled congestion controller for multiple flows. Media frames are encoded and forwarded to the RTP queue (1). The media rate adaptation adapts to the size of the RTP queue (2) and controls the media bitrate (3). The RTP packets are picked from the RTP queue (for multiple flows from each queue based on some defined priority order or simply in a round robin fashion) (4) by the sender transmission controller. The sender transmission controller (in case of multiple flows a transmission scheduler) takes care of the transmission of RTP packets, to be written to the UDP socket (5). In the general case all media must go through the sender transmission controller and is allowed to be transmitted if the number of bytes in flight is less than the congestion window. RTCP packets are received (6) and the information about 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. 4.1.1.1. Constants The recommended values for the constants are deduced from experimental results. OWD_TARGET_LO (0.1s) Target value for the minimum OWD Johansson & Sarker Expires April 21, 2016 [Page 8] Internet-Draft SCReAM October 2015 OWD_TARGET_HI (0.4s) Target value for the maximum OWD OWD_WEIGHT (0.1) Averaging factor for owd_fraction_avg 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.6) CWND scale factor due to loss event BETA_ECN (0.8) CWND scale factor due to ECN event BETA_R (0.9) Target rate scale factor due to loss event MSS (1000 byte) Maximum segment size = Max RTP packet size BYTES_IN_FLIGHT_SLACK (10%) Additional slack to the congestion window RATE_ADJUST_INTERVAL (0.2s) Interval between media bitrate adjustments TARGET_BITRATE_MIN Min target bitrate [bps] TARGET_BITRATE_MAX Max target bitrate [bps] RAMP_UP_SPEED (200kbps/s) Maximum allowed rate increase speed PRE_CONGESTION_GUARD (0.0..0.2) Guard factor against early congestion onset. A higher value gives less jitter, possibly at the expense of a lower link utilization. TX_QUEUE_SIZE_FACTOR (0.0..0.2) Guard factor against RTP queue buildup OWD_TREND_LO (0.2) Threshold value for owd_trend Johansson & Sarker Expires April 21, 2016 [Page 9] Internet-Draft SCReAM October 2015 T_RESUME_FAST_INCREASE Time span until fast increase can be resumed, given that the owd_trend is below OWD_TREND_LO 4.1.1.2. State variables owd_target (OWD_TARGET_LO) OWD target owd_fraction_avg (0.0) EWMA filtered owd_fraction owd_fraction_hist[20] ({0,..,0}) Vector of the last 20 owd_fraction owd_trend (0.0) OWD trend, indicates incipient congestion owd_trend_mem (0.0) Low pass filtered version of owd_trend owd_norm_hist[100] ({0,..,0}) Vector of the last 100 owd_norm min_cwnd (2*MSS) Minimum congestion window in_fast_increase (true) True if in fast increase state cwnd (min_cwnd) Congestion window cwnd_last_max (1 byte) Congestion window inflection point, i.e. the last known highest cwnd. Used to limit cwnd increase close to the last known congestion point. bytes_newly_acked (0) The number of bytes that was acknowledged with the last received acknowledgement i.e. bytes acknowledged since the last CWND update. Reset after a CWND update send_wnd (0) Upper limit of how many bytes that can be transmitted. Updated when CWND is updated and when RTP packet is transmitted target_bitrate (0 bps) Media target bitrate Johansson & Sarker Expires April 21, 2016 [Page 10] Internet-Draft SCReAM October 2015 target_bitrate_last_max (1 bps) Media target bitrate inflection point i.e. the last known highest target_bitrate. Used to limit bitrate increase 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 rate_rtp (0.0 bps) Measured bitrate from the media encoder rate_rtp_median (0.0 bps) Median value of rate_rtp, computed over more than 10s s_rtt (0.0s) Smoothed RTT [s], computed similar to method depicted in [RFC6298] rtp_queue_size (0 bits) Size of RTP packets in queue rtp_size (0 byte) Size of the last transmitted RTP packet 4.1.2. Network congestion control This section explains the network congestion control, it contains two main functions o Computation of congestion window at the sender: Gives an upper limit to the number of bytes in flight i.e. how many bytes that have been transmitted but not yet acknowledged. o Calculation of send window at the sender: RTP packets are transmitted if allowed by the relation between the number of bytes in flight and the congestion window. This is controlled by the send window. Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an RTP packet oriented protocol. Thus a list of transmitted RTP packets and their respective transmission times (wall-clock time) is kept for further calculation. The feedback from the receiver is assumed to consist of the following elements. Johansson & Sarker Expires April 21, 2016 [Page 11] Internet-Draft SCReAM October 2015 o The highest received RTP sequence number. o The wall clock timestamp corresponding to the received RTP packet with he highest sequence number. o Accumulated number of lost RTP packets (n_loss). o Accumulated number of ECN-CE marked packets (n_ECN). When the sender receives RTCP feedback, the OWD is calculated as outlined in [RFC6817] and a number of variables are updated as illustrated by the pseudo code below. update_variables(owd): owd_fraction = owd/owd_target #calculate moving average owd_fraction_avg = (1-OWD_WEIGHT)*owd_fraction_avg+ OWD_WEIGHT*owd_fraction update_owd_fraction_hist(owd_fraction) # R is an autocorrelation function of owd_fraction_hist # at lag K a = R(owd_fraction_hist,1)/R(owd_fraction_hist,0) #calculate OWD trend owd_trend = a*owd_fraction_avg owd_trend_mem = max(0.99*owd_trend_mem, owd_trend) The OWD fraction is sampled every 50ms and the last 20 samples are stored in a vector (owd_fraction_hist). This vector is used in the computation of an OWD trend that gives a value between 0.0 and 1.0 depending on the estimated congestion level. The prediction coefficient 'a' has positive values if OWD shows an increasing trend, thus an indication of congestion is obtained before the OWD target is reached. The prediction coefficient is further multiplied with owd_fraction_avg to reduce sensitivity to increasing OWD when OWD is very small. The owd_trend is utilized in the media rate control to indicate incipient congestion and to determine when to exit from fast increase mode. owd_trend_mem is used to enforce a less aggressive rate increase after congestion events. The function update_owd_fraction_hist(..) removes the oldest element and adds the latest owd_fraction element to the owd_fraction_hist vector. A loss event is detected if the n_loss counter in the feedback has increased since the previous received feedback. Once a loss event is detected, the n_loss counter is ignored for a full smoothed round trip time, the intention of this is to limit the congestion window decrease to at most once per round trip. The congestion window backoff due to loss events is deliberately a bit less than is the case with e.g TCP NewReno. The reason is that Johansson & Sarker Expires April 21, 2016 [Page 12] Internet-Draft SCReAM October 2015 TCP is generally used to transmit whole files, which can be translated to an infinite source bitrate. SCReAM on the other hand has a source which rate is limited to a value close to the available transmit rate and often below said value, the effect of this is that SCReAM has less opportunity to grab free capacity than a TCP based file transfer. To compensate for this it is necessary to let SCReAM reduce the congestion window slightly less when loss events occur. An ECN event is detected if the n_ECN counter in the feedback report has increased since the previous received feedback. Once an ECN event is detected, the n_ECN counter is ignored for a full smoothed round trip time, the intention of this is to limit the congestion window decrease to at most once per round trip. The congestion window backoff due to an ECN event is deliberately smaller than if a loss event occurs. This is inline with the idea outlined in [Khademi_alternative_backoff_ECN] to enable ECN marking thresholds lower than the corresponding packet drop thresholds. The update of congestion window depends on whether a loss or ECN or neither occurs. The pseudo code below describes actions taken in case of different events. on loss(owd): in_fast_increase = false cwnd_last_max = cwnd cwnd = max(min_cwnd,cwnd*BETA_LOSS) adjust_owd_target(owd)#compensating for competing flows calculate_send_window(owd,owd_target) on ECN(owd): in_fast_increase = false cwnd_last_max = cwnd cwnd = max(min_cwnd,cwnd*BETA_ECN) adjust_owd_target(owd)#compensating for competing flows calculate_send_window(owd, owd_target) # when no loss or ECN event is detected on acknowledgement(owd): update_bytes_newly_acked() update_cwnd(bytes_newly_acked) adjust_owd_target(owd) #compensating for competing flows calculate_send_window(owd, owd_target) check_to_resume_fast_increase() The methods are further described in detail below. Johansson & Sarker Expires April 21, 2016 [Page 13] Internet-Draft SCReAM October 2015 4.1.2.1. Updating bytes_newly_acked The 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 RTP packets with sequence number N+1, N+2 and N+3. Packets that are lost are also included, which means that even though e.g packet N+2 was lost, its size is still included in the update of bytes_newly_acked. 4.1.2.2. Updating congestion window The congestion window update is based on OWD, except for the occurrence of loss or ECN events, which was described earlier. OWD is obtained from the send and received timestamp of the RTP packets. LEDBAT [RFC6817] explains the details of the computation of the OWD. An OWD sample is obtained for each received acknowledgement. No smoothing of the OWD samples occur, however some smoothing occurs anyway as the computation of the CWND is in itself a low pass filter function. Pseudo code for the update of the congestion window is found below. Johansson & Sarker Expires April 21, 2016 [Page 14] Internet-Draft SCReAM October 2015 update_cwnd(bytes_newly_acked): # additional scaling factor to slow down closer to target # The min scale factor is 0.2 to avoid that the congestion window # growth is stalled scale = max(0.2,min(1.0,(abs(cwnd-cwnd_last_max)/cwnd_i*4)^2)) # action depends on whether algorithm is in fast increase if (in_fast_increase) if(owd_trend >= 0.2) in_fast_increase=false cwnd_i=cwnd else cwnd = cwnd + bytes_newly_acked*scale return # not in fast increase phase # off_target calculated as with LEDBAT off_target = (owd_target - owd) / owd_target gain = GAIN # adapt only increase based on scale if (off_target > 0) gain *= (1 - owd_trend/ 0.2) * scale # increase/decrease the congestion window # off_target can be positive or negative cwnd += gain * off_target * bytes_newly_acked * MSS / cwnd # Limit cwnd to the maximum number of bytes in flight cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM) cwnd = max(cwnd, MIN_CWND) CWND is updated differently depending on whether the congestion control is in fast increase or not. A Boolean variable in_fast_increase indicates if the congestion is in fast increase state. In fast increase state the congestion window is increased with the number of newly acknowledged bytes scaled by a scale factor that depends on the relation between CWND and the last known maximum value of CWND (cwnd_last_max). The congestion window growth when in_fast_increase is false is dictated by the relation between owd and owd_target, also here the scale factor scale factor is applied to limit the congestion window growth when cwnd gets close to cwnd_last_max. Johansson & Sarker Expires April 21, 2016 [Page 15] Internet-Draft SCReAM October 2015 The scale factor as applied above makes the congestion window grow in a similar way as is the case with the Cubic congestion control algorithm. SCReAM calculates the GAIN in a similar way to what is specified in [RFC6817]. There are however a few differences. o [RFC6817] specifies a constant GAIN, this specification however limits the gain when CWND is increased dependent on near congestion state and the relation to the last known max CWND value. o [RFC6817] specifies that the CWND increased is limited by an additional function controlled by a constant ALLOWED_INCREASE. This additional limitation is removed in this specification. Further the CWND is limited by max_bytes_in_flight and min_cwnd. The limitation of the congestion window by the maximum number of bytes in flight over the last 5 seconds (max_bytes_in_flight) avoids possible over-estimation of the throughput after for example, idle periods. An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to allow for a certain amount of media coder output rate variability. SCReAM uses the terminology "Bytes in flight (bytes_in_flight)" which is computed as the sum of the sizes of the RTP packets ranging from the RTP packet most recently transmitted down to but not including the acknowledged packet 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 RTP packet 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 RTP packets with sequence number SN-4, SN-3, SN-2, SN-1 and SN, it does not matter if for instance packet with sequence number SN-3 was lost, the size of RTP packet with sequence number SN-3 will still be considered in the computation of bytes_in_flight. 4.1.2.3. Compensation for competing flows It is likely that a flow using SCReAM algorithm will have to share congested bottlenecks with other flows that use a more aggressive congestion control algorithm. SCReAM takes care of such situations by adjusting the owr_target. Johansson & Sarker Expires April 21, 2016 [Page 16] Internet-Draft SCReAM October 2015 adjust_owd_target(owd) owd_norm = owd / OWD_TARGET_LOW update_owd_norm_history(owd_norm) # Compute variance owd_norm_var = VARIATION(owd_norm_history(100)) # Compensation for competing traffic if (owd_norm_var < 0.16) # Compute average owd_norm_avg = AVERAGE(owd_norm_history(20)) # Update target OWD owd_target = owd_norm_avg*OWD_TARGET_LO*1.1 owd_target = min(OWD_TARGET_HI, owd_target) owd_target = max(OWD_TARGET_LO, owd_target) The owd_target is adjusted according to the owd_norm_mean_sh whenever owd_norm_var is below a given value. The condition to update owd_target is fulfilled if owd_norm_var < 0.16 (indicating that the standard deviation is less than 0.4). owd_norm is the OWD divided by OWD_TARGET_LO. owd_norm_mean_sh is the short term (last 20 samples) average of owd_norm. owd_norm_var is the variance of owd_norm over the last 100 samples. 4.1.2.4. Send window calculation The basic design principle behind packet transmission in SCReAM is 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: o Bitrate variations: The media frame size is always varying to a larger or smaller extent. A strict rule as the one given above will have the effect that the media bitrate will have difficulties to increase as the congestion window puts a too hard restriction on the media frame size variation. This can lead to occasional queuing of RTP packets in the RTP packet queue that will further prevent bitrate increase. o Reverse (feedback) path congestion: Especially in transport over buffer-bloated networks, the one way delay in the reverse direction may jump due to congestion. The effect of this is that the acknowledgements are delayed with the result that the self- clocking is temporarily halted, even though the forward path is not congested. The congestion window is adjusted depending on OWD and its relation to the OWD target. When OWD is greater than OWD target the congestion window enforces a strict rule that helps to prevent Johansson & Sarker Expires April 21, 2016 [Page 17] Internet-Draft SCReAM October 2015 further queue buildup. When OWD is less than or equal to OWD target then an additional slack is added to the congestion window that reduces as congestion increases, BYTES_IN_FLIGHT_SLACK is a maximum allowed slack in percent. A large value increases the robustness to bitrate variations in the source and congested feedback channel issues. The possible drawback is increased delay or packet loss when forward path congestion occurs. The adjusted congestion window (cwnd_s) is used in the send window calculation. The send window is given by the relation between the adjusted congestion window and the amount of bytes in flight according to the pseudo code below. calculate_send_window(owd, owd_target) # compensate for backward congestion and bitrate variations if (owd <= owd_target) x_cwnd=1.0+BYTES_IN_FLIGHT_SLACK*(1.0-owd_trend/0.5)/100.0 cwnd_s = max(cwnd*x_cwnd, cwnd+MSS) send_wnd = cwnd_s-bytes_in_flight 4.1.2.5. Resuming fast increase Fast increase can be resumed in order to speed up the bitrate increase in case congestion abates. The condition to resume fast increase (in_fast_increase = true) is that owd_trend is less than OWD_TREND_LO for T_RESUME_FAST_INCREASE seconds or more. 4.1.3. Media rate control The media rate control algorithm is executed at regular intervals RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to loss events. The media rate control operates based on the size of the RTP packet send queue and observed loss events. In addition, owd_trend is also considered in the media rate control, this to reduce the amount of induced network jitter. The role of the media rate control is to strike a reasonable balance between a low amount of queuing in the RTP queue and a sufficient amount of data to send in order to keep the data path busy. A too cautious setting leads to possible under-utilization of network capacity and that the flow is starved out by other, more opportunistic traffic, on the other hand a too aggressive setting leads to extra jitter. A variable target_bitrate is adjusted depending on the congestion state. The target bitrate can vary between a minimum value (target_bitrate_min) and a maximum value (target_bitrate_max). Johansson & Sarker Expires April 21, 2016 [Page 18] Internet-Draft SCReAM October 2015 For the overall bitrate adjustment, two network throughput estimates are computed : o rate_transmit: The measured transmit bitrate o rate_ack: The ACKed bitrate, i.e. the volume of ACKed bits per time unit. Both estimates are updated every 200ms. The current throughput, current_rate, is computed as the maximum value of rate_transmit and rate_ack. The rationale behind the use of rate_ack in addition to rate_transmit is that rate_transmit is affected also by the amount of data that is available to transmit, thus a lack of data to transmit can be seen as reduced throughput that may itself cause an unnecessary rate reduction. To overcome this shortcoming; rate_ack is used as well. This gives a more stable throughput estimate. Note that rate_ack is updated by bytes_newly_acked, which means that even lost packets are regarded as acknowledged. The rate change behavior depends on whether a loss event has occurred, and if the congestion control is in fast increase or not. Johansson & Sarker Expires April 21, 2016 [Page 19] Internet-Draft SCReAM October 2015 # The target_bitrate is updated at a regular interval according # to RATE_ADJUST_INTERVAL on loss: target_bitrate_last_max = target_bitrate target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN) exit if (in_fast_increase = true) scl_i = (target_bitrate - target_bitrate_last_max)/ target_bitrate_last_max increment = RAMP_UP_SPEED*RATE_ADJUST_INTERVAL* (1.0-min(1.0, owd_trend/0.2)) # Value 0.2 as the bitrate should be allowed to increase # at least slowly --> avoid locking the rate to # target_bitrate_last_max increment *= max(0.2, min(1.0, (scl_i*4)^2)) target_bitrate += increment target_bitrate *= (1.0- PRE_CONGESTION_GUARD*owd_trend) else pre_congestion = min(1.0, max(0.0, owd_fraction_avg-0.3)/0.7) pre_congestion += owd_trend target_bitrate=current_rate*(1.0-PRE_CONGESTION_GUARD* pre_congestion)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size end rate_rtp_limit = max(br, max(rate_rtp,rtp_rate_median)) rate_rtp_limit *= (2.0-1.0*owd_trend_mem) target_bitrate = min(target_bitrate, rate_rtp_limit) target_bitrate = min(TARGET_BITRATE_MAX, max(TARGET_BITRATE_MIN,target_bitrate)) In case of a loss event the target_bitrate is updated and the rate change procedure is exited. Otherwise the rate change procedure continues. An ECN event does not cause any action, the reason to this is that the congestion window is reduced less due to ECN events than loss events, the effect is thus that the expected additional RTP queuing delay due to ECN events is so small that an additional decrease in media rate is not warranted. When in fast increase state, the bitrate increase is given by the desired ramp-up speed (RAMP_UP_SPEED) and is limited by the relation between the current bitrate and the last known max bitrate. Furthermore an increased OWD trend limits the bitrate increase. The setting of RAMP_UP_SPEED depends on preferences, a high setting such as 1000kbps/s makes it possible to quickly gain high quality media, Johansson & Sarker Expires April 21, 2016 [Page 20] Internet-Draft SCReAM October 2015 this is however at the expense of a higher risk of jitter, which can manifest itself as e.g. choppy video rendering. When in_fast_increase is false, the bitrate increase is given by the current bitrate and is also controlled by the estimated RTP queue and the OWD trend, thus it is sufficient that an increased congestion level is sensed by the network congestion control to limit the bitrate. In the fast increase phase an allowed increment is computed based on the congestion level and the relation to target_bitrate_last_max and the target_bitrate is reduced further if congestion is detected. If in_fast_increase is false then the target_bitrate_last_max is updated to the current value of target_bitrate if in_fast_increase was true the last time the bitrate was updated. Additionally, a pre- congestion indicator is computed and the rate is adjusted accordingly. In cases where input stimuli to the media encoder is static, for instance in "talking head" scenarios, the target bitrate is not always fully utilized. This may cause undesirable oscillations in the target bitrate in the cases where the link throughput is limited and the media coder input stimuli changes between static and varying. To overcome this issue, the target bitrate is capped to be less than a given multiplier of a median value of the history of media coder output bitrates, rate_rtp_limit. A multiplier is applied to rate_rtp_limit, depending on congestion history. The target_bitrate is then limited by this rate_rtp_limit. Finally the target_bitrate is enforced to be within the defined min and max values. The vary reader may notice the dependency on the OWD in the computation of the target bitrate, this manifests itself in the use of the owd_trend and owd_fraction_avg. As these parameters are used also in the network congestion control one may suspect that some odd interaction between the media rate control and the network congestion control, this is in fact the case if the parameter PRE_CONGESTION_GUARD is set to a high value. The use of owd_trend and owd_fraction_avg in the media rate control is solely to reduce jitter, the dependency can be removed by setting PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase at the expense of more jitter. Johansson & Sarker Expires April 21, 2016 [Page 21] Internet-Draft SCReAM October 2015 4.1.3.1. FEC and packet overhead considerations The target bitrate given by SCReAM depicts the bitrate including RTP and FEC overhead. Therefore it is necessary that the media encoder takes this overhead into account when the media bitrate is set. It is not strictly necessary to make a 100% perfect compensation for the overhead as the SCReAM algorithm will inherently compensate moderate errors. Under-compensation for the overhead has the effect that the jitter will increase somewhat while overcompensation will have the effect that the bottleneck link becomes under-utilized. 4.2. SCReAM Receiver The simple task of the SCReAM receiver is to feedback acknowledgements of received packets, total loss count and total ECN count to the SCReAM sender. Upon reception of each RTP packet the receiver will simply maintain enough information to send the aforementioned values to the SCReAM sender via RTCP transport layer feedback message. The frequency of the feedback message depends on the available RTCP bandwidth. The details of this feedback is given in another document. 5. Discussion This section covers a few discussion points o RTCP feedback overhead: SCReAM benefits from a relatively frequent feedback. Experiments have shown that a feedback rate roughly equal to the frame rate gives a stable self-clocking and robustness against loss of feedback. With a maximum bitrate of 1500kbps the RTCP feedback overhead is in the range 10-15kbps with reduced size RTCP [RFC5506], including IP and UDP framing, in other words the RTCP overhead is quite modest and should not pose a problem in the general case. Other solutions may be required in highly asymmetrical link capacity cases. Worth notice is that SCReAM can work with as low feedback rates as once every 200ms, this however comes with a higher sensitivity to loss of feedback and also a potential reduction in throughput. o AVPF mode: The RTCP feedback is based on AVPF regular mode. The SCReAM feedback is transmitted as reduced size RTCP so save overhead, it is however required to transmit full compound RTCP at regular intervals, this interval can be controlled by trr-int depicted in [RFC4585]. o Clock drift: SCReAM can suffer from the same issues with clock drift as is the case with LEDBAT [RFC6817]. Section A.2 in said RFC however describes ways to mitigate issues with clock drift. Johansson & Sarker Expires April 21, 2016 [Page 22] Internet-Draft SCReAM October 2015 6. Implementation status [Editor's note: Please remove the whole section before publication, as well reference to RFC 6982] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC6982], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see it". 6.1. OpenWebRTC The SCReAM algorithm has been implemented in the OpenWebRTC project [OpenWebRTC], an open source WebRTC implementation from Ericsson Research. This SCReAM implementation is usable with any WebRTC endpoint using OpenWebRTC. o Organization : Ericsson Research, Ericsson. o Name : OpenWebRTC gst plug-in. o Implementation link : The GStreamer plug-in code for SCReAM can be found at github repository [SCReAM-Implementation] and is waiting to be merged with the master branch of OpebWebRTC repository (https://github.com/EricssonResearch/openwebrtc/pull/413). However, people are encouraged to have look at it and send feedback. This wiki (https://github.com/EricssonResearch/openwebrtc/wiki) contains required information for building and using OpenWebRTC. Note that to get all the SCReAM related code and build them, one has to use the cerbero fork from DanielLindstrm' s repository (https://github.com/DanielLindstrm/cerbero/tree/scream) instead of EricssonResearch fork of cerbero. Johansson & Sarker Expires April 21, 2016 [Page 23] Internet-Draft SCReAM October 2015 o Coverage : The code implements [I-D.ietf-rmcat-scream-cc]. The current implementation has been tuned and tested to adapt a video stream and does not adapt the audio streams. o Implementation experience : The implementation of the algorithm in the OpenWebRTC has given great insight into the algorithm itself and its interaction with other involved modules such as encoder, RTP queue etc. In fact it proves the usability of a self-clocked rate adaptation algorithm in the real WebRTC system. The implementation experience has led to various algorithm improvements both in terms of stability and design. For example, improved rate increase behavior and removal of the ACK vector from the feedback message. o Contact : irc://chat.freenode.net/openwebrtc 6.2. A C++ Implementation of SCReAM o Organization : Ericsson Research, Ericsson. o Name : SCReAM. o Implementation link : A C++ implementation of SCreAM is also available which is aimed for doing quick experiments[SCReAM-Cplusplus_Implementation]. This repository also includes a rudimentary implementation of a simulator. This code can be included in other simulators like NS-3. o Coverage : The code implements [I-D.ietf-rmcat-scream-cc] o Contact : ingemar.s.johansson@ericsson.com, zaheduzzaman.sarker@ericsson.com 7. Acknowledgements We would like to thank the following persons for their comments, questions and support during the work that led to this memo: Markus Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many additional thanks to Karen and Mirja for patiently reading, suggesting improvements and also for asking all the difficult but necessary questions. Johansson & Sarker Expires April 21, 2016 [Page 24] Internet-Draft SCReAM October 2015 8. IANA Considerations A new RFC4585 transport layer feedback message needs to be standardized. 9. 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. 10. Change history A list of changes: o WG-01 to WG-02: Complete restructuring of the document. Moved feedback message to a separate draft. o WG-00 to WG-01 : Changed the Source code section to Implementation status section. o -05 to WG-00 : First version of WG doc, moved additional features section to Appendix. Added description of prioritization in SCReAM. Added description of additional cap on target bitrate o -04 to -05 : ACK vector is replaced by a loss counter, PT is removed from feedback, references to source code added o -03 to -04 : Extensive changes due to review comments, code somewhat modified, frame skipping made optional o -02 to -03 : Added algorithm description with equations, removed pseudo code and simulation results o -01 to -02 : Updated GCC simulation results o -00 to -01 : Fixed a few bugs in example code 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Johansson & Sarker Expires April 21, 2016 [Page 25] Internet-Draft SCReAM October 2015 [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, . [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, . [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, . [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, . [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, . 11.2. Informative References [I-D.ietf-rmcat-app-interaction] Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP Application Interaction with Congestion Control", draft- ietf-rmcat-app-interaction-01 (work in progress), October 2014. [I-D.ietf-rmcat-cc-codec-interactions] Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "Congestion Control and Codec interactions in RTP Applications", draft-ietf-rmcat-cc-codec-interactions-01 (work in progress), October 2015. [I-D.ietf-rmcat-coupled-cc] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion control for RTP media", draft-ietf-rmcat-coupled-cc-00 (work in progress), September 2015. Johansson & Sarker Expires April 21, 2016 [Page 26] Internet-Draft SCReAM October 2015 [I-D.ietf-rmcat-scream-cc] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation for Multimedia", draft-ietf-rmcat-scream-cc-01 (work in progress), July 2015. [I-D.ietf-rmcat-wireless-tests] Sarker, Z. and I. Johansson, "Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks", draft-ietf-rmcat-wireless-tests-00 (work in progress), June 2015. [I-D.ietf-tcpm-newcwv] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating TCP to support Rate-Limited Traffic", draft-ietf-tcpm- newcwv-13 (work in progress), June 2015. [Khademi_alternative_backoff_ECN] "TCP Alternative Backoff with ECN (ABE)", . [OpenWebRTC] "Open WebRTC project.", . [PACKET_CONSERVATION] "Congestion Avoidance and Control", 1988. [QoS-3GPP] TS 23.203, 3GPP., "Policy and charging control architecture", June 2011, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013, . [SCReAM-Cplusplus_Implementation] "C++ Implementation of SCReAM", . Johansson & Sarker Expires April 21, 2016 [Page 27] Internet-Draft SCReAM October 2015 [SCReAM-Implementation] "SCReAM Implementation", . [TFWC] University College London, "Fairer TCP-Friendly Congestion Control Protocol for Multimedia Streaming", December 2007, . Appendix A. Additional features This section describes additional features. They are not required for the basic functionality of SCReAM but can improve performance in certain scenarios and topologies. A.1. Stream prioritization The SCReAM algorithm makes a good distinction between network congestion control and the media rate control, an RTP queue queues up RTP packets pending transmission. This is easily extended to many streams, in which case RTP packets from two or more RTP queues are scheduled at the rate permitted by the network congestion control. The scheduling can be done by means of a few different scheduling regimes. For example the method applied in [I-D.ietf-rmcat-coupled-cc] can be used. The implementation of SCReAM use something that is referred to as credit based scheduling. Credit based scheduling is for instance implemented in IEEE 802.17. The short description is that credit is accumulated by queues as they wait for service and are spent while the queues are being services. For instance, if one queue is allowed to transmit 1000bytes, then a credit of 1000bytes is allocated to the other unscheduled queues. This principle can be extended to weighted scheduling in which case the credit allocated to unscheduled queues depends on the weight allocation. A.2. Computation of autocorrelation function The autocorrelation function is computed over a vector of values. Let x be a vector constituting N values, the autocorrelation function for a given lag=k for the vector x is given by . Johansson & Sarker Expires April 21, 2016 [Page 28] Internet-Draft SCReAM October 2015 n=N-k R(x,k) = SUM x(n)*x(n+k) n=1 Figure 2: Autocorrelation function Authors' Addresses Ingemar Johansson Ericsson AB Laboratoriegraend 11 Luleaa 977 53 Sweden Phone: +46 730783289 Email: ingemar.s.johansson@ericsson.com Zaheduzzaman Sarker Ericsson AB Laboratoriegraend 11 Luleaa 977 53 Sweden Phone: +46 761153743 Email: zaheduzzaman.sarker@ericsson.com Johansson & Sarker Expires April 21, 2016 [Page 29]