idnits 2.17.1 draft-ietf-rmcat-scream-cc-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2017) is 2368 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '20' on line 514 -- Looks like a reference, but probably isn't: '100' on line 523 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-coupled-cc-07 == Outdated reference: A later version (-11) exists of draft-ietf-rmcat-wireless-tests-04 == Outdated reference: A later version (-12) exists of draft-ietf-tcpm-alternativebackoff-ecn-02 == Outdated reference: A later version (-15) exists of draft-ietf-tcpm-rack-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMCAT WG I. Johansson 3 Internet-Draft Z. Sarker 4 Intended status: Experimental Ericsson AB 5 Expires: April 29, 2018 October 26, 2017 7 Self-Clocked Rate Adaptation for Multimedia 8 draft-ietf-rmcat-scream-cc-13 10 Abstract 12 This memo describes a rate adaptation algorithm for conversational 13 media services such as interactive video. The solution conforms to 14 the packet conservation principle and uses a hybrid loss and delay 15 based congestion control algorithm. The algorithm is evaluated over 16 both simulated Internet bottleneck scenarios as well as in a Long 17 Term Evolution (LTE) system simulator and is shown to achieve both 18 low latency and high video throughput in these scenarios. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 29, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 56 1.2. Why is it a self-clocked algorithm? . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 4 59 3.1. Network Congestion Control . . . . . . . . . . . . . . . 7 60 3.2. Sender Transmission Control . . . . . . . . . . . . . . . 8 61 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 8 62 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 9 63 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 9 64 4.1.1. Constants and Parameter values . . . . . . . . . . . 9 65 4.1.1.1. Constants . . . . . . . . . . . . . . . . . . . . 10 66 4.1.1.2. State variables . . . . . . . . . . . . . . . . . 11 67 4.1.2. Network congestion control . . . . . . . . . . . . . 13 68 4.1.2.1. Reaction to packets loss and ECN . . . . . . . . 16 69 4.1.2.2. Congestion window update . . . . . . . . . . . . 16 70 4.1.2.3. Competing flows compensation . . . . . . . . . . 19 71 4.1.2.4. Lost packet detection . . . . . . . . . . . . . . 21 72 4.1.2.5. Send window calculation . . . . . . . . . . . . . 22 73 4.1.2.6. Packet pacing . . . . . . . . . . . . . . . . . . 23 74 4.1.2.7. Resuming fast increase . . . . . . . . . . . . . 23 75 4.1.2.8. Stream prioritization . . . . . . . . . . . . . . 23 76 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 24 77 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 27 78 4.2.1. Requirements on feedback elements . . . . . . . . . . 27 79 4.2.2. Requirements on feedback intensity . . . . . . . . . 29 80 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 29 81 6. Implementation status . . . . . . . . . . . . . . . . . . . . 30 82 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 31 83 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 31 84 7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 32 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 88 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 33 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 35 91 12.2. Informative References . . . . . . . . . . . . . . . . . 35 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 94 1. Introduction 96 Congestion in the Internet occurs when the transmitted bitrate is 97 higher than the available capacity over a given transmission path. 98 Applications that are deployed in the Internet have to employ 99 congestion control, to achieve robust performance and to avoid 100 congestion collapse in the Internet. Interactive realtime 101 communication imposes a lot of requirements on the transport, 102 therefore a robust, efficient rate adaptation for all access types is 103 an important part of interactive realtime communications as the 104 transmission channel bandwidth can vary over time. Wireless access 105 such as LTE, which is an integral part of the current Internet, 106 increases the importance of rate adaptation as the channel bandwidth 107 of a default LTE bearer [QoS-3GPP] can change considerably in a very 108 short time frame. Thus a rate adaptation solution for interactive 109 realtime media, such as WebRTC, should be both quick and be able to 110 operate over a large range in channel capacity. This memo describes 111 SCReAM (Self-Clocked Rate Adaptation for Multimedia), a solution that 112 implements congestion control for RTP streams [RFC3550]. While 113 SCReAM was originally devised for WebRTC (Web Real-Time 114 Communication) [RFC7478], it can also be used for other applications 115 where congestion control of RTP streams is necessary. SCReAM is 116 based on the self-clocking principle of TCP and uses techniques 117 similar to what is used in the LEDBAT based rate adaptation algorithm 118 [RFC6817]. SCReAM is not entirely self-clocked as it augments self- 119 clocking with pacing and a minimum send rate. 120 SCReAM can take advantage of ECN (Explicit Congestion Notification) 121 in cases where ECN is supported by the network and the hosts. ECN is 122 however not required for the basic congestion control functionality 123 in SCReAM. 125 1.1. Wireless (LTE) access properties 127 [I-D.ietf-rmcat-wireless-tests] describes the complications that can 128 be observed in wireless environments. Wireless access such as LTE 129 can typically not guarantee a given bandwidth, this is true 130 especially for default bearers. The network throughput can vary 131 considerably for instance in cases where the wireless terminal is 132 moving around. Even though LTE can support bitrates well above 133 100Mbps, there are cases when the available bitrate can be much 134 lower, examples are situations with high network load and poor 135 coverage. An additional complication is that the network throughput 136 can drop for short time intervals at e.g. handover, these short 137 glitches are initially very difficult to distinguish from more 138 permanent reductions in throughput. 140 Unlike wireline bottlenecks with large statistical multiplexing it is 141 not possible to try to maintain a given bitrate when congestion is 142 detected with the hope that other flows will yield, this is because 143 there are generally few other flows competing for the same 144 bottleneck. Each user gets its own variable throughput bottleneck, 145 where the throughput depends on factors like channel quality, network 146 load and historical throughput. The bottom line is, if the 147 throughput drops, the sender has no other option than to reduce the 148 bitrate. Once the radio scheduler has reduced the resource 149 allocation for a bearer, an RMCAT flow in that bearer aims to reduce 150 the sending rate quite quickly (within one RTT) in order to avoid 151 excessive queuing delay or packet loss. 153 1.2. Why is it a self-clocked algorithm? 155 Self-clocked congestion control algorithms provide a benefit over the 156 rate based counterparts in that the former consists of two adaptation 157 mechanisms: 159 o A congestion window computation that evolves over a longer 160 timescale (several RTTs) especially when the congestion window 161 evolution is dictated by estimated delay (to minimize 162 vulnerability to e.g. short term delay variations). 164 o A fine grained congestion control given by the self-clocking which 165 operates on a shorter time scale (1 RTT). The benefits of self- 166 clocking are also elaborated upon in [TFWC]. 168 A rate based congestion control typically adjusts the rate based on 169 delay and loss. The congestion detection needs to be done with a 170 certain time lag to avoid over-reaction to spurious congestion events 171 such as delay spikes. Despite the fact that there are two or more 172 congestion indications, the outcome is still that there is still only 173 one mechanism to adjust the sending rate. This makes it difficult to 174 reach the goals of high throughput and prompt reaction to congestion. 176 2. Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 3. Overview of SCReAM Algorithm 184 The core SCReAM algorithm has similarities to the concepts of self- 185 clocking used in TFWC [TFWC] and follows the packet conservation 186 principle. The packet conservation principle is described as an 187 important key-factor behind the protection of networks from 188 congestion [Packet-conservation]. 190 In SCReAM, the receiver of the media echoes a list of received RTP 191 packets and the timestamp of the RTP packet with the highest sequence 192 number back to the sender in feedback packets. The sender keeps a 193 list of transmitted packets, their respective sizes and the time they 194 were transmitted. This information is used to determine the number 195 of bytes that can be transmitted at any given time instant. A 196 congestion window puts an upper limit on how many bytes can be in 197 flight, i.e. transmitted but not yet acknowledged. 199 The congestion window is determined in a way similar to LEDBAT 200 [RFC6817]. LEDBAT is a congestion control algorithm that uses send 201 and receive timestamps to estimate the queuing delay (from now on 202 denoted qdelay) along the transmission path. This information is 203 used to adjust the congestion window. The use of LEDBAT ensures that 204 the end-to-end latency is kept low. [LEDBAT-delay-impact] shows that 205 LEDBAT has certain inherent issues that makes it counteract its 206 purpose to achieve low delay. The general problem described in the 207 paper is that the base delay is offset by LEDBAT's own queue buildup. 208 The big difference with using LEDBAT in the SCReAM context lies in 209 the fact that the source is rate limited and that it is required that 210 the RTP queue is kept short (preferably empty). In addition the 211 output from a video encoder is rarely constant bitrate, static 212 content (talking heads) for instance gives almost zero video bitrate. 213 This gives two useful properties when LEDBAT is used with SCReAM that 214 help to avoid the issues described in [LEDBAT-delay-impact]: 216 1. There is always a certain probability that SCReAM is short of 217 data to transmit, which means that the network queue will run 218 empty every once in a while. 220 2. The max video bitrate can be lower than the link capacity. If 221 the max video bitrate is 5Mbps and the capacity is 10Mbps then 222 the network queue will run empty. 224 It is sufficient that any of the two conditions above is fulfilled to 225 make the base delay update properly. Furthermore 226 [LEDBAT-delay-impact] describes an issue with short lived competing 227 flows, the case in SCReAM is that these short lived flows will cause 228 the self-clocking in SCReAM to slow down with the result that the RTP 229 queue is built up, which will in turn result in a reduced media video 230 bitrate. SCReAM will thus yield more to competing short lived flows 231 than what is the case with traditional use of LEDBAT. 232 The basic functionality in the use of LEDBAT in SCReAM is quite 233 simple, there are however a few steps to take to make the concept 234 work with conversational media: 236 o Congestion window validation techniques. These are similar in 237 action as the method described in [RFC7661]. Congestion window 238 validation ensures that the congestion window is limited by the 239 actual number bytes in flight, this is important especially in the 240 context of rate limited sources such as video. Lack of congestion 241 window validation would lead to a slow reaction to congestion as 242 the congestion window does not properly reflect the congestion 243 state in the network. The allowed idle period in this memo is 244 shorter than in [RFC7661], this to avoid excessive delays in the 245 cases where e.g. wireless throughput has decreased during a period 246 where the output bitrate from the media coder has been low, for 247 instance due to inactivity. Furthermore, this memo allows for 248 more relaxed rules for when the congestion window is allowed to 249 grow, this is necessary as the variable output bitrate generally 250 means that the congestion window is often under-utilized. 252 o Fast increase makes the bitrate increase faster when no congestion 253 is detected. It makes the media bitrate ramp-up within 5 to 10 254 seconds. The behavior is similar to TCP slowstart. The fast 255 increase is exited when congestion is detected. The fast increase 256 state can however resume if the congestion level is low, this 257 enables a reasonably quick rate increase in case link throughput 258 increases. 260 o A qdelay trend is computed for earlier detection of incipient 261 congestion and as a result it reduces jitter. 263 o Addition of a media rate control function. 265 o Use of inflection points in the media rate calculation to achieve 266 reduced jitter. 268 o Adjustment of qdelay target for better performance when competing 269 with other loss based congestion controlled flows. 271 The above mentioned features will be described in more detail in 272 sections Section 3.1 to Section 3.3. The full details are described 273 in Section 4. 275 +---------------------------+ 276 | Media encoder | 277 +---------------------------+ 278 ^ | 279 | |(1) 280 |(3) RTP 281 | V 282 | +-----------+ 283 +---------+ | | 284 | Media | (2) | Queue | 285 | rate |<------| | 286 | control | |RTP packets| 287 +---------+ | | 288 +-----------+ 289 | 290 |(4) 291 RTP 292 | 293 v 294 +------------+ +--------------+ 295 | Network | (7) | Sender | 296 +-->| congestion |------>| Transmission | 297 | | control | | Control | 298 | +------------+ +--------------+ 299 | | 300 |-------------RTCP----------| |(5) 301 (6) | RTP 302 | v 303 +------------+ 304 | UDP | 305 | socket | 306 +------------+ 308 Figure 1: SCReAM sender functional view 310 The SCReAM algorithm consists of three main parts: network congestion 311 control, sender transmission control and media rate control. All of 312 these three parts reside at the sender side. Figure 1 shows the 313 functional overview of a SCReAM sender. The receiver side algorithm 314 is very simple in comparison as it only generates feedback containing 315 acknowledgements of received RTP packets and an ECN count. 317 3.1. Network Congestion Control 319 The network congestion control sets an upper limit on how much data 320 can be in the network (bytes in flight); this limit is called CWND 321 (congestion window) and is used in the sender transmission control. 323 The SCReAM congestion control method, uses techniques similar to 324 LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT, 325 it is not necessary to use synchronized clocks in sender and receiver 326 in order to compute the qdelay. It is however necessary that they 327 use the same clock frequency, or that the clock frequency at the 328 receiver can be inferred reliably by the sender. Failure to meet 329 this requirement leads to malfunction in the SCReAM congestion 330 control algorithm due to incorrect estimation of the network queue 331 delay. 333 The SCReAM sender calculates the congestion window based on the 334 feedback from the SCReAM receiver. The congestion window is allowed 335 to increase if the qdelay is below a predefined qdelay target, 336 otherwise the congestion window decreases. The qdelay target is 337 typically set to 50-100ms. This ensures that the queuing delay is 338 kept low. The reaction to loss or ECN events leads to an instant 339 reduction of CWND. Note that the source rate limited nature of real 340 time media such as video, typically means that the queuing delay will 341 mostly be below the given delay target, this is contrary to the case 342 where large files are transmitted using LEDBAT congestion control, in 343 which case the queuing delay will stay close to the delay target. 345 3.2. Sender Transmission Control 347 The sender transmission control limits the output of data, given by 348 the relation between the number of bytes in flight and the congestion 349 window. Packet pacing is used to mitigate issues with ACK 350 compression that MAY cause increased jitter and/or packet loss in the 351 media traffic. Packet pacing limits the packet transmission rate 352 given by the estimated link throughput. Even if the send window 353 allows for the transmission of a number of packets, these packets are 354 not transmitted immediately, but rather they are transmitted in 355 intervals given by the packet size and the estimated link throughput. 357 3.3. Media Rate Control 359 The media rate control serves to adjust the media bitrate to ramp-up 360 quickly enough to get a fair share of the system resources when link 361 throughput increases. 363 The reaction to reduced throughput MUST be prompt in order to avoid 364 getting too much data queued in the RTP packet queue(s) in the 365 sender. The media bitrate is decreased if the RTP queue size exceeds 366 a threshold. 368 In cases where the sender frame queues increase rapidly such as in 369 the case of a RAT (Radio Access Type) handover it MAY be necessary to 370 implement additional actions, such as discarding of encoded media 371 frames or frame skipping in order to ensure that the RTP queues are 372 drained quickly. Frame skipping results in the frame rate being 373 temporarily reduced. Which method to use is a design choice and 374 outside the scope of this algorithm description. 376 4. Detailed Description of SCReAM 378 4.1. SCReAM Sender 380 This section describes the sender side algorithm in more detail. It 381 is split between the network congestion control, sender transmission 382 control and the media rate control. 384 A SCReAM sender implements media rate control and an RTP queue for 385 each media type or source, where RTP packets containing encoded media 386 frames are temporarily stored for transmission. Figure 1 shows the 387 details when a single media source (or stream) is used. A 388 transmission scheduler (not shown in the figure) is added to support 389 multiple streams. The transmission scheduler can enforce differing 390 priorities between the streams and act like a coupled congestion 391 controller for multiple flows. Support for multiple streams is 392 implemented in [SCReAM-CPP-implementation]. 394 Media frames are encoded and forwarded to the RTP queue (1) in 395 Figure 1. The media rate adaptation adapts to the size of the RTP 396 queue (2) and provides a target rate for the media encoder (3). The 397 RTP packets are picked from the RTP queue (for multiple flows from 398 each RTP queue based on some defined priority order or simply in a 399 round robin fashion) (4) by the sender transmission controller. The 400 sender transmission controller (in case of multiple flows a 401 transmission scheduler) sends the RTP packets to the UDP socket (5). 402 In the general case all media SHOULD go through the sender 403 transmission controller and is limited so that the number of bytes in 404 flight is less than the congestion window. RTCP packets are received 405 (6) and the information about bytes in flight and congestion window 406 is exchanged between the network congestion control and the sender 407 transmission control (7). 409 4.1.1. Constants and Parameter values 411 Constants and state variables are listed in this section. Temporary 412 variables are not listed, instead they are appended with '_t' in the 413 pseudo code to indicate their local scope. 415 4.1.1.1. Constants 417 The RECOMMENDED values, within (), for the constants are deduced from 418 experiments. The units are enclosed in square brackets [ ]. 420 QDELAY_TARGET_LO (0.1s) 421 Target value for the minimum qdelay. 423 QDELAY_TARGET_HI (0.4s) 424 Target value for the maximum qdelay. This parameter provides an 425 upper limit to how much the target qdelay (qdelay_target) can be 426 increased in order to cope with competing loss based flows. The 427 target qdelay does not have to be initialized to this high value 428 however as it would increase e2e delay and also make the rate 429 control and congestion control loop sluggish. 431 QDELAY_WEIGHT (0.1) 432 Averaging factor for qdelay_fraction_avg. 434 QDELAY_TREND_TH (0.2) 435 Threshold for the detection of incipient congestion. 437 MIN_CWND (3000byte) 438 Minimum congestion window. 440 MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1) 441 Headroom for the limitation of CWND. 443 GAIN (1.0) 444 Gain factor for congestion window adjustment. 446 BETA_LOSS (0.8) 447 CWND scale factor due to loss event. 449 BETA_ECN (0.9) 450 CWND scale factor due to ECN event. 452 BETA_R (0.9) 453 Target rate scale factor due to loss event. 455 MSS (1000 byte) 456 Maximum segment size = Max RTP packet size. 458 RATE_ADJUST_INTERVAL (0.2s) 459 Interval between media bitrate adjustments. 461 TARGET_BITRATE_MIN 462 Min target bitrate [bps], bps is bits per second. 464 TARGET_BITRATE_MAX 465 Max target bitrate [bps]. 467 RAMP_UP_SPEED (200000bps/s) 468 Maximum allowed rate increase speed. 470 PRE_CONGESTION_GUARD (0.0..1.0) 471 Guard factor against early congestion onset. A higher value gives 472 less jitter, possibly at the expense of a lower link utilization. 473 This value MAY be subject to tuning depending on e.g media coder 474 characteristics, experiments with H264 and VP8 indicate that 0.1 is 475 a suitable value. See [SCReAM-CPP-implementation] and 476 [SCReAM-implementation-experience] for evaluation of a real 477 implementation. 479 TX_QUEUE_SIZE_FACTOR (0.0..2.0) 480 Guard factor against RTP queue buildup. This value MAY be subject 481 to tuning depending on e.g media coder characteristics, experiments 482 with H264 and VP8 indicate that 1.0 is a suitable value. See 483 [SCReAM-CPP-implementation] and [SCReAM-implementation-experience] 484 for evaluation of a real implementation. 486 RTP_QDELAY_TH (0.02s) RTP queue delay threshold for a target rate 487 reduction. 489 TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP 490 qdelay threshold exceeds RTP_QDELAY_TH. 492 QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend. 494 T_RESUME_FAST_INCREASE (5s) Time span until fast increase can be 495 resumed, given that the qdelay_trend is below QDELAY_TREND_LO. 497 RATE_PACE_MIN (50000bps) Minimum pacing rate. 499 4.1.1.2. State variables 501 The values within () indicate initial values. 503 qdelay_target (QDELAY_TARGET_LO) 504 qdelay target, a variable qdelay target is introduced to manage 505 cases where e.g. FTP competes for the bandwidth over the same 506 bottleneck, a fixed qdelay target would otherwise starve the RMCAT 507 flow under such circumstances. The qdelay target is allowed to 508 vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI. 510 qdelay_fraction_avg (0.0) 511 EWMA (Exponentially Weighted Moving Average) filtered fractional 512 qdelay. 514 qdelay_fraction_hist[20] ({0,..,0}) 515 Vector of the last 20 fractional qdelay samples. 517 qdelay_trend (0.0) 518 qdelay trend, indicates incipient congestion. 520 qdelay_trend_mem (0.0) 521 Low pass filtered version of qdelay_trend. 523 qdelay_norm_hist[100] ({0,..,0}) 524 Vector of the last 100 normalized qdelay samples. 526 in_fast_increase (true) 527 True if in fast increase state. 529 cwnd (MIN_CWND) 530 Congestion window. 532 bytes_newly_acked (0) 533 The number of bytes that was acknowledged with the last received 534 acknowledgement i.e. bytes acknowledged since the last CWND update. 536 max_bytes_in_flight (0) 537 The maximum number of bytes in flight over a sliding time window, 538 i.e. transmitted but not yet acknowledged bytes. 540 send_wnd (0) 541 Upper limit to how many bytes that can currently be transmitted. 542 Updated when cwnd is updated and when RTP packet is transmitted. 544 target_bitrate (0 bps) 545 Media target bitrate. 547 target_bitrate_last_max (1 bps) 548 Media target bitrate inflection point i.e. the last known highest 549 target_bitrate. Used to limit bitrate increase speed close to the 550 last known congestion point. 552 rate_transmit (0.0 bps) 553 Measured transmit bitrate. 555 rate_ack (0.0 bps) 556 Measured throughput based on received acknowledgements. 558 rate_media (0.0 bps) 559 Measured bitrate from the media encoder. 561 rate_media_median (0.0 bps) 562 Median value of rate_media, computed over more than 10s. 564 s_rtt (0.0s) 565 Smoothed RTT [s], computed with a similar method to that described 566 in [RFC6298]. 568 rtp_queue_size (0 bits) 569 Sum of the sizes of RTP packets in queue. 571 rtp_size (0 byte) 572 Size of the last transmitted RTP packet. 574 loss_event_rate (0.0) 575 The estimated fraction of RTTs with lost packets detected. 577 4.1.2. Network congestion control 579 This section explains the network congestion control, it contains two 580 main functions: 582 o Computation of congestion window at the sender: Gives an upper 583 limit to the number of bytes in flight. 585 o Calculation of send window at the sender: RTP packets are 586 transmitted if allowed by the relation between the number of bytes 587 in flight and the congestion window. This is controlled by the 588 send window. 590 SCReAM is a window based and byte oriented congestion control 591 protocol, where the number of bytes transmitted is inferred from the 592 size of the transmitted RTP packets. Thus a list of transmitted RTP 593 packets and their respective transmission times (wall-clock time) 594 MUST be kept for further calculation. 596 The number of bytes in flight (bytes_in_flight) is computed as the 597 sum of the sizes of the RTP packets ranging from the RTP packet most 598 recently transmitted down to but not including the acknowledged 599 packet with the highest sequence number. This can be translated to 600 the difference between the highest transmitted byte sequence number 601 and the highest acknowledged byte sequence number. As an example: If 602 RTP packet with sequence number SN is transmitted and the last 603 acknowledgement indicates SN-5 as the highest received sequence 604 number then bytes in flight is computed as the sum of the size of RTP 605 packets with sequence number SN-4, SN-3, SN-2, SN-1 and SN, it does 606 not matter if for instance packet with sequence number SN-3 was lost, 607 the size of RTP packet with sequence number SN-3 will still be 608 considered in the computation of bytes_in_flight. 610 Furthermore, a variable bytes_newly_acked is incremented with a value 611 corresponding to how much the highest sequence number has increased 612 since the last feedback. As an example: If the previous 613 acknowledgement indicated the highest sequence number N and the new 614 acknowledgement indicated N+3, then bytes_newly_acked is incremented 615 by a value equal to the sum of the sizes of RTP packets with sequence 616 number N+1, N+2 and N+3. Packets that are lost are also included, 617 which means that even though e.g packet N+2 was lost, its size is 618 still included in the update of bytes_newly_acked. The 619 bytes_newly_acked variable is reset to zero after a CWND update. 621 The feedback from the receiver is assumed to consist of the following 622 elements. 624 o A list of received RTP packets' sequence numbers. 626 o The wall clock timestamp corresponding to the received RTP packet 627 with the highest sequence number. 629 o Accumulated number of ECN-CE marked packets (n_ECN). 631 When the sender receives RTCP feedback, the qdelay is calculated as 632 outlined in [RFC6817]. A qdelay sample is obtained for each received 633 acknowledgement. No smoothing of the qdelay samples occur, however 634 some smoothing occurs anyway as the computation of the CWND is a low 635 pass filter function. A number of variables are updated as 636 illustrated by the pseudo code below, temporary variables are 637 appended with '_t'. As mentioned in Section 7 , calculation of the 638 proper congestion window and media bitrate may benefit from 639 additional optimizations for handling of very high and very low 640 bitrates, and from additional damping to handle periodic packet 641 bursts. Some such optimizations are implemented in 642 [SCReAM-CPP-implementation], but they do not form part of the 643 specification of SCReAM at this time. 645 646 update_variables(qdelay): 647 qdelay_fraction_t = qdelay/qdelay_target 648 # Calculate moving average 649 qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+ 650 QDELAY_WEIGHT*qdelay_fraction_t 651 update_qdelay_fraction_hist(qdelay_fraction_t) 652 # Compute the average of the values in qdelay_fraction_hist 653 avg_t = average(qdelay_fraction_hist) 654 # R is an autocorrelation function of qdelay_fraction_hist, 655 # with the mean (DC component) removed, at lag K 656 # The subtraction of the scalar avg_t from 657 # qdelay_fraction_hist is performed element-wise 658 a_t = R(qdelay_fraction_hist-avg_t,1)/ 659 R(qdelay_fraction_hist-avg_t,0) 660 # Calculate qdelay trend 661 qdelay_trend = min(1.0,max(0.0,a_t*qdelay_fraction_avg)) 662 # Calculate a 'peak-hold' qdelay_trend, this gives a memory 663 # of congestion in the past 664 qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend) 665 667 The qdelay fraction is sampled every 50ms and the last 20 samples are 668 stored in a vector (qdelay_fraction_hist). This vector is used in 669 the computation of an qdelay trend that gives a value between 0.0 and 670 1.0 depending on the estimated congestion level. The prediction 671 coefficient 'a_t' has positive values if qdelay shows an increasing 672 or decreasing trend, thus an indication of congestion is obtained 673 before the qdelay target is reached. As a side effect, also the case 674 that qdelay decreases is taken as a sign of congestion, experiments 675 have however shown that this is beneficial as varying queue delay up 676 or down is an indication that the transmit rate is very close to the 677 path capacity. 679 The autocorrelation function 'R' is defined as follows. Let x be a 680 vector constituting N values, the biased autocorrelation function for 681 a given lag=k for the vector x is given by. 683 n=N-k 684 R(x,k) = SUM x(n)*x(n+k) 685 n=1 687 The prediction coefficient is further multiplied with 688 qdelay_fraction_avg to reduce sensitivity to increasing qdelay when 689 it is very small. The 50ms sampling is a simplification that could 690 have the effect that the same qdelay is sampled several times, this 691 does however not pose any problem as the vector is only used to 692 determine if the qdelay is increasing or decreasing. The 693 qdelay_trend is utilized in the media rate control to indicate 694 incipient congestion and to determine when to exit from fast increase 695 mode. qdelay_trend_mem is used to enforce a less aggressive rate 696 increase after congestion events. The function 697 update_qdelay_fraction_hist(..) removes the oldest element and adds 698 the latest qdelay_fraction element to the qdelay_fraction_hist 699 vector. 701 4.1.2.1. Reaction to packets loss and ECN 703 A loss event is indicated if one or more RTP packets are declared 704 missing. The loss detection is described in Section 4.1.2.4. Once a 705 loss event is detected, further detected lost RTP packets SHOULD be 706 ignored for a full smoothed round trip time, the intention of this is 707 to limit the congestion window decrease to at most once per round 708 trip. 709 The congestion window back off due to loss events is deliberately a 710 bit less than is the case with e.g. TCP Reno. The reason is that 711 TCP is generally used to transmit whole files, which can be 712 translated to an infinite source bitrate. SCReAM on the other hand 713 has a source whose rate is limited to a value close to the available 714 transmit rate and often below that value, the effect of this is that 715 SCReAM has less opportunity to grab free capacity than a TCP based 716 file transfer. To compensate for this it is RECOMMENDED to let 717 SCReAM reduce the congestion window less than what is the case with 718 TCP when loss events occur. 720 An ECN event is detected if the n_ECN counter in the feedback report 721 has increased since the previous received feedback. Once an ECN 722 event is detected, the n_ECN counter is ignored for a full smoothed 723 round trip time, the intention of this is to limit the congestion 724 window decrease to at most once per round trip. The congestion 725 window back off due to an ECN event MAY be smaller than if a loss 726 event occurs. This is in line with the idea outlined in 727 [I-D.ietf-tcpm-alternativebackoff-ecn] to enable ECN marking 728 thresholds lower than the corresponding packet drop thresholds. 730 4.1.2.2. Congestion window update 732 The update of the congestion window depends on whether loss or ECN- 733 marking or neither occurs. The pseudo code below describes actions 734 taken in case of the different events. 736 737 on congestion event(qdelay): 738 # Either loss or ECN mark is detected 739 in_fast_increase = false 740 if (is loss) 741 # Loss is detected 742 cwnd = max(MIN_CWND,cwnd*BETA_LOSS) 743 else 744 # No loss, so it is then an ECN mark 745 cwnd = max(MIN_CWND,cwnd*BETA_ECN) 746 end 747 adjust_qdelay_target(qdelay) #compensating for competing flows 748 calculate_send_window(qdelay,qdelay_target) 750 # When no congestion event 751 on acknowledgement(qdelay): 752 update_bytes_newly_acked() 753 update_cwnd(bytes_newly_acked) 754 adjust_qdelay_target(qdelay) #compensating for competing flows 755 calculate_send_window(qdelay, qdelay_target) 756 check_to_resume_fast_increase() 757 759 The methods are further described in detail below. 761 The congestion window update is based on qdelay, except for the 762 occurrence of loss events (one or more lost RTP packets in one RTT), 763 or ECN events, which was described earlier. 765 Pseudo code for the update of the congestion window is found below. 767 768 update_cwnd(bytes_newly_acked): 769 # In fast increase ? 770 if (in_fast_increase) 771 if (qdelay_trend >= QDELAY_TREND_TH) 772 # Incipient congestion detected, exit fast increase 773 in_fast_increase = false 774 else 775 # No congestion yet, increase cwnd if it 776 # is sufficiently used 777 # An additional slack of bytes_newly_acked is 778 # added to ensure that CWND growth occurs 779 # even when feedback is sparse 780 if (bytes_in_flight*1.5+bytes_newly_acked > cwnd) 781 cwnd = cwnd+bytes_newly_acked 782 end 783 return 784 end 785 end 787 # Not in fast increase phase 788 # off_target calculated as with LEDBAT 789 off_target_t = (qdelay_target - qdelay) / qdelay_target 791 gain_t = GAIN 792 # Adjust congestion window 793 cwnd_delta_t = 794 gain_t * off_target_t * bytes_newly_acked * MSS / cwnd 795 if (off_target_t > 0 && 796 bytes_in_flight*1.25+bytes_newly_acked <= cwnd) 797 # No cwnd increase if window is underutilized 798 # An additional slack of bytes_newly_acked is 799 # added to ensure that CWND growth occurs 800 # even when feedback is sparse 801 cwnd_delta_t = 0; 802 end 804 # Apply delta 805 cwnd += cwnd_delta_t 806 # limit cwnd to the maximum number of bytes in flight 807 cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM) 808 cwnd = max(cwnd, MIN_CWND) 810 812 CWND is updated differently depending on whether the congestion 813 control is in fast increase state or not, as controlled by the 814 variable in_fast_increase. 816 When in fast increase state, the congestion window is increased with 817 the number of newly acknowledged bytes as long as the window is 818 sufficiently used. Sparse feedback can potentially limit congestion 819 window growth, an additional slack is therefore added, given by the 820 number of newly acknowledged bytes. 822 The congestion window growth when in_fast_increase is false is 823 dictated by the relation between qdelay and qdelay_target, congestion 824 window growth is limited if the window is not used sufficiently. 826 SCReAM calculates the GAIN in a similar way to what is specified in 827 [RFC6817]. However, [RFC6817] specifies that the CWND increase is 828 limited by an additional function controlled by a constant 829 ALLOWED_INCREASE. This additional limitation is removed in this 830 specification. 832 Further the CWND is limited by max_bytes_in_flight and MIN_CWND. The 833 limitation of the congestion window by the maximum number of bytes in 834 flight over the last 5 seconds (max_bytes_in_flight) avoids possible 835 over-estimation of the throughput after for example, idle periods. 836 An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to 837 allow for a certain amount of media coder output rate variability. 839 4.1.2.3. Competing flows compensation 841 It is likely that a flow using SCReAM algorithm will have to share 842 congested bottlenecks with other flows that use a more aggressive 843 congestion control algorithm, examples are large FTP flows using loss 844 based congestion control. The worst condition occurs when the 845 bottleneck queues are of tail-drop type with a large buffer size. 846 SCReAM takes care of such situations by adjusting the qdelay_target 847 when loss based flows are detected, as given by the pseudo code 848 below. 850 851 adjust_qdelay_target(qdelay) 852 qdelay_norm_t = qdelay / QDELAY_TARGET_LOW 853 update_qdelay_norm_history(qdelay_norm_t) 854 # Compute variance 855 qdelay_norm_var_t = VARIANCE(qdelay_norm_history(200)) 856 # Compensation for competing traffic 857 # Compute average 858 qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50)) 859 # Compute upper limit to target delay 860 new_target_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t) 861 new_target_t *= QDELAY_TARGET_LO 862 if (loss_event_rate > 0.002) 863 # Packet losses detected 864 qdelay_target = 1.5*new_target_t 865 else 866 if (qdelay_norm_var_t < 0.2) 867 # Reasonably safe to set target qdelay 868 qdelay_target = new_target_t 869 else 870 # Check if target delay can be reduced, this helps to avoid 871 # that the target delay is locked to high values for ever 872 if (new_target_t < QDELAY_TARGET_LO) 873 # Decrease target delay quickly as measured queueing 874 # delay is lower than target 875 qdelay_target = max(qdelay_target*0.5,new_target_t) 876 else 877 # Decrease target delay slowly 878 qdelay_target *= 0.9 879 end 880 end 881 end 883 # Apply limits 884 qdelay_target = min(QDELAY_TARGET_HI, qdelay_target) 885 qdelay_target = max(QDELAY_TARGET_LO, qdelay_target) 886 888 Two temporary variables are calculated. qdelay_norm_avg_t is the long 889 term average queue delay, qdelay_norm_var_t is the long term variance 890 of the queue delay. A high qdelay_norm_var_t indicates that the 891 queue delay changes, this can be an indication of reduced bottleneck 892 bandwidth or that a competing flow has just entered. Thus, it 893 indicates that it is not safe to adjust the queue delay target. 895 A low qdelay_norm_var_t indicates that the queue delay is relatively 896 stable, the reason can be that the queue delay is low but it can also 897 be an indication that a competing flow is filling up the bottleneck 898 to the limit where packet losses may start to occur, in which case 899 the queue delay will stay relatively high for a longer time. 901 The queue delay target is allowed to be increased if, either the loss 902 event rate is above a given threshold or that qdelay_norm_var_t is 903 low. Both these conditions indicate that a competing flow may be 904 present. In all other cases the queue delay target is decreased. 906 The function that adjusts the qdelay_target is simple and has a 907 certain risk to produce both false positive and negatives, The case 908 that self-inflicted congestion by the SCReAM algorithm may be falsely 909 interpreted as the presence of competing loss based FTP flows is a 910 false positive. The opposite case where the algorithm fails to 911 detect the presence of a competing FTP flow is a false negative. 913 Extensive simulations have shown that the algorithm performs well in 914 LTE test cases and that it also performs well in simple bandwidth 915 limited bottleneck test cases with competing FTP flows. It can 916 however not be completely ruled out that this algorithm can fail. 917 Especially the false positives can be problematic as the end to end 918 delay can increase dramatically if the target queue delay is 919 increased by accident as a result of self-inflicted congestion. 921 If it is deemed unlikely that competing flows occur over the same 922 bottleneck, the algorithm described in this section MAY be turned 923 off. One such case can be QoS enabled bearers in 3GPP based access 924 such as LTE. However, when sending over the Internet, often the 925 network conditions are not known for sure and it is in general not 926 possible to make safe assumptions on how a network is used and 927 whether or not competing flows share the same bottleneck. Therefore 928 turning this algorithm off must be considered with caution as that 929 can lead to basically zero throughput if competing with other, loss 930 based, traffic. 932 4.1.2.4. Lost packet detection 934 Lost packet detection is based on the received sequence number list. 935 A reordering window SHOULD be applied to avoid that packet reordering 936 triggers loss events. 937 The reordering window is specified as a time unit, similar to the 938 ideas behind RACK (Recent ACKnowledgement) [I-D.ietf-tcpm-rack]. The 939 computation of the reordering window is made possible by means of a 940 lost flag in the list of transmitted RTP packets. This flag is set 941 if the received sequence number list indicates that the given RTP 942 packet is missing. If a later feedback indicates that a previously 943 lost marked packet was indeed received, then the reordering window is 944 updated to reflect the reordering delay. The reordering window is 945 given by the difference in time between the event that the packet was 946 marked as lost and the event that it was indicated as successfully 947 received. 948 Loss is detected if a given RTP packet is not acknowledged within a 949 time window (indicated by the reordering window) after an RTP packet 950 with higher sequence number was acknowledged. 952 4.1.2.5. Send window calculation 954 The basic design principle behind packet transmission in SCReAM is to 955 allow transmission only if the number of bytes in flight is less than 956 the congestion window. There are however two reasons why this strict 957 rule will not work optimally: 959 o Bitrate variations: Media sources such as video encoders generally 960 produce frames whose size always vary to a larger or smaller 961 extent. The RTP queue absorbs the natural variations in frame 962 sizes. The RTP queue should however be as short as possible, to 963 avoid that the end to end delay increases. To achieve that, the 964 media rate control takes the RTP queue size into account when the 965 target bitrate for the media is computed. A strict 'send only 966 when bytes in flight is less than the congestion window' rule can 967 lead to that the RTP queue grows simply because the send window is 968 limited, the effect of which would be that the target bitrate is 969 pushed down. The consequence of this is that the congestion 970 window will not increase, or will increase very slowly, because 971 the congestion window is only allowed to increase when there is a 972 sufficient amount of data in flight. The end effect is then that 973 the media bitrate increases very slowly or not at all. 975 o Reverse (feedback) path congestion: Especially in transport over 976 buffer-bloated networks, the one way delay in the reverse 977 direction can jump due to congestion. The effect of this is that 978 the acknowledgements are delayed with the result that the self- 979 clocking is temporarily halted, even though the forward path is 980 not congested. 982 The send window is adjusted depending on qdelay and its relation to 983 the qdelay target and the relation between the congestion window and 984 the number of bytes in flight. A strict rule is applied when qdelay 985 is higher than qdelay_target, to avoid further queue buildup in the 986 network. For cases when qdelay is lower than the qdelay_target, a 987 more relaxed rule is applied. This allows the bitrate to increase 988 quickly when no congestion is detected while still being able to give 989 a stable behavior in congested situations. 991 The send window is given by the relation between the adjusted 992 congestion window and the amount of bytes in flight according to the 993 pseudo code below. 995 996 calculate_send_window(qdelay, qdelay_target) 997 # send window is computed differently depending on congestion level 998 if (qdelay <= qdelay_target) 999 send_wnd = cwnd+MSS-bytes_in_flight 1000 else 1001 send_wnd = cwnd-bytes_in_flight 1002 end 1003 1005 The send window is updated whenever an RTP packet is transmitted or 1006 an RTCP feedback messaged is received. 1008 4.1.2.6. Packet pacing 1010 Packet pacing is used in order to mitigate coalescing i.e. that 1011 packets are transmitted in bursts, with the increased risk of more 1012 jitter and potentially increased packet loss. Packet pacing also 1013 mitigates possible issues with queue overflow due to key-frame 1014 generation in video coders. The time interval between consecutive 1015 packet transmissions is enforced to be equal to or higher than t_pace 1016 where t_pace is given by the equations below : 1018 1019 pace_bitrate = max (RATE_PACE_MIN, cwnd* 8 / s_rtt) 1020 t_pace = rtp_size * 8 / pace_bitrate 1021 1023 rtp_size is the size of the last transmitted RTP packet, s_rtt is the 1024 smoothed round trip time. RATE_PACE_MIN is the minimum pacing rate. 1026 4.1.2.7. Resuming fast increase 1028 Fast increase can resume in order to speed up the bitrate increase in 1029 case congestion abates. The condition to resume fast increase 1030 (in_fast_increase = true) is that qdelay_trend is less than 1031 QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more. 1033 4.1.2.8. Stream prioritization 1035 The SCReAM algorithm makes a good distinction between network 1036 congestion control and the media rate control. This is easily 1037 extended to many streams, in which case RTP packets from two or more 1038 RTP queues are scheduled at the rate permitted by the network 1039 congestion control. 1041 The scheduling can be done by means of a few different scheduling 1042 regimes. For example the method applied in 1044 [I-D.ietf-rmcat-coupled-cc] can be used. The implementation of 1045 SCReAM [SCReAM-CPP-implementation] use credit based scheduling. In 1046 credit based scheduling, credit is accumulated by queues as they wait 1047 for service and are spent while the queues are being serviced. For 1048 instance, if one queue is allowed to transmit 1000bytes, then a 1049 credit of 1000bytes is allocated to the other unscheduled queues. 1050 This principle can be extended to weighted scheduling in which case 1051 the credit allocated to unscheduled queues depends on the relative 1052 weights. The latter is also implemented in 1053 [SCReAM-CPP-implementation]. 1055 4.1.3. Media rate control 1057 The media rate control algorithm is executed at regular intervals 1058 RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to 1059 loss events. The media rate control operates based on the size of 1060 the RTP packet send queue and observed loss events. In addition, 1061 qdelay_trend is also considered in the media rate control to reduce 1062 the amount of induced network jitter. 1064 The role of the media rate control is to strike a reasonable balance 1065 between a low amount of queuing in the RTP queue(s) and a sufficient 1066 amount of data to send in order to keep the data path busy. A too 1067 cautious setting leads to possible under-utilization of network 1068 capacity leading to that the flow can become starved out by other 1069 more opportunistic traffic. On the other hand, a too aggressive 1070 setting leads to increased jitter. 1072 The target_bitrate is adjusted depending on the congestion state. 1073 The target bitrate can vary between a minimum value 1074 (TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX). 1075 TARGET_BITRATE_MIN SHOULD be chosen to a low enough value to avoid 1076 that RTP packets become queued up when the network throughput is 1077 reduced. The sender SHOULD also be equipped with a mechanism that 1078 discards RTP packets in cases where the network throughput becomes 1079 very low and RTP packets are excessively delayed. 1081 For the overall bitrate adjustment, two network throughput estimates 1082 are computed : 1084 o rate_transmit: The measured transmit bitrate. 1086 o rate_ack: The ACKed bitrate, i.e. the volume of ACKed bits per 1087 second. 1089 Both estimates are updated every 200ms. 1091 The current throughput, current_rate, is computed as the maximum 1092 value of rate_transmit and rate_ack. The rationale behind the use of 1093 rate_ack in addition to rate_transmit is that rate_transmit is 1094 affected also by the amount of data that is available to transmit, 1095 thus a lack of data to transmit can be seen as reduced throughput 1096 that can itself cause an unnecessary rate reduction. To overcome 1097 this shortcoming; rate_ack is used as well. This gives a more stable 1098 throughput estimate. 1100 The rate change behavior depends on whether a loss or ECN event has 1101 occurred and if the congestion control is in fast increase or not. 1103 1104 # The target_bitrate is updated at a regular interval according 1105 # to RATE_ADJUST_INTERVAL 1107 on loss: 1108 # Loss event detected 1109 target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN) 1110 exit 1111 on ecn_mark: 1112 # ECN event detected 1113 target_bitrate = max(BETA_ECN* target_bitrate, TARGET_BITRATE_MIN) 1114 exit 1116 ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate/2.0) 1117 scale_t = (target_bitrate - target_bitrate_last_max)/ 1118 target_bitrate_last_max 1119 scale_t = max(0.2, min(1.0, (scale_t*4)^2)) 1120 # min scale_t value 0.2 as the bitrate should be allowed to 1121 # increase at least slowly --> avoid locking the rate to 1122 # target_bitrate_last_max 1123 if (in_fast_increase = true) 1124 increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL 1125 increment_t *= scale_t 1126 target_bitrate += increment_t 1127 else 1128 current_rate_t = max(rate_transmit, rate_ack) 1129 # Compute a bitrate change 1130 delta_rate_t = current_rate_t*(1.0-PRE_CONGESTION_GUARD* 1131 queue_delay_trend)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size 1132 # Limit a positive increase if close to target_bitrate_last_max 1133 if (delta_rate_t > 0) 1134 delta_rate_t *= scale_t 1135 delta_rate_t = 1136 min(delta_rate_t,ramp_up_speed_t*RATE_ADJUST_INTERVAL) 1137 end 1138 target_bitrate += delta_rate_t 1139 # Force a slight reduction in bitrate if RTP queue 1140 # builds up 1141 rtp_queue_delay_t = rtp_queue_size/current_rate_t 1142 if (rtp_queue_delay_t > RTP_QDELAY_TH) 1143 target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY 1144 end 1145 end 1147 rate_media_limit_t = 1148 max(current_rate_t, max(rate_media,rtp_rate_median)) 1149 rate_media_limit_t *= (2.0-qdelay_trend_mem) 1150 target_bitrate = min(target_bitrate, rate_media_limit_t) 1151 target_bitrate = min(TARGET_BITRATE_MAX, 1152 max(TARGET_BITRATE_MIN,target_bitrate)) 1153 1155 In case of a loss event the target_bitrate is updated and the rate 1156 change procedure is exited. Otherwise the rate change procedure 1157 continues. The rationale behind the rate reduction due to loss is 1158 that a congestion window reduction will take effect, a rate reduction 1159 pro actively avoids RTP packets being queued up when the transmit 1160 rate decreases due to the reduced congestion window. A similar rate 1161 reduction happens when ECN events are detected. 1163 The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless 1164 a loss event occurs. The value is based on experimentation with real 1165 life limitations in video coders taken into account 1166 [SCReAM-CPP-implementation]. A too short interval is shown to make 1167 the rate control loop in video coders more unstable, a too long 1168 interval makes the overall congestion control sluggish. 1170 When in fast increase state (in_fast_increase=true), the bitrate 1171 increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . The 1172 ramp-up speed is limited when the target bitrate is low to avoid rate 1173 oscillation at low bottleneck bitrates. The setting of RAMP_UP_SPEED 1174 depends on preferences, a high setting such as 1000kbps/s makes it 1175 possible to quickly get high quality media, this is however at the 1176 expense of a increased jitter, which can manifest itself as e.g. 1177 choppy video rendering. 1179 When in_fast_increase is false, the bitrate increase is given by the 1180 current bitrate and is also controlled by the estimated RTP queue and 1181 the qdelay trend, thus it is sufficient that an increased congestion 1182 level is sensed by the network congestion control to limit the 1183 bitrate. The target_bitrate_last_max is updated when congestion is 1184 detected. 1186 Finally the target_bitrate is enforced to be within the defined min 1187 and max values. 1189 The aware reader may notice the dependency on the qdelay in the 1190 computation of the target bitrate, this manifests itself in the use 1191 of the qdelay_trend. As these parameters are used also in the 1192 network congestion control one may suspect some odd interaction 1193 between the media rate control and the network congestion control, 1194 this is in fact the case if the parameter PRE_CONGESTION_GUARD is set 1195 to a high value. The use of qdelay_trend in the media rate control 1196 is solely to reduce jitter, the dependency can be removed by setting 1197 PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase 1198 after congestion, at the expense of increased jitter in congested 1199 situations. 1201 4.2. SCReAM Receiver 1203 The simple task of the SCReAM receiver is to feedback 1204 acknowledgements of received packets and total ECN count to the 1205 SCReAM sender, in addition, the receive time of the RTP packet with 1206 the highest sequence number is echoed back. Upon reception of each 1207 RTP packet the receiver MUST maintain enough information to send the 1208 aforementioned values to the SCReAM sender via a RTCP transport layer 1209 feedback message. The frequency of the feedback message depends on 1210 the available RTCP bandwidth. The requirements on the feedback 1211 elements and the feedback interval is described. 1213 4.2.1. Requirements on feedback elements 1215 The following feedback elements are REQUIRED for the basic 1216 functionality in SCReAM. 1218 o A list of received RTP packets. This list SHOULD be sufficiently 1219 long to cover all received RTP packets. This list can be realized 1220 with the Loss RLE report block in [RFC3611]. 1222 o A wall clock timestamp corresponding to the received RTP packet 1223 with the highest sequence number is required in order to compute 1224 the qdelay. This can be realized by means of the Packet Receipt 1225 Times Report Block in [RFC3611]. begin_seq MUST be set to the 1226 highest received (possibly wrapped around) sequence number, 1227 end_seq MUST be set to begin_seq+1 % 65536. The timestamp clock 1228 MAY be set according to [RFC3611] i.e. equal to the RTP timestamp 1229 clock. Detailed individual packet receive times is not necessary 1230 as SCReAM does currently not describe how this can be used. 1232 The basic feedback needed for SCReAM involves the use of the Loss RLE 1233 report block and the Packet Receipt Times block defined in Figure 2. 1235 0 1 2 3 1236 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 |V=2|P|reserved | PT=XR=207 | length | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | SSRC | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | BT=2 | rsvd. | T=0 | block length | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | SSRC of source | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | begin_seq | end_seq | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | chunk 1 | chunk 2 | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 : ... : 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | chunk n-1 | chunk n | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | BT=3 | rsvd. | T=0 | block length | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | SSRC of source | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | begin_seq | end_seq | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Receipt time of packet begin_seq | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 Figure 2: Basic feedback message for SCReAM, based on RFC3611 1265 In a typical use case, no more than four Loss RLE chunks are needed, 1266 thus the feedback message will be 44bytes. It is obvious from the 1267 figure that there is a lot of redundant information in the feedback 1268 message. A more optimized feedback format, including the additional 1269 feedback elements listed below, could reduce the feedback message 1270 size a bit. 1272 Additional feedback elements that can improve the performance of 1273 SCReAM are: 1275 o Accumulated number of ECN-CE marked packets (n_ECN). This can for 1276 instance be realized with the ECN Feedback Report Format in 1277 [RFC6679]. The given feedback report format is actually a slight 1278 overkill as SCReAM would do quite well with only a counter that 1279 increments by one for each received packet with the ECN-CE code 1280 point set. The more bulky format could nevertheless be useful for 1281 e.g ECN black-hole detection. 1283 4.2.2. Requirements on feedback intensity 1285 SCReAM benefits from a relatively frequent feedback. It is 1286 RECOMMENDED that a SCReAM implementation follows the guidelines 1287 below. 1289 The feedback interval depends on the media bitrate. At low bitrates 1290 it is sufficient with a feedback interval of 100 to 400ms, while at 1291 high bitrates a feedback interval of roughly 20ms is to prefer, at 1292 very high bitrates, even shorter feedback intervals MAY be needed in 1293 order to keep the self-clocking in SCReAM working well. One piece of 1294 evidence of a too sparse feedback is that the SCReAM implementation 1295 cannot reach high bitrates, even in uncongested links. A more 1296 frequent feedback might solve this issue. 1298 The numbers above can be formulated as feedback interval function 1299 that can be useful for the computation of the desired RTCP bandwidth. 1300 The following equation expresses the feedback rate: 1302 rate_fb = min(50,max(2.5,rate_media/10000)) 1304 rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is 1305 the feedback rate expressed in [packets/s]. Converted to feedback 1306 interval we get: 1308 fb_int = 1.0/min(50,max(2.5,rate_media/10000)) 1310 The transmission interval is not critical, this means that in the 1311 case of multi-stream handling between two hosts, the feedback for two 1312 or more SSRCs can be bundled to save UDP/IP overhead, the final 1313 realized feedback interval SHOULD however not exceed 2*fb_int in such 1314 cases meaning that a scheduled feedback transmission event should not 1315 be delayed more that fb_int. 1317 SCReAM works with AVPF regular mode, immediate or early mode is not 1318 required by SCReAM but can nonetheless be useful for e.g RTCP 1319 messages not directly related to SCReAM, such as those specified in 1320 [RFC4585]. It is RECOMMENDED to use reduced size RTCP [RFC5506] 1321 where regular full compound RTCP transmission is controlled by trr- 1322 int as described in [RFC4585]. 1324 5. Discussion 1326 This section covers a few discussion points 1327 o Clock drift: SCReAM can suffer from the same issues with clock 1328 drift as is the case with LEDBAT [RFC6817]. Section A.2 in 1329 [RFC6817] however describes ways to mitigate issues with clock 1330 drift. 1332 o Support for alternate ECN semantics: This specification adopts the 1333 proposal in [I-D.ietf-tcpm-alternativebackoff-ecn] to reduce the 1334 congestion window less when ECN based congestion events are 1335 detected. Future work on Low Loss Low Latency for Scalable 1336 throughput (L4S) may lead to updates in a future RFC that 1337 describes SCReAM support for L4S. 1339 o A new RFC4585 transport layer feedback message could to be 1340 standardized if the use of the already existing RTCP extensions as 1341 described in Section 4.2 is not deemed sufficient. 1343 o The target bitrate given by SCReAM depicts the bitrate including 1344 RTP and FEC overhead. The media encoder SHOULD take this overhead 1345 into account when the media bitrate is set. This means that the 1346 media coder bitrate SHOULD be computed as 1348 media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate 1350 It is not strictly necessary to make a 100% perfect compensation 1351 for the overhead as the SCReAM algorithm will inherently 1352 compensate for moderate errors. Under-compensation of the 1353 overhead has the effect of increasing jitter while 1354 overcompensation will have the effect of causing the bottleneck 1355 link to become under-utilized. 1357 6. Implementation status 1359 [Editor's note: Please remove the whole section before publication, 1360 as well reference to RFC 7942] 1362 This section records the status of known implementations of the 1363 protocol defined by this specification at the time of posting of this 1364 Internet-Draft, and is based on a proposal described in [RFC7942]. 1365 The description of implementations in this section is intended to 1366 assist the IETF in its decision processes in progressing drafts to 1367 RFCs. Please note that the listing of any individual implementation 1368 here does not imply endorsement by the IETF. Furthermore, no effort 1369 has been spent to verify the information presented here that was 1370 supplied by IETF contributors. This is not intended as, and MUST NOT 1371 be construed to be, a catalog of available implementations or their 1372 features. Readers are advised to note that other implementations MAY 1373 exist. 1375 According to [RFC7942], "this will allow reviewers and working groups 1376 to assign due consideration to documents that have the benefit of 1377 running code, which may serve as evidence of valuable experimentation 1378 and feedback that have made the implemented protocols more mature. 1379 It is up to the individual working groups to use this information as 1380 they see it". 1382 6.1. OpenWebRTC 1384 The SCReAM algorithm has been implemented in the OpenWebRTC project 1385 [OpenWebRTC], an open source WebRTC implementation from Ericsson 1386 Research. This SCReAM implementation is usable with any WebRTC 1387 endpoint using OpenWebRTC. 1389 o Organization : Ericsson Research, Ericsson. 1391 o Name : OpenWebRTC gst plug-in. 1393 o Implementation link : The GStreamer plug-in code for SCReAM can be 1394 found at github repository [SCReAM-implementation] The wiki 1395 (https://github.com/EricssonResearch/openwebrtc/wiki) contains 1396 required information for building and using OpenWebRTC. 1398 o Coverage : The code implements the specification in this memo. 1399 The current implementation has been tuned and tested to adapt a 1400 video stream and does not adapt the audio streams. 1402 o Implementation experience : The implementation of the algorithm in 1403 the OpenWebRTC has given great insight into the algorithm itself 1404 and its interaction with other involved modules such as encoder, 1405 RTP queue etc. In fact it proves the usability of a self-clocked 1406 rate adaptation algorithm in the real WebRTC system. The 1407 implementation experience has led to various algorithm 1408 improvements both in terms of stability and design. The current 1409 implementation use an n_loss counter for lost packets indication, 1410 this is subject to change in later versions to a list of received 1411 RTP packets. 1413 o Contact : irc://chat.freenode.net/openwebrtc 1415 6.2. A C++ Implementation of SCReAM 1417 o Organization : Ericsson Research, Ericsson. 1419 o Name : SCReAM. 1421 o Implementation link : A C++ implementation of SCReAM is available 1422 at[SCReAM-CPP-implementation]. The code includes full support for 1423 congestion control, rate control and multi stream handling, it can 1424 be integrated in web clients given the addition of extra code to 1425 implement the RTCP feedback and RTP queue(s). The code also 1426 includes a rudimentary implementation of a simulator that allows 1427 for some initial experiments. An additional experiment with 1428 SCReAM in a remote control arrangement is also documented. 1430 o Coverage : The code implements the specification in this memo. 1432 o Contact : ingemar.s.johansson@ericsson.com 1434 7. Suggested experiments 1436 SCReAM has been evaluated in a number of different ways, most of the 1437 evaluation has been in simulator. The OpenWebRTC implementation work 1438 involved extensive testing with artificial bottlenecks with varying 1439 bandwidths and using two different video coders (OpenH264 and VP9), 1440 the experience of this lead to further improvements of the media rate 1441 control logic. 1443 Further experiments are preferably done by means of implementation in 1444 real clients and web browsers. RECOMMENDED experiments are: 1446 o Trials with various access technologies: EDGE/3G/4G, WiFi, DSL. 1447 Some experiments have already been carried out with LTE access, 1448 see e.g. [SCReAM-CPP-implementation] and 1449 [SCReAM-implementation-experience] 1451 o Trials with different kinds of media: Audio, Video, slide show 1452 content. Evaluation of multi stream handling in SCReAM. 1454 o Evaluation of functionality of competing flows compensation 1455 mechanism: Evaluate how SCReAM performs with competing TCP like 1456 traffic and to what extent the competing flows compensation causes 1457 self-inflicted congestion. 1459 o Determine proper parameters: A set of default parameters are given 1460 that makes SCReAM work over a reasonably large operation range, 1461 however for instance for very low or very high bitrates it may be 1462 necessary to use different values for instance for the 1463 RAMP_UP_SPEED. 1465 o Experimentation with further improvements to the congestion window 1466 and media bitrate calculation. [SCReAM-CPP-implementation] 1467 implements some optimizations, not described in this memo, that 1468 improve performance slightly. Further experiments are likely to 1469 lead to more optimizations of the algorithm. 1471 8. Acknowledgements 1473 We would like to thank the following persons for their comments, 1474 questions and support during the work that led to this memo: Markus 1475 Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, 1476 Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, 1477 Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard 1478 Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many 1479 additional thanks to RMCAT chairs Karen E. E. Nielsen and Mirja 1480 Kuehlewind for patiently reading, suggesting improvements and also 1481 for asking all the difficult but necessary questions. Thanks to 1482 Stefan Holmer, Xiaoqing Zhu, Safiqul Islam and David Hayes for the 1483 additional review of this document. Thanks to Ralf Globisch for 1484 taking time to try out SCReAM in his challenging low bitrate use 1485 cases, Robert Hedman for finding a few additional flaws in the 1486 running code, and Gustavo Garcia and 'miseri' for code contributions. 1488 9. IANA Considerations 1490 There is currently no request to IANA 1492 10. Security Considerations 1494 The feedback can be vulnerable to attacks similar to those that can 1495 affect TCP. It is therefore RECOMMENDED that the RTCP feedback is at 1496 least integrity protected. Furthermore, as SCReAM is self-clocked, a 1497 malicious middlebox can drop RTCP feedback packets and thus cause the 1498 self-clocking in SCReAM to stall. This attack is however mitigated 1499 by the minimum send rate maintained by SCReAM when no feedback is 1500 received. 1502 11. Change history 1504 A list of changes: 1506 o WG-12 to WG-13: IESG comments addressed 1508 o WG-11 to WG-12: Review comments from Joel Halpern and Mirja 1510 o WG-10 to WG-11: Review comments from Mirja 1512 o WG-9 to WG-10: Minor edits 1514 o WG-08 to WG-09: Updated based shepherd review by Martin 1515 Stiemerling, Q-bit semantics are removed as this is superfluous 1516 for the moment. Pacing and RTCP considerations are moved up from 1517 the appendix, FEC discussion moved to discussion section. 1519 o WG-07 to WG-08: Avoid draft expiry 1521 o WG-06 to WG-07: Updated based on WGLC review by David Hayes and 1522 Safiqul Islam 1524 o WG-05 to WG-06: Added list of suggested experiments 1526 o WG-04 to WG-05: Congestion control and rate control simplified 1527 somewhat 1529 o WG-03 to WG-04: Editorial fixes 1531 o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing 1532 Zhu addressed, owd changed to qdelay for clarity. Added appendix 1533 section with RTCP feedback requirements, including a suggested 1534 basic feedback format based Loss RLE report block and the Packet 1535 Receipt Times blocks in [RFC3611]. Loss detection added as a 1536 section. Transmission scheduling and packet pacing explained in 1537 appendix. Source quench semantics added to appendix. 1539 o WG-01 to WG-02: Complete restructuring of the document. Moved 1540 feedback message to a separate draft. 1542 o WG-00 to WG-01 : Changed the Source code section to Implementation 1543 status section. 1545 o -05 to WG-00 : First version of WG doc, moved additional features 1546 section to Appendix. Added description of prioritization in 1547 SCReAM. Added description of additional cap on target bitrate 1549 o -04 to -05 : ACK vector is replaced by a loss counter, PT is 1550 removed from feedback, references to source code added 1552 o -03 to -04 : Extensive changes due to review comments, code 1553 somewhat modified, frame skipping made optional 1555 o -02 to -03 : Added algorithm description with equations, removed 1556 pseudo code and simulation results 1558 o -01 to -02 : Updated GCC simulation results 1560 o -00 to -01 : Fixed a few bugs in example code 1562 12. References 1563 12.1. Normative References 1565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1566 Requirement Levels", BCP 14, RFC 2119, 1567 DOI 10.17487/RFC2119, March 1997, 1568 . 1570 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1571 Jacobson, "RTP: A Transport Protocol for Real-Time 1572 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1573 July 2003, . 1575 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 1576 "RTP Control Protocol Extended Reports (RTCP XR)", 1577 RFC 3611, DOI 10.17487/RFC3611, November 2003, 1578 . 1580 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1581 "Extended RTP Profile for Real-time Transport Control 1582 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1583 DOI 10.17487/RFC4585, July 2006, 1584 . 1586 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1587 Real-Time Transport Control Protocol (RTCP): Opportunities 1588 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 1589 2009, . 1591 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1592 "Computing TCP's Retransmission Timer", RFC 6298, 1593 DOI 10.17487/RFC6298, June 2011, 1594 . 1596 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 1597 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 1598 DOI 10.17487/RFC6817, December 2012, 1599 . 1601 12.2. Informative References 1603 [I-D.ietf-rmcat-coupled-cc] 1604 Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion 1605 control for RTP media", draft-ietf-rmcat-coupled-cc-07 1606 (work in progress), September 2017. 1608 [I-D.ietf-rmcat-wireless-tests] 1609 Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and 1610 M. Ramalho, "Evaluation Test Cases for Interactive Real- 1611 Time Media over Wireless Networks", draft-ietf-rmcat- 1612 wireless-tests-04 (work in progress), May 2017. 1614 [I-D.ietf-tcpm-alternativebackoff-ecn] 1615 Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 1616 "TCP Alternative Backoff with ECN (ABE)", draft-ietf-tcpm- 1617 alternativebackoff-ecn-02 (work in progress), October 1618 2017. 1620 [I-D.ietf-tcpm-rack] 1621 Cheng, Y., Cardwell, N., and N. Dukkipati, "RACK: a time- 1622 based fast loss detection algorithm for TCP", draft-ietf- 1623 tcpm-rack-02 (work in progress), March 2017. 1625 [LEDBAT-delay-impact] 1626 "Assessing LEDBAT's Delay Impact, IEEE communications 1627 letters, vol. 17, no. 5, May 2013", May 2013, 1628 . 1631 [OpenWebRTC] 1632 "Open WebRTC project.", . 1634 [Packet-conservation] 1635 "Congestion Avoidance and Control, ACM SIGCOMM Computer 1636 Communication Review 1988", 1988. 1638 [QoS-3GPP] 1639 TS 23.203, 3GPP., "Policy and charging control 1640 architecture", June 2011, . 1643 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 1644 and K. Carlberg, "Explicit Congestion Notification (ECN) 1645 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1646 2012, . 1648 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 1649 Time Communication Use Cases and Requirements", RFC 7478, 1650 DOI 10.17487/RFC7478, March 2015, 1651 . 1653 [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating 1654 TCP to Support Rate-Limited Traffic", RFC 7661, 1655 DOI 10.17487/RFC7661, October 2015, 1656 . 1658 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1659 Code: The Implementation Status Section", BCP 205, 1660 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1661 . 1663 [SCReAM-CPP-implementation] 1664 "C++ Implementation of SCReAM", 1665 . 1667 [SCReAM-implementation] 1668 "SCReAM Implementation", 1669 . 1672 [SCReAM-implementation-experience] 1673 "Updates on SCReAM : An implementation experience", 1674 . 1677 [TFWC] University College London, "Fairer TCP-Friendly Congestion 1678 Control Protocol for Multimedia Streaming", December 2007, 1679 . 1682 Authors' Addresses 1684 Ingemar Johansson 1685 Ericsson AB 1686 Laboratoriegraend 11 1687 Luleaa 977 53 1688 Sweden 1690 Phone: +46 730783289 1691 Email: ingemar.s.johansson@ericsson.com 1692 Zaheduzzaman Sarker 1693 Ericsson AB 1694 Laboratoriegraend 11 1695 Luleaa 977 53 1696 Sweden 1698 Phone: +46 761153743 1699 Email: zaheduzzaman.sarker@ericsson.com