--- 1/draft-ietf-rmcat-scream-cc-10.txt 2017-10-10 05:22:40.991996247 -0700 +++ 2/draft-ietf-rmcat-scream-cc-11.txt 2017-10-10 05:22:41.576010106 -0700 @@ -1,54 +1,54 @@ RMCAT WG I. Johansson Internet-Draft Z. Sarker Intended status: Experimental Ericsson AB -Expires: January 19, 2018 July 18, 2017 +Expires: April 12, 2018 October 9, 2017 Self-Clocked Rate Adaptation for Multimedia - draft-ietf-rmcat-scream-cc-10 + draft-ietf-rmcat-scream-cc-11 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 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 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/. + Drafts is at https://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 January 19, 2018. + This Internet-Draft will expire on April 12, 2018. 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 - (http://trustee.ietf.org/license-info) in effect on the date of + (https://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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 @@ -58,95 +58,98 @@ 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4 3.1. Network Congestion Control . . . . . . . . . . . . . . . 7 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 9 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Constants and Parameter values . . . . . . . . . . . 9 4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 9 4.1.1.2. State variables . . . . . . . . . . . . . . . . . 11 4.1.2. Network congestion control . . . . . . . . . . . . . 13 - 4.1.2.1. Congestion window update . . . . . . . . . . . . 16 - 4.1.2.2. Competing flows compensation . . . . . . . . . . 18 - 4.1.2.3. Lost packet detection . . . . . . . . . . . . . . 20 - 4.1.2.4. Send window calculation . . . . . . . . . . . . . 20 - 4.1.2.5. Packet pacing . . . . . . . . . . . . . . . . . . 21 - 4.1.2.6. Resuming fast increase . . . . . . . . . . . . . 21 + 4.1.2.1. Reaction to packets loss and ECN . . . . . . . . 15 + 4.1.2.2. Congestion window update . . . . . . . . . . . . 16 + 4.1.2.3. Competing flows compensation . . . . . . . . . . 18 + 4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 20 + 4.1.2.5. Send window calculation . . . . . . . . . . . . . 20 + 4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 21 + 4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 22 + 4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 22 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 22 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 25 4.2.1. Requirements on feedback elements . . . . . . . . . . 25 4.2.2. Requirements on feedback intensity . . . . . . . . . 27 - 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 6. Implementation status . . . . . . . . . . . . . . . . . . . . 28 + 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 6. Implementation status . . . . . . . . . . . . . . . . . . . . 29 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 29 - 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 29 + 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 30 7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 30 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 31 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . 33 - Appendix A. Additional information . . . . . . . . . . . . . . . 34 - A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 34 - A.2. Computation of autocorrelation function . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 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 MUST employ congestion - control, to achieve robust performance and to avoid congestion - collapse in the Internet. Interactive realtime 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 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, SHOULD be both quick and be able to operate over a large - range in channel capacity. This memo describes SCReAM (Self-Clocked - Rate Adaptation for Multimedia), a solution that is based on the - self-clocking principle of TCP and uses techniques similar to what is - used in the LEDBAT based rate adaptation algorithm [RFC6817]. SCReAM - is not entirely self-clocked as it augments self-clocking with pacing - and a minimum send rate. + 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 realtime + 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 realtime 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 + realtime media, such as WebRTC, should be both quick and be able to + operate over a large range in channel capacity. This memo describes + SCReAM (Self-Clocked Rate Adaptation for Multimedia), a solution that + implements congestion control for RTP streams [RFC3550]. While + SCReAM was originally devised for WebRTC (Web Real-Time + Communication) [RFC7478], 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 LEDBAT based rate adaptation algorithm + [RFC6817]. SCReAM is not entirely self-clocked as it augments self- + clocking with pacing and a minimum send rate. 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 + 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 100Mbps, 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 - MAY drop for short time intervals at e.g. handover, these short + can drop for short time intervals at e.g. 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 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, an RMCAT flow in that bearer SHOULD reduce + allocation for a bearer, an RMCAT 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. 1.2. Why is it a self-clocked algorithm? Self-clocked congestion control algorithms provide a benefit over the rate based counterparts in that the former consists of two adaptation mechanisms: o A congestion window computation that evolves over a longer @@ -407,30 +410,36 @@ The RECOMMENDED values, within (), for the constants are deduced from experiments. The units are enclosed in square brackets [ ]. QDELAY_TARGET_LO (0.1s) Target value for the minimum qdelay. QDELAY_TARGET_HI (0.4s) 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. The - target qdelay MUST NOT be initialized to this high value however as - it would increase e2e delay and also make the rate control and - congestion control loop sluggish. + target qdelay does not have to be initialized to this high value + however as it would increase e2e delay and also make the rate + control and congestion control loop sluggish. QDELAY_WEIGHT (0.1) Averaging factor for qdelay_fraction_avg. QDELAY_TREND_TH (0.2) Averaging factor for qdelay_fraction_avg. + QDELAY_TREND_TH (0.2) + Averaging factor for qdelay_fraction_avg. + + MIN_CWND (3000byte) + Min CWND. + 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.8) @@ -471,22 +480,24 @@ for evaluation of a real implementation. RTP_QDELAY_TH (0.02s) RTP queue delay threshold for a target rate reduction. TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP qdelay threshold exceeds. QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend. - T_RESUME_FAST_INCREASE Time span until fast increase can be resumed, - given that the qdelay_trend is below QDELAY_TREND_LO. + T_RESUME_FAST_INCREASE (5s) Time span until fast increase can be + resumed, given that the qdelay_trend is below QDELAY_TREND_LO. + + RATE_PACE_MIN (50000bps) Minimum pacing rate. 4.1.1.2. State variables The values within () indicate initial values. qdelay_target (QDELAY_TARGET_LO) qdelay target, a variable qdelay target is introduced to manage cases where e.g. FTP competes for the bandwidth over the same bottleneck, a fixed qdelay target would otherwise starve the RMCAT flow under such circumstances. The qdelay target is allowed to @@ -637,40 +648,52 @@ # of congestion in the past qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend) The qdelay fraction is sampled every 50ms and the last 20 samples are stored in a vector (qdelay_fraction_hist). This vector is used in the computation of an qdelay 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 qdelay shows an increasing trend, thus an indication of congestion is obtained before the qdelay - target is reached. The autocorrelation function 'R' is defined in - Appendix A.2. The prediction coefficient is further multiplied with + target is reached. + + The autocorrelation function 'R' is defined as follows. Let x be a + vector constituting N values, the biased autocorrelation function for + a given lag=k for the vector x is given by. + + n=N-k + R(x,k) = SUM x(n)*x(n+k) + n=1 + + The prediction coefficient is further multiplied with qdelay_fraction_avg to reduce sensitivity to increasing qdelay when it is very small. The 50ms sampling is a simplification and MAY have the effect that the same qdelay is sampled several times, this does however not pose any problem as the vector is only used to determine if the qdelay is increasing or decreasing. The qdelay_trend is utilized in the media rate control to indicate incipient congestion and to determine when to exit from fast increase mode. qdelay_trend_mem is used to enforce a less aggressive rate increase after congestion events. The function update_qdelay_fraction_hist(..) removes the oldest element and adds the latest qdelay_fraction element to the qdelay_fraction_hist vector. +4.1.2.1. Reaction to packets loss and ECN + A loss event is indicated if one or more RTP packets are declared - missing. The loss detection is described in Section 4.1.2.3. Once a - loss event is detected, further detected lost RTP packets are 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. + missing. The loss detection is described in Section 4.1.2.4. Once a + loss event is detected, further detected lost RTP packets SHOULD be + 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 back off due to loss events is deliberately a bit less than is the case with e.g. TCP Reno. The reason is that 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 whose rate is limited to a value close to the available transmit rate and often below that 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 RECOMMENDED to let SCReAM reduce the congestion window less than what is the case with TCP when loss events occur. @@ -678,51 +701,51 @@ 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 back off due to an ECN event MAY be smaller than if a loss event occurs. This is in line with the idea outlined in [I-D.ietf-tcpm-alternativebackoff-ecn] to enable ECN marking thresholds lower than the corresponding packet drop thresholds. +4.1.2.2. Congestion window update + The update of the congestion window depends on whether loss or ECN- marking or neither occurs. The pseudo code below describes actions taken in case of the different events. on congestion event(qdelay): # Either loss or ECN mark is detected in_fast_increase = false if (is loss) # loss is detected - cwnd = max(min_cwnd,cwnd*BETA_LOSS) + cwnd = max(MIN_CWND,cwnd*BETA_LOSS) else # No loss, so it is then an ECN mark - cwnd = max(min_cwnd,cwnd*BETA_ECN) + cwnd = max(MIN_CWND,cwnd*BETA_ECN) end adjust_qdelay_target(qdelay) #compensating for competing flows calculate_send_window(qdelay,qdelay_target) # when no congestion event on acknowledgement(qdelay): update_bytes_newly_acked() update_cwnd(bytes_newly_acked) adjust_qdelay_target(qdelay) #compensating for competing flows calculate_send_window(qdelay, qdelay_target) check_to_resume_fast_increase() The methods are further described in detail below. -4.1.2.1. Congestion window update - The congestion window update is based on qdelay, except for the occurrence of loss events (one or more lost RTP packets in one RTT), or ECN events, which was described earlier. Pseudo code for the update of the congestion window is found below. update_cwnd(bytes_newly_acked): # in fast increase ? @@ -775,71 +798,65 @@ the number of newly acknowledged bytes as long as the window is sufficiently used. Sparse feedback can potentially limit congestion window growth, an additional slack is therefore added, given by the number of newly acknowledged bytes. The congestion window growth when in_fast_increase is false is dictated by the relation between qdelay and qdelay_target, congestion window growth is limited if the window is not used sufficiently. 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 increase is limited by an - additional function controlled by a constant ALLOWED_INCREASE. - This additional limitation is removed in this specification. + [RFC6817]. However, [RFC6817] specifies that the CWND increase 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. -4.1.2.2. Competing flows compensation +4.1.2.3. Competing flows compensation 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 qdelay_target. 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 - oh_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t) - oh_t *= QDELAY_TARGET_LO + new_target_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t) + new_target_t *= QDELAY_TARGET_LO if (loss_event_rate > 0.002) # Packet losses detected - qdelay_target = 1.5*oh_t + qdelay_target = 1.5*new_target_t else if (qdelay_norm_var_t < 0.2) # Reasonably safe to set target qdelay - qdelay_target = oh_t + qdelay_target = new_target_t else # Check if target delay can be reduced, this helps to avoid # that the target delay is locked to high values for ever - if (oh_t < QDELAY_TARGET_LO) + if (new_target_t < QDELAY_TARGET_LO) # Decrease target delay quickly as measured queueing # delay is lower than target - qdelay_target = max(qdelay_target*0.5,oh_t) + 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) @@ -850,62 +867,65 @@ A low qdelay_norm_avg_t value indicates that the qdelay does not change rapidly. It is desired to avoid the case that the qdelay target is increased due to self-congestion, indicated by a changing qdelay and consequently an increased qdelay_norm_var_t. Still it SHOULD be possible to increase the qdelay target if the qdelay continues to be high. This is a simple function with a certain risk of both false positives and negatives. In the simulated LTE test cases it manages competing FTP flows reasonably well at the same time as generally avoiding accidental increases in the qdelay target. The algorithm can however accidentally increase the qdelay target and - cause self-inflicted congestion in certain cases. It is therefore - RECOMMENDED that the algorithm described in this section is turned - off it is deemed unlikely that competing flows occur over the same - bottleneck + cause self-inflicted congestion in certain cases. If it is deemed + unlikely that competing flows occur over the same bottleneck, the + algorithm described in this section MAY be turned off. However, when + sending over the Internet, often the network conditions are not known + for sure. Therefore turning this algorithm off must be considered + with caution as that can lead to basically zero throughput if + competing with other, loss based, traffic. -4.1.2.3. Lost packet detection +4.1.2.4. Lost packet detection Lost packet detection is based on the received sequence number list. - A reordering window SHOULD be applied to avoid packet reordering - triggering loss events. + A reordering window SHOULD be applied to avoid that packet reordering + triggers loss events. The reordering window is specified as a time unit, similar to the ideas behind RACK (Recent ACKnowledgement) [I-D.ietf-tcpm-rack]. The computation of the reordering window is made possible by means of a lost flag in the list of transmitted RTP packets. This flag is set if the received sequence number list indicates that the given RTP packet is missing. If a later feedback indicates that a previously lost marked packet was indeed received, then the reordering window is updated to reflect the reordering delay. The reordering window is given by the difference in time between the event that the packet was marked as lost and the event that it was indicated as successfully received. Loss is detected if a given RTP packet is not acknowledged within a time window (indicated by the reordering window) after an RTP packet with higher sequence number was acknowledged. -4.1.2.4. Send window calculation +4.1.2.5. 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 can lead to 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 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 + direction can 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 send window is adjusted depending on qdelay and its relation to the qdelay target and the relation between the congestion window and the number of bytes in flight. A strict rule is applied when qdelay is higher than qdelay_target, to avoid further queue buildup in the network. For cases when qdelay is lower than the qdelay_target, a more relaxed rule is applied. This allows the bitrate to increase @@ -922,86 +942,109 @@ if (qdelay <= qdelay_target) send_wnd = cwnd+MSS-bytes_in_flight else send_wnd = cwnd-bytes_in_flight end The send window is updated whenever an RTP packet is transmitted or an RTCP feedback messaged is received. -4.1.2.5. Packet pacing +4.1.2.6. Packet pacing Packet pacing is used in order to mitigate coalescing i.e. that packets are transmitted in bursts, with the increased risk of more - jitter and potentially increased packet loss. The time interval - between consecutive packet transmissions is enforced to be equal to - or higher than t_pace where t_pace is given by the equations below : + jitter and potentially increased packet loss. Packet pacing also + mitigates possible issues with queue overflow due to key-frame + generation in video coders. The time interval between consecutive + packet transmissions is enforced to be equal to or higher than t_pace + where t_pace is given by the equations below : pace_bitrate = max (RATE_PACE_MIN, cwnd* 8 / s_rtt) t_pace = rtp_size * 8 / pace_bitrate rtp_size is the size of the last transmitted RTP packet, s_rtt is the - smoothed round trip time. RATE_PACE_MIN=50000 is the minimum pacing - rate. + smoothed round trip time. RATE_PACE_MIN is the minimum pacing rate. -4.1.2.6. Resuming fast increase +4.1.2.7. Resuming fast increase Fast increase can resume in order to speed up the bitrate increase in case congestion abates. The condition to resume fast increase (in_fast_increase = true) is that qdelay_trend is less than QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more. +4.1.2.8. Stream prioritization + + The SCReAM algorithm makes a good distinction between network + congestion control and the media rate control. 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 [SCReAM-CPP-implementation] use credit based scheduling. In + credit based scheduling, credit is accumulated by queues as they wait + for service and are spent while the queues are being serviced. 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 relative + weights. The latter is also implemented in + [SCReAM-CPP-implementation]. + 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, qdelay_trend is also considered in the media rate control 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(s) 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 leading to the flow being starved out by other more - opportunistic traffic. On the other hand, a too aggressive setting - leads to increased jitter. + capacity leading to that the flow can become starved out by other + more opportunistic traffic. On the other hand, a too aggressive + setting leads to increased jitter. The 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). + TARGET_BITRATE_MIN SHOULD be chosen to a low enough value to avoid - RTP packets being queued up when the network throughput becomes low. - The sender SHOULD also be equipped with a mechanism that discards RTP - packets in cases where the network throughput becomes very low and - RTP packets are excessively delayed. + that RTP packets become queued up when the network throughput is + reduced. The sender SHOULD also be equipped with a mechanism that + discards RTP packets in cases where the network throughput becomes + very low and RTP packets are excessively delayed. 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 second. 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 + that can itself cause an unnecessary rate reduction. To overcome this shortcoming; rate_ack is used as well. This gives a more stable throughput estimate. The rate change behavior depends on whether a loss or ECN event has occurred and if the congestion control is in fast increase or not. # The target_bitrate is updated at a regular interval according # to RATE_ADJUST_INTERVAL @@ -1058,21 +1101,21 @@ continues. The rationale behind the rate reduction due to loss is that a congestion window reduction will take effect, a rate reduction pro actively avoids RTP packets being queued up when the transmit rate decreases due to the reduced congestion window. A similar rate reduction happens when ECN events are detected. The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless a loss event occurs. The value is based on experimentation with real life limitations in video coders taken into account [SCReAM-CPP-implementation]. A too short interval is shown to make - the video coder internal rate control loop more unstable, a too long + the rate control loop in video coders more unstable, a too long interval makes the overall congestion control sluggish. When in fast increase state (in_fast_increase=true), the bitrate increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . The ramp-up speed is limited when the target bitrate is low to avoid rate oscillation at low bottleneck bitrates. The setting of RAMP_UP_SPEED depends on preferences, a high setting such as 1000kbps/s makes it possible to quickly get high quality media, this is however at the expense of a increased jitter, which can manifest itself as e.g. choppy video rendering. @@ -1080,24 +1123,24 @@ 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 qdelay trend, thus it is sufficient that an increased congestion level is sensed by the network congestion control to limit the bitrate. The target_bitrate_last_max is updated when congestion is detected. Finally the target_bitrate is enforced to be within the defined min and max values. - The aware reader MAY notice the dependency on the qdelay in the + The aware reader may notice the dependency on the qdelay in the computation of the target bitrate, this manifests itself in the use of the qdelay_trend. As these parameters are used also in the - network congestion control one MAY suspect some odd interaction + network congestion control one may suspect 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 qdelay_trend 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 after congestion, at the expense of increased jitter in congested situations. 4.2. SCReAM Receiver @@ -1106,25 +1149,22 @@ SCReAM sender, in addition, the receive time of the RTP packet with the highest sequence number is echoed back. Upon reception of each RTP packet the receiver MUST maintain enough information to send the aforementioned values to the SCReAM sender via a RTCP transport layer feedback message. The frequency of the feedback message depends on the available RTCP bandwidth. The requirements on the feedback elements and the feedback interval is described. 4.2.1. Requirements on feedback elements - SCReAM requires the following elements for its basic functionality, - i.e. only including features that are strictly necessary in order to - make SCReAM function. ECN is not included as basic functionality as - it regarded as an additional feature that is not strictly necessary - even though it can improve quality of experience quite considerably. + The following feedback elements are REQUIRED for the basic + functionality in SCReAM. o A list of received RTP packets. This list SHOULD be sufficiently long to cover all received RTP packets. This list can be realized with the Loss RLE report block in [RFC3611]. o A wall clock timestamp corresponding to the received RTP packet with the highest sequence number is required in order to compute the qdelay. This can be realized by means of the Packet Receipt Times Report Block in [RFC3611]. begin_seq MUST be set to the highest received (possibly wrapped around) sequence number, @@ -1159,44 +1199,52 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt time of packet begin_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Basic feedback message for SCReAM, based on RFC3611 - In a typical use case, no more than four Loss RLE chunks SHOULD be - needed, thus the feedback message will be 44bytes. It is obvious - from the figure that there is a lot of redundant information in the - feedback message. A more optimized feedback format, including the - additional feedback elements listed below, could reduce the feedback - message size a bit. + In a typical use case, no more than four Loss RLE chunks are needed, + thus the feedback message will be 44bytes. It is obvious from the + figure that there is a lot of redundant information in the feedback + message. A more optimized feedback format, including the additional + feedback elements listed below, could reduce the feedback message + size a bit. Additional feedback elements that can improve the performance of SCReAM are: o Accumulated number of ECN-CE marked packets (n_ECN). This can for instance be realized with the ECN Feedback Report Format in [RFC6679]. The given feedback report format is actually a slight overkill as SCReAM would do quite well with only a counter that increments by one for each received packet with the ECN-CE code - point set. The more bulky format MAY be nevertheless be useful - for e.g ECN black-hole detection. + point set. The more bulky format could nevertheless be useful for + e.g ECN black-hole detection. 4.2.2. Requirements on feedback intensity - SCReAM benefits from a relatively frequent feedback. The feedback - interval depends on the media bitrate. At low bitrates it is - sufficient with a feedback interval of 100 to 400ms, while at high - bitrates a feedback interval of roughly 20ms is to prefer. + SCReAM benefits from a relatively frequent feedback. It is + RECOMMENDED that a SCReAM implementation follows the guidelines + below. + + The feedback interval depends on the media bitrate. At low bitrates + it is sufficient with a feedback interval of 100 to 400ms, while at + high bitrates a feedback interval of roughly 20ms is to prefer, at + very high bitrates, even shorter feedback intervals MAY be needed in + order to keep the self-clocking in SCReAM working well. One piece of + evidence of a too sparse feedback is that the SCReAM implementation + cannot reach high bitrates, even in uncongested links. A more + frequent feedback MAY solve this issue. The numbers above can be formulated as feedback interval function that can be useful for the computation of the desired RTCP bandwidth. The following equation expresses the feedback rate: rate_fb = min(50,max(2.5,rate_media/10000)) rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is the feedback rate expressed in [packets/s]. Converted to feedback interval we get: @@ -1204,43 +1252,43 @@ fb_int = 1.0/min(50,max(2.5,rate_media/10000)) The transmission interval is not critical, this means that in the case of multi-stream handling between two hosts, the feedback for two or more SSRCs can be bundled to save UDP/IP overhead, the final realized feedback interval SHOULD however not exceed 2*fb_int in such cases meaning that a scheduled feedback transmission event should not be delayed more that fb_int. SCReAM works with AVPF regular mode, immediate or early mode is not - REQUIRED by SCReAM but MAY nonetheless be useful for e.g RTCP + required by SCReAM but can nonetheless be useful for e.g RTCP messages not directly related to SCReAM, such as those specified in [RFC4585]. It is RECOMMENDED to use reduced size RTCP [RFC5506] where regular full compound RTCP transmission is controlled by trr- int as described in [RFC4585]. 5. Discussion This section covers a few discussion points o Clock drift: SCReAM can suffer from the same issues with clock drift as is the case with LEDBAT [RFC6817]. Section A.2 in [RFC6817] however describes ways to mitigate issues with clock drift. o Support for alternate ECN semantics: This specification adopts the proposal in [I-D.ietf-tcpm-alternativebackoff-ecn] to reduce the congestion window less when ECN based congestion events are detected. Future work on Low Loss Low Latency for Scalable - throughput (L4S) MAY lead to updates in a future RFC that + throughput (L4S) may lead to updates in a future RFC that describes SCReAM support for L4S. - o A new RFC4585 transport layer feedback message MAY to be + o A new RFC4585 transport layer feedback message could to be standardized if the use of the already existing RTCP extensions as described in Section 4.2 is not deemed sufficient. o The target bitrate given by SCReAM depicts the bitrate including RTP and FEC overhead. The media encoder SHOULD take this overhead into account when the media bitrate is set. This means that the media coder bitrate SHOULD be computed as media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate @@ -1348,58 +1396,62 @@ o Trials with different kinds of media: Audio, Video, slide show content. Evaluation of multi stream handling in SCReAM. o Evaluation of functionality of competing flows compensation mechanism: Evaluate how SCReAM performs with competing TCP like traffic and to what extent the competing flows compensation causes self-inflicted congestion. o Determine proper parameters: A set of default parameters are given that makes SCReAM work over a reasonably large operation range, - however for instance for very low or very high bitrates it MAY be + however for instance for very low or very high bitrates it may be necessary to use different values for instance for the RAMP_UP_SPEED. 8. 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 RMCAT chairs Karen E. E. Nielsen and Mirja Kuehlewind for patiently reading, suggesting improvements and also for asking all the difficult but necessary questions. Thanks to Stefan Holmer, Xiaoqing Zhu, Safiqul Islam and David Hayes for the additional review of this document. Thanks to Ralf Globisch for taking time to try out SCReAM in his challenging low bitrate use - cases. + cases, Robert Hedman for finding a few additional flaws in the + running code, and Gustavo Garcia and 'miseri' for code contributions. 9. IANA Considerations There is currently no request to IANA 10. Security Considerations The feedback can be vulnerable to attacks similar to those that can affect TCP. It is therefore RECOMMENDED that the RTCP feedback is at least integrity protected. Furthermore, as SCReAM is self-clocked, a malicious middlebox can drop RTCP feedback packets and thus cause the self-clocking in SCReAM to stall. This attack is however mitigated by the minimum send rate maintained by SCReAM when no feedback is received. 11. Change history A list of changes: + o WG-10 to WG-11: Review comments from Mirja + o WG-9 to WG-10: Minor edits + o WG-08 to WG-09: Updated based shepherd review by Martin Stiemerling, Q-bit semantics are removed as this is superfluous for the moment. Pacing and RTCP considerations are moved up from the appendix, FEC discussion moved to discussion section. o WG-07 to WG-08: Avoid draft expiry o WG-06 to WG-07: Updated based on WGLC review by David Hayes and Safiqul Islam @@ -1431,59 +1483,58 @@ 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 12. References 12.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, - . + . [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, . + 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, - . + . 12.2. Informative References [I-D.ietf-rmcat-coupled-cc] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion - control for RTP media", draft-ietf-rmcat-coupled-cc-06 - (work in progress), March 2017. + control for RTP media", draft-ietf-rmcat-coupled-cc-07 + (work in progress), September 2017. [I-D.ietf-rmcat-wireless-tests] Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and M. Ramalho, "Evaluation Test Cases for Interactive Real- Time Media over Wireless Networks", draft-ietf-rmcat- wireless-tests-04 (work in progress), May 2017. [I-D.ietf-tcpm-alternativebackoff-ecn] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- @@ -1505,92 +1556,69 @@ [Packet-conservation] "Congestion Avoidance and Control, ACM SIGCOMM Computer Communication Review 1988", 1988. [QoS-3GPP] TS 23.203, 3GPP., "Policy and charging control architecture", June 2011, . + [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, . + [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, - . + . [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, . + 2012, . + + [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- + Time Communication Use Cases and Requirements", RFC 7478, + DOI 10.17487/RFC7478, March 2015, + . [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating TCP to Support Rate-Limited Traffic", RFC 7661, DOI 10.17487/RFC7661, October 2015, - . + . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, - . + . [SCReAM-CPP-implementation] "C++ Implementation of SCReAM", . [SCReAM-implementation] "SCReAM Implementation", - . + . [SCReAM-implementation-experience] "Updates on SCReAM : An implementation experience", - . + . [TFWC] University College London, "Fairer TCP-Friendly Congestion Control Protocol for Multimedia Streaming", December 2007, . -Appendix A. Additional information - -A.1. Stream prioritization - - The SCReAM algorithm makes a good distinction between network - congestion control and the media rate control. 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 [SCReAM-CPP-implementation] use credit based scheduling. In - credit based scheduling, credit is accumulated by queues as they wait - for service and are spent while the queues are being serviced. 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 relative - weights. - -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 biased autocorrelation - function for a given lag=k for the vector x is given by . - - n=N-k - R(x,k) = SUM x(n)*x(n+k) - n=1 - Authors' Addresses Ingemar Johansson Ericsson AB Laboratoriegraend 11 Luleaa 977 53 Sweden Phone: +46 730783289 Email: ingemar.s.johansson@ericsson.com