idnits 2.17.1 draft-ietf-rmcat-scream-cc-07.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (November 14, 2016) is 2720 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '20' on line 498 -- Looks like a reference, but probably isn't: '100' on line 507 == Unused Reference: 'RFC3550' is defined on line 1314, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rmcat-app-interaction' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rmcat-cc-codec-interactions' is defined on line 1348, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rmcat-scream-cc' is defined on line 1359, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-coupled-cc-04 == Outdated reference: A later version (-13) exists of draft-ietf-rmcat-scream-cc-06 == Outdated reference: A later version (-11) exists of draft-ietf-rmcat-wireless-tests-02 == Outdated reference: A later version (-01) exists of draft-cheng-tcpm-rack-00 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 5 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: May 18, 2017 November 14, 2016 7 Self-Clocked Rate Adaptation for Multimedia 8 draft-ietf-rmcat-scream-cc-07 10 Abstract 12 This memo describes a rate adaptation algorithm for conversational 13 media services such as video. The solution conforms to the packet 14 conservation principle and uses a hybrid loss and delay based 15 congestion control algorithm. The algorithm is evaluated over both 16 simulated Internet bottleneck scenarios as well as in a Long Term 17 Evolution (LTE) system simulator and is shown to achieve both low 18 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 http://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 May 18, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . 8 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. Congestion window update . . . . . . . . . . . . 16 69 4.1.2.2. Competing flows compensation . . . . . . . . . . 18 70 4.1.2.3. Lost packet detection . . . . . . . . . . . . . . 20 71 4.1.2.4. Send window calculation . . . . . . . . . . . . . 20 72 4.1.2.5. Resuming fast increase . . . . . . . . . . . . . 21 73 4.1.3. Media rate control . . . . . . . . . . . . . . . . . 21 74 4.1.3.1. FEC and packet overhead considerations . . . . . 24 75 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 25 76 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 25 77 6. Implementation status . . . . . . . . . . . . . . . . . . . . 25 78 6.1. OpenWebRTC . . . . . . . . . . . . . . . . . . . . . . . 26 79 6.2. A C++ Implementation of SCReAM . . . . . . . . . . . . . 27 80 7. Suggested experiments . . . . . . . . . . . . . . . . . . . . 27 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 84 11. Change history . . . . . . . . . . . . . . . . . . . . . . . 28 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 87 12.2. Informative References . . . . . . . . . . . . . . . . . 30 88 Appendix A. Additional information . . . . . . . . . . . . . . . 32 89 A.1. Stream prioritization . . . . . . . . . . . . . . . . . . 32 90 A.2. Computation of autocorrelation function . . . . . . . . . 32 91 A.3. Sender transmission control and packet pacing . . . . . . 33 92 A.4. RTCP feedback considerations . . . . . . . . . . . . . . 33 93 A.4.1. Requirements on feedback elements . . . . . . . . . . 33 94 A.4.2. Requirements on feedback intensity . . . . . . . . . 35 95 A.5. Q-bit semantics (source quench) . . . . . . . . . . . . . 36 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 98 1. Introduction 100 Congestion in the Internet occurs when the transmitted bitrate is 101 higher than the available capacity over a given transmission path. 102 Applications that are deployed in the Internet must employ congestion 103 control, to achieve robust performance and to avoid congestion 104 collapse in the Internet. Interactive realtime communication imposes 105 a lot of requirements on the transport, therefore a robust, efficient 106 rate adaptation for all access types is an important part of 107 interactive realtime communications as the transmission channel 108 bandwidth may vary over time. Wireless access such as LTE, which is 109 an integral part of the current Internet, increases the importance of 110 rate adaptation as the channel bandwidth of a default LTE bearer 111 [QoS-3GPP] can change considerably in a very short time frame. Thus 112 a rate adaptation solution for interactive realtime media, such as 113 WebRTC, must be both quick and be able to operate over a large range 114 in channel capacity. This memo describes SCReAM (Self-Clocked Rate 115 Adaptation for Multimedia), a solution that is based on the self- 116 clocking principle of TCP and uses techniques similar to what is used 117 in the LEDBAT based rate adaptation algorithm [RFC6817]. SCReAM is 118 not entirely self-clocked as it augments self-clocking with pacing 119 and a minimum send rate. 121 1.1. Wireless (LTE) access properties 123 [I-D.ietf-rmcat-wireless-tests] describes the complications that can 124 be observed in wireless environments. Wireless access such as LTE 125 can typically not guarantee a given bandwidth, this is true 126 especially for default bearers. The network throughput may vary 127 considerably for instance in cases where the wireless terminal is 128 moving around. Even though LTE can support bitrates well above 129 100Mbps, there are cases when the available bitrate can be much 130 lower, examples are situations with high network load and poor 131 coverage. 133 Unlike wireline bottlenecks with large statistical multiplexing it is 134 not possible to try to maintain a given bitrate when congestion is 135 detected with the hope that other flows will yield, this is because 136 there are generally few other flows competing for the same 137 bottleneck. Each user gets its own variable throughput bottleneck, 138 where the throughput depends on factors like channel quality, network 139 load and historical throughput. The bottom line is, if the 140 throughput drops, the sender has no other option than to reduce the 141 bitrate. Once the radio scheduler has reduced the resource 142 allocation for a bearer, an RMCAT flow in that bearer needs to reduce 143 the sending rate quite quickly (within one RTT) in order to avoid 144 excessive queuing delay or packet loss. 146 1.2. Why is it a self-clocked algorithm? 148 Self-clocked congestion control algorithms provide a benefit over the 149 rate based counterparts in that the former consists of two adaptation 150 mechanisms: 152 o A congestion window computation that evolves over a longer 153 timescale (several RTTs) especially when the congestion window 154 evolution is dictated by estimated delay (to minimize 155 vulnerability to e.g. short term delay variations). 157 o A fine grained congestion control given by the self-clocking which 158 operates on a shorter time scale (1 RTT). The benefits of self- 159 clocking are also elaborated upon in [TFWC]. 161 A rate based congestion control typically adjusts the rate based on 162 delay and loss. The congestion detection needs to be done with a 163 certain time lag to avoid over-reaction to spurious congestion events 164 such as delay spikes. Despite the fact that there are two or more 165 congestion indications, the outcome is still that there is still only 166 one mechanism to adjust the sending rate. This makes it difficult to 167 reach the goals of high throughput and prompt reaction to congestion. 169 2. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC2119 [RFC2119] 175 3. Overview of SCReAM Algorithm 177 The core SCReAM algorithm has similarities to the concepts of self- 178 clocking used in TFWC [TFWC] and follows the packet conservation 179 principle. The packet conservation principle is described as an 180 important key-factor behind the protection of networks from 181 congestion [Packet-conservation]. 183 In SCReAM, the receiver of the media echoes a list of received RTP 184 packets and the timestamp of the RTP packet with the highest sequence 185 number back to the sender in feedback packets. The sender keeps a 186 list of transmitted packets, their respective sizes and the time they 187 were transmitted. This information is used to determine the number 188 of bytes that can be transmitted at any given time instant. A 189 congestion window puts an upper limit on how many bytes can be in 190 flight, i.e. transmitted but not yet acknowledged. 192 The congestion window is determined in a way similar to LEDBAT 193 [RFC6817]. LEDBAT is a congestion control algorithm that uses send 194 and receive timestamps to estimate the queuing delay (from now on 195 denoted qdelay) along the transmission path. This information is 196 used to adjust the congestion window. The use of LEDBAT ensures that 197 the end-to-end latency is kept low. [LEDBAT-delay-impact] shows that 198 LEDBAT has certain inherent issues that makes it counteract its 199 purpose to achieve low delay. The general problem described in the 200 paper is that the base delay is offset by LEDBAT's own queue buildup. 201 The big difference with using LEDBAT in the SCReAM context lies in 202 the fact that the source is rate limited and that it is required that 203 the RTP queue is kept short (preferably empty). In addition the 204 output from a video encoder is rarely constant bitrate, static 205 content (talking heads) for instance gives almost zero video rate. 206 This gives two useful properties when LEDBAT is used with SCReAM that 207 help to avoid the issues described in [LEDBAT-delay-impact]: 209 1. There is always a certain probability that SCReAM is short of 210 data to transmit, which means that the network queue will run 211 empty every once in a while. 213 2. The max video bitrate can be lower than the link capacity. If 214 the max video bitrate is 5Mbps and the capacity is 10Mbps then 215 the network queue will run empty. 217 It is sufficient that any of the two conditions above is fulfilled to 218 make the base delay update properly. Furthermore 219 [LEDBAT-delay-impact] describes an issue with short lived competing 220 flows, the case in SCReAM is that these short lived flows will cause 221 the self-clocking in SCReAM to slow down with the result that the RTP 222 queue is built up, which will in turn result in a reduced media video 223 bitrate. SCReAM will thus yield more to competing short lived flows 224 than what is the case with traditional use of LEDBAT. 225 The basic functionality in the use of LEDBAT in SCReAM is quite 226 simple, there are however a few steps to take to make the concept 227 work with conversational media: 229 o Congestion window validation techniques. These are similar in 230 action as the method described in [RFC7661]. Congestion window 231 validation ensures that the congestion window is limited by the 232 actual number bytes in flight, this is important especially in the 233 context of rate limited sources such as video. Lack of congestion 234 window validation would lead to a slow reaction to congestion as 235 the congestion window does not properly reflect the congestion 236 state in the network. The allowed idle period in this memo is 237 shorter than in [RFC7661], this to avoid excessive delays in the 238 cases where e.g. wireless throughput has decreased during a period 239 where the output bitrate from the media coder has been low, for 240 instance due to inactivity. Furthermore, this memo allows for 241 more relaxed rules for when the congestion window is allowed to 242 grow, this is necessary as the variable output bitrate generally 243 means that the congestion window is often under-utilized. 245 o Fast increase makes the bitrate increase faster when no congestion 246 is detected. It makes the media bitrate ramp-up within 5 to 10 247 seconds. The behavior is similar to TCP slowstart. The fast 248 increase is exited when congestion is detected. The fast increase 249 state can however resume if the congestion level is low, this 250 enables a reasonably quick rate increase in case link throughput 251 increases. 253 o A qdelay trend is computed for earlier detection of incipient 254 congestion and as a result it reduces jitter. 256 o Addition of a media rate control function. 258 o Use of inflection points in the media rate calculation to achieve 259 reduced jitter. 261 o Adjustment of qdelay target for better performance when competing 262 with other loss based congestion controlled flows. 264 The above mentioned features will be described in more detail in 265 sections Section 3.1 to Section 3.3. 267 +---------------------------+ 268 | Media encoder | 269 +---------------------------+ 270 ^ | 271 (3)| (1)| 272 | RTP 273 | V 274 | +-----------+ 275 +---------+ | | 276 | Media | (2) | Queue | 277 | rate |<------| | 278 | control | |RTP packets| 279 +---------+ | | 280 +-----------+ 281 | 282 | 283 (4)| 284 RTP 285 | 286 v 287 +------------+ +--------------+ 288 | Network | (7) | Sender | 289 +-->| congestion |------>| Transmission | 290 | | control | | Control | 291 | +------------+ +--------------+ 292 | | 293 | (6) |(5) 294 |-------------RTCP----------| RTP 295 | | 296 | v 297 +------------+ 298 | UDP | 299 | socket | 300 +------------+ 302 Figure 1: SCReAM sender functional view 304 The SCReAM algorithm consists of three main parts: network congestion 305 control, sender transmission control and media rate control. All of 306 these three parts reside at the sender side. Figure 1 shows the 307 functional overview of a SCReAM sender. The receiver side algorithm 308 is very simple in comparison as it only generates feedback containing 309 acknowledgements of received RTP packets and an ECN count. 311 3.1. Network Congestion Control 313 The network congestion control sets an upper limit on how much data 314 can be in the network (bytes in flight); this limit is called CWND 315 (congestion window) and is used in the sender transmission control. 317 The SCReAM congestion control method, uses techniques similar to 318 LEDBAT [RFC6817] to measure the qdelay. As is the case with LEDBAT, 319 it is not necessary to use synchronized clocks in sender and receiver 320 in order to compute the qdelay. It is however necessary that they 321 use the same clock frequency, or that the clock frequency at the 322 receiver can be inferred reliably by the sender. 324 The SCReAM sender calculates the congestion window based on the 325 feedback from the SCReAM receiver. The congestion window is allowed 326 to increase if the qdelay is below a predefined qdelay target, 327 otherwise the congestion window decreases. The qdelay target is 328 typically set to 50-100ms. This ensures that the queuing delay is 329 kept low. The reaction to loss or ECN events leads to an instant 330 reduction of CWND. Note that the source rate limited nature of real 331 time media such as video, typically means that the queuing delay will 332 mostly be below the given delay target, this is contrary to the case 333 where large files are transmitted using LEDBAT congestion control, in 334 which case the queuing delay will stay close to the delay target. 336 3.2. Sender Transmission Control 338 The sender transmission control limits the output of data, given by 339 the relation between the number of bytes in flight and the congestion 340 window. Packet pacing is used to mitigate issues with ACK 341 compression that may cause increased jitter and/or packet loss in the 342 media traffic. Packet pacing limits the packet transmission rate 343 given by the estimated link throughput. Even if the send window 344 allows for the transmission of a number of packets, these packets are 345 not transmitted immediately, but rather they are transmitted in 346 intervals given by the packet size and the estimated link throughput. 348 3.3. Media Rate Control 350 The media rate control serves to adjust the media bitrate to ramp-up 351 quickly enough to get a fair share of the system resources when link 352 throughput increases. 354 The reaction to reduced throughput must be prompt in order to avoid 355 getting too much data queued in the RTP packet queue(s) in the 356 sender. The media bitrate is decreased if the RTP queue size exceeds 357 a threshold. 359 In cases where the sender frame queues increase rapidly such as in 360 the case of a RAT (Radio Access Type) handover it may be necessary to 361 implement additional actions, such as discarding of encoded media 362 frames or frame skipping in order to ensure that the RTP queues are 363 drained quickly. Frame skipping results in the frame rate being 364 temporarily reduced. Which method to use is a design choice and 365 outside the scope of this algorithm description. 367 4. Detailed Description of SCReAM 369 4.1. SCReAM Sender 371 This section describes the sender side algorithm in more detail. It 372 is split between the network congestion control, sender transmission 373 control and the media rate control. 375 A SCReAM sender implements media rate control and an RTP queue for 376 each media type or source, where RTP packets containing encoded media 377 frames are temporarily stored for transmission. Figure 1 shows the 378 details when a single media source (or stream) is used. A 379 transmission scheduler (not shown in the figure) is added to support 380 multiple streams. The transmission scheduler can enforce differing 381 priorities between the streams and act like a coupled congestion 382 controller for multiple flows. Support for multiple streams is 383 implemented in [SCReAM-CPP-implementation]. 385 Media frames are encoded and forwarded to the RTP queue (1) in 386 Figure 1. The media rate adaptation adapts to the size of the RTP 387 queue (2) and provides a target rate for the media encoder (3). The 388 RTP packets are picked from the RTP queue (for multiple flows from 389 each RTP queue based on some defined priority order or simply in a 390 round robin fashion) (4) by the sender transmission controller. The 391 sender transmission controller (in case of multiple flows a 392 transmission scheduler) sends the RTP packets to the UDP socket (5). 393 In the general case all media must go through the sender transmission 394 controller and is limited so that the number of bytes in flight is 395 less than the congestion window. RTCP packets are received (6) and 396 the information about bytes in flight and congestion window is 397 exchanged between the network congestion control and the sender 398 transmission control (7). 400 4.1.1. Constants and Parameter values 402 Constants and state variables are listed in this section. Temporary 403 variables are not listed, instead they are appended with '_t' in the 404 pseudo code to indicate their local scope. 406 4.1.1.1. Constants 408 The recommended values, within (), for the constants are deduced from 409 experiments. 411 QDELAY_TARGET_LO (0.1s) 412 Target value for the minimum qdelay. 414 QDELAY_TARGET_HI (0.4s) 415 Target value for the maximum qdelay. This parameter provides an 416 upper limit to how much the target qdelay (qdelay_target) can be 417 increased in order to cope with competing loss based flows. The 418 target qdelay should not be initialized to this high value however 419 as it would increase e2e delay and also make the rate control and 420 congestion control loop sluggish. 422 QDELAY_WEIGHT (0.1) 423 Averaging factor for qdelay_fraction_avg. 425 QDELAY_TREND_TH (0.2) 426 Averaging factor for qdelay_fraction_avg. 428 MAX_BYTES_IN_FLIGHT_HEAD_ROOM (1.1) 429 Headroom for the limitation of CWND. 431 GAIN (1.0) 432 Gain factor for congestion window adjustment. 434 BETA_LOSS (0.6) 435 CWND scale factor due to loss event. 437 BETA_ECN (0.8) 438 CWND scale factor due to ECN event. 440 BETA_R (0.9) 441 Target rate scale factor due to loss event. 443 MSS (1000 byte) 444 Maximum segment size = Max RTP packet size. 446 RATE_ADJUST_INTERVAL (0.2s) 447 Interval between media bitrate adjustments. 449 TARGET_BITRATE_MIN 450 Min target bitrate [bps]. 452 TARGET_BITRATE_MAX 453 Max target bitrate [bps]. 455 RAMP_UP_SPEED (200000bps/s) 456 Maximum allowed rate increase speed. 458 PRE_CONGESTION_GUARD (0.0..1.0) 459 Guard factor against early congestion onset. A higher value gives 460 less jitter, possibly at the expense of a lower link utilization. 461 This value may be subject to tuning depending on e.g media coder 462 characteristics, experiments with H264 and VP8 indicate that 0.1 is 463 a suitable value. See [SCReAM-implementation-experience] for 464 evaluation of a real implementation. 466 TX_QUEUE_SIZE_FACTOR (0.0..2.0) 467 Guard factor against RTP queue buildup. This value may be subject 468 to tuning depending on e.g media coder characteristics, experiments 469 with H264 and VP8 indicate that 1.0 is a suitable value. See 470 [SCReAM-implementation-experience] for evaluation of a real 471 implementation. 473 RTP_QDELAY_TH (0.02s) RTP queue delay threshold for a target rate 474 reduction. 476 TARGET_RATE_SCALE_RTP_QDELAY (0.95) Target rate scale when RTP 477 qdelay threshold exceeds. 479 QDELAY_TREND_LO (0.2) Threshold value for qdelay_trend. 481 T_RESUME_FAST_INCREASE Time span until fast increase can be resumed, 482 given that the qdelay_trend is below QDELAY_TREND_LO. 484 4.1.1.2. State variables 486 The values within () indicate initial values. 488 qdelay_target (QDELAY_TARGET_LO) 489 qdelay target, a variable qdelay target is introduced to manage 490 cases where e.g. FTP competes for the bandwidth over the same 491 bottleneck, a fixed qdelay target would otherwise starve the RMCAT 492 flow under such circumstances. The qdelay target is allowed to 493 vary between QDELAY_TARGET_LO and QDELAY_TARGET_HI. 495 qdelay_fraction_avg (0.0) 496 EWMA filtered fractional qdelay. 498 qdelay_fraction_hist[20] ({0,..,0}) 499 Vector of the last 20 fractional qdelay samples. 501 qdelay_trend (0.0) 502 qdelay trend, indicates incipient congestion. 504 qdelay_trend_mem (0.0) 505 Low pass filtered version of qdelay_trend. 507 qdelay_norm_hist[100] ({0,..,0}) 508 Vector of the last 100 normalized qdelay samples. 510 min_cwnd (2*MSS) 511 Minimum congestion window. 513 in_fast_increase (true) 514 True if in fast increase state. 516 cwnd (min_cwnd) 517 Congestion window. 519 bytes_newly_acked (0) 520 The number of bytes that was acknowledged with the last received 521 acknowledgement i.e. bytes acknowledged since the last CWND update. 523 send_wnd (0) 524 Upper limit to how many bytes that can currently be transmitted. 525 Updated when cwnd is updated and when RTP packet is transmitted. 527 target_bitrate (0 bps) 528 Media target bitrate. 530 target_bitrate_last_max (1 bps) 531 Media target bitrate inflection point i.e. the last known highest 532 target_bitrate. Used to limit bitrate increase speed close to the 533 last known congestion point. 535 rate_transmit (0.0 bps) 536 Measured transmit bitrate. 538 rate_ack (0.0 bps) 539 Measured throughput based on received acknowledgements. 541 rate_media (0.0 bps) 542 Measured bitrate from the media encoder. 544 rate_media_median (0.0 bps) 545 Median value of rate_media, computed over more than 10s. 547 s_rtt (0.0s) 548 Smoothed RTT [s], computed with a similar method to that described 549 in [RFC6298]. 551 rtp_queue_size (0 bits) 552 Size of RTP packets in queue. 554 rtp_size (0 byte) 555 Size of the last transmitted RTP packet. 557 loss_event_rate (0.0) 558 The estimated fraction of RTTs with lost packets detected. 560 4.1.2. Network congestion control 562 This section explains the network congestion control, it contains two 563 main functions: 565 o Computation of congestion window at the sender: Gives an upper 566 limit to the number of bytes in flight. 568 o Calculation of send window at the sender: RTP packets are 569 transmitted if allowed by the relation between the number of bytes 570 in flight and the congestion window. This is controlled by the 571 send window. 573 SCReAM is a window based and byte oriented congestion control 574 protocol, where the number of bytes transmitted is inferred from the 575 size of the transmitted RTP packets. Thus a list of transmitted RTP 576 packets and their respective transmission times (wall-clock time) is 577 kept for further calculation. 579 The number of bytes in flight (bytes_in_flight) is computed as the 580 sum of the sizes of the RTP packets ranging from the RTP packet most 581 recently transmitted down to but not including the acknowledged 582 packet with the highest sequence number. This can be translated to 583 the difference between the highest transmitted byte sequence number 584 and the highest acknowledged byte sequence number. As an example: If 585 RTP packet with sequence number SN is transmitted and the last 586 acknowledgement indicates SN-5 as the highest received sequence 587 number then bytes in flight is computed as the sum of the size of RTP 588 packets with sequence number SN-4, SN-3, SN-2, SN-1 and SN, it does 589 not matter if for instance packet with sequence number SN-3 was lost, 590 the size of RTP packet with sequence number SN-3 will still be 591 considered in the computation of bytes_in_flight. 593 Furthermore, a variable bytes_newly_acked is incremented with a value 594 corresponding to how much the highest sequence number has increased 595 since the last feedback. As an example: If the previous 596 acknowledgement indicated the highest sequence number N and the new 597 acknowledgement indicated N+3, then bytes_newly_acked is incremented 598 by a value equal to the sum of the sizes of RTP packets with sequence 599 number N+1, N+2 and N+3. Packets that are lost are also included, 600 which means that even though e.g packet N+2 was lost, its size is 601 still included in the update of bytes_newly_acked. The 602 bytes_newly_acked variable is reset after a CWND update. 604 The feedback from the receiver is assumed to consist of the following 605 elements. More details are found in Appendix A.4. 607 o A list of received RTP packets. 609 o The wall clock timestamp corresponding to the received RTP packet 610 with the highest sequence number. 612 o Accumulated number of ECN-CE marked packets (n_ECN). 614 When the sender receives RTCP feedback, the qdelay is calculated as 615 outlined in [RFC6817]. A qdelay sample is obtained for each received 616 acknowledgement. No smoothing of the qdelay samples occur, however 617 some smoothing occurs anyway as the computation of the CWND is a low 618 pass filter function. A number of variables are updated as 619 illustrated by the pseudo code below, temporary variables are 620 appended with '_t'. Note that the pseudo code does not show all 621 details for reasons of readability, the reader is encouraged to look 622 into the C++ code in [SCReAM-CPP-implementation] for the details. 624 update_variables(qdelay): 625 qdelay_fraction_t = qdelay/qdelay_target 626 #calculate moving average 627 qdelay_fraction_avg = (1-QDELAY_WEIGHT)*qdelay_fraction_avg+ 628 QDELAY_WEIGHT*qdelay_fraction_t 629 update_qdelay_fraction_hist(qdelay_fraction_t) 630 # R is an autocorrelation function of qdelay_fraction_hist 631 # at lag K 632 a = R(qdelay_fraction_hist,1)/R(qdelay_fraction_hist,0) 633 #calculate qdelay trend 634 qdelay_trend = min(1.0,max(0.0,a*qdelay_fraction_avg)) 635 #calculate a 'peak-hold' qdelay_trend, this gives a memory 636 # of congestion in the past 637 qdelay_trend_mem = max(0.99*qdelay_trend_mem, qdelay_trend) 639 The qdelay fraction is sampled every 50ms and the last 20 samples are 640 stored in a vector (qdelay_fraction_hist). This vector is used in 641 the computation of an qdelay trend that gives a value between 0.0 and 642 1.0 depending on the estimated congestion level. The prediction 643 coefficient 'a' has positive values if qdelay shows an increasing 644 trend, thus an indication of congestion is obtained before the qdelay 645 target is reached. The autocorrelation function 'R' is defined in 646 Appendix A.2. The prediction coefficient is further multiplied with 647 qdelay_fraction_avg to reduce sensitivity to increasing qdelay when 648 it is very small. The 50ms sampling is a simplification and may have 649 the effect that the same qdelay is sampled several times, this does 650 however not pose any problem a the vector is only used to determine 651 if the qdelay is increasing or decreasing. The qdelay_trend is 652 utilized in the media rate control to indicate incipient congestion 653 and to determine when to exit from fast increase mode. 654 qdelay_trend_mem is used to enforce a less aggressive rate increase 655 after congestion events. The function 656 update_qdelay_fraction_hist(..) removes the oldest element and adds 657 the latest qdelay_fraction element to the qdelay_fraction_hist 658 vector. 660 A loss event is indicated if one or more RTP packets are declared 661 missing. The loss detection is described in Section 4.1.2.3. Once a 662 loss event is detected, further detected lost RTP packets are ignored 663 for a full smoothed round trip time, the intention of this is to 664 limit the congestion window decrease to at most once per round trip. 665 The congestion window back off due to loss events is deliberately a 666 bit less than is the case with e.g. TCP Reno. The reason is that 667 TCP is generally used to transmit whole files, which can be 668 translated to an infinite source bitrate. SCReAM on the other hand 669 has a source whose rate is limited to a value close to the available 670 transmit rate and often below that value, the effect of this is that 671 SCReAM has less opportunity to grab free capacity than a TCP based 672 file transfer. To compensate for this it is necessary to let SCReAM 673 reduce the congestion window slightly less than what is the case with 674 TCP when loss events occur. 676 An ECN event is detected if the n_ECN counter in the feedback report 677 has increased since the previous received feedback. Once an ECN 678 event is detected, the n_ECN counter is ignored for a full smoothed 679 round trip time, the intention of this is to limit the congestion 680 window decrease to at most once per round trip. The congestion 681 window back off due to an ECN event is deliberately smaller than if a 682 loss event occurs. This is in line with the idea outlined in 683 [Khademi-alternative-backoff-ECN] to enable ECN marking thresholds 684 lower than the corresponding packet drop thresholds. 686 The update of the congestion window depends on whether loss or ECN- 687 marking or neither occurs. The pseudo code below describes actions 688 taken in case of the different events. 690 on congestion event(qdelay): 691 # Either loss or ECN mark is detected 692 in_fast_increase = false 693 if (is loss) 694 # loss is detected 695 cwnd = max(min_cwnd,cwnd*BETA_LOSS) 696 else 697 # No loss, so it is then an ECN mark 698 cwnd = max(min_cwnd,cwnd*BETA_ECN) 699 end 700 adjust_qdelay_target(qdelay) #compensating for competing flows 701 calculate_send_window(qdelay,qdelay_target) 703 # when no congestion event 704 on acknowledgement(qdelay): 705 update_bytes_newly_acked() 706 update_cwnd(bytes_newly_acked) 707 adjust_qdelay_target(qdelay) #compensating for competing flows 708 calculate_send_window(qdelay, qdelay_target) 709 check_to_resume_fast_increase() 711 The methods are further described in detail below. 713 4.1.2.1. Congestion window update 715 The congestion window update is based on qdelay, except for the 716 occurrence of loss events (one or more lost RTP packets in one RTT), 717 or ECN events, which was described earlier. 719 Pseudo code for the update of the congestion window is found below. 721 update_cwnd(bytes_newly_acked): 723 # in fast increase ? 724 if (in_fast_increase) 725 if (qdelay_trend >= QDELAY_TREND_TH) 726 # incipient congestion detected, exit fast increase 727 in_fast_increase = false 728 else 729 # no congestion yet, increase cwnd if it 730 # is sufficiently used 731 # an additional slack of bytes_newly_acked is 732 # added to ensure that CWND growth occurs 733 # even when feedback is sparse 734 if (bytes_in_flight*1.5+bytes_newly_acked > cwnd) 735 cwnd = cwnd+bytes_newly_acked 736 end 737 return 738 end 739 end 741 # not in fast increase phase 742 # off_target calculated as with LEDBAT 743 off_target_t = (qdelay_target - qdelay) / qdelay_target 745 gain_t = GAIN 746 # adjust congestion window 747 cwnd_delta_t = 748 gain_t * off_target_t * bytes_newly_acked * MSS / cwnd 749 if (off_target_t > 0 && bytes_in_flight*1.25+bytes_newly_acked <= cwnd) 750 # no cwnd increase if window is underutilized 751 # an additional slack of bytes_newly_acked is 752 # added to ensure that CWND growth occurs 753 # even when feedback is sparse 754 cwnd_delta_t = 0; 755 end 757 # apply delta 758 cwnd += cwnd_delta_t 759 # limit cwnd to the maximum number of bytes in flight 760 cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM) 761 cwnd = max(cwnd, MIN_CWND) 763 CWND is updated differently depending on whether the congestion 764 control is in fast increase state or not, as controlled by the 765 variable in_fast_increase. 767 When in fast increase state, the congestion window is increased with 768 the number of newly acknowledged bytes as long as the window is 769 sufficiently used. Sparse feedback can potentially limit congestion 770 window growth, an additional slack is therefore added, given by the 771 number of newly acknowledged bytes. 773 The congestion window growth when in_fast_increase is false is 774 dictated by the relation between qdelay and qdelay_target, congestion 775 window growth is limited if the window is not used sufficiently. 777 SCReAM calculates the GAIN in a similar way to what is specified in 778 [RFC6817]. There are however a few differences. 780 o [RFC6817] specifies a constant GAIN, this specification however 781 limits the gain when CWND is increased dependent on near 782 congestion state and the relation to the last known max CWND 783 value. 785 o [RFC6817] specifies that the CWND increase is limited by an 786 additional function controlled by a constant ALLOWED_INCREASE. 787 This additional limitation is removed in this specification. 789 Further the CWND is limited by max_bytes_in_flight and min_cwnd. The 790 limitation of the congestion window by the maximum number of bytes in 791 flight over the last 5 seconds (max_bytes_in_flight) avoids possible 792 over-estimation of the throughput after for example, idle periods. 793 An additional MAX_BYTES_IN_FLIGHT_HEAD_ROOM allows for a slack, to 794 allow for a certain amount of media coder output rate variability. 796 4.1.2.2. Competing flows compensation 798 It is likely that a flow using SCReAM algorithm will have to share 799 congested bottlenecks with other flows that use a more aggressive 800 congestion control algorithm. SCReAM takes care of such situations 801 by adjusting the qdelay_target. 803 adjust_qdelay_target(qdelay) 804 qdelay_norm_t = qdelay / QDELAY_TARGET_LOW 805 update_qdelay_norm_history(qdelay_norm_t) 806 # Compute variance 807 qdelay_norm_var_t = VARIANCE(qdelay_norm_history(200)) 808 # Compensation for competing traffic 809 # Compute average 810 qdelay_norm_avg_t = AVERAGE(qdelay_norm_history(50)) 811 # Compute upper limit to target delay 812 oh_t = qdelay_norm_avg_t + sqrt(qdelay_norm_var_t) 813 oh_t *= QDELAY_TARGET_LO 814 if (loss_event_rate > 0.002) 815 # Packet losses detected 816 qdelay_target = 1.5*oh_t 817 else 818 if (qdelay_norm_var_t < 0.2) 819 # Reasonably safe to set target qdelay 820 qdelay_target = oh_t 821 else 822 # Check if target delay can be reduced, this helps to avoid 823 # that the target delay is locked to high values for ever 824 if (oh_t < QDELAY_TARGET_LO) 825 # Decrease target delay quickly as measured queueing 826 # delay is lower than target 827 qdelay_target = max(qdelay_target*0.5,oh_t) 828 else 829 # Decrease target delay slowly 830 qdelay_target *= 0.9 831 end 832 end 833 end 835 # Apply limits 836 qdelay_target = min(QDELAY_TARGET_HI, qdelay_target) 837 qdelay_target = max(QDELAY_TARGET_LO, qdelay_target) 839 The qdelay_target is adjusted differently, depending on if 840 qdelay_norm_var_t is above or below a given value. 841 A low qdelay_norm_avg_t value indicates that the qdelay does not 842 change rapidly. It is desired to avoid the case that the qdelay 843 target is increased due to self-congestion, indicated by a changing 844 qdelay and consequently an increased qdelay_norm_var_t. Still it 845 should be possible to increase the qdelay target if the qdelay 846 continues to be high. This is a simple function with a certain risk 847 of both false positives and negatives. In the simulated LTE test 848 cases it manages competing FTP flows reasonably well at the same time 849 as generally avoiding accidental increases in the qdelay target. The 850 algorithm can however accidentally increase the qdelay target and 851 cause self-inflicted congestion in certain cases. It is therefore 852 recommended that the algorithm described in this section is turned 853 off it is deemed unlikely that competing flows occur over the same 854 bottleneck 856 4.1.2.3. Lost packet detection 858 Lost packet detection is based on the received sequence number list. 859 A reordering window should be applied to avoid packet reordering 860 triggering loss events. 861 The reordering window is specified as a time unit, similar to the 862 ideas behind RACK (Recent ACKnowledgement) [RACK]. The computation 863 of the reordering window is made possible by means of a lost flag in 864 the list of transmitted RTP packets. This flag is set if the 865 received sequence number list indicates that the given RTP packet is 866 missing. If a later feedback indicates that a previously lost marked 867 packet was indeed received, then the reordering window is updated to 868 reflect the reordering delay. The reordering window is given by the 869 difference in time between the event that the packet was marked as 870 lost and the event that it was indicated as successfully received. 871 Loss is detected if a given RTP packet is not acknowledged within a 872 time window (indicated by the reordering window) after an RTP packet 873 with higher sequence number was acknowledged. 875 4.1.2.4. Send window calculation 877 The basic design principle behind packet transmission in SCReAM is to 878 allow transmission only if the number of bytes in flight is less than 879 the congestion window. There are however two reasons why this strict 880 rule will not work optimally: 882 o Bitrate variations: The media frame size is always varying to a 883 larger or smaller extent. A strict rule can lead to that the 884 media bitrate will have difficulties to increase as the congestion 885 window puts a too hard restriction on the media frame size 886 variation. This can lead to occasional queuing of RTP packets in 887 the RTP packet queue that will prevent bitrate increase. 889 o Reverse (feedback) path congestion: Especially in transport over 890 buffer-bloated networks, the one way delay in the reverse 891 direction may jump due to congestion. The effect of this is that 892 the acknowledgements are delayed with the result that the self- 893 clocking is temporarily halted, even though the forward path is 894 not congested. 896 The send window is adjusted depending on qdelay and its relation to 897 the qdelay target and the relation between the congestion window and 898 the number of bytes in flight. A strict rule is applied when qdelay 899 is higher than qdelay_target, to avoid further queue buildup in the 900 network. For cases when qdelay is lower than the qdelay_target, a 901 more relaxed rule is applied. This allows the bitrate to increase 902 quickly when no congestion is detected while still being able to give 903 a stable behavior in congested situations. 905 The send window is given by the relation between the adjusted 906 congestion window and the amount of bytes in flight according to the 907 pseudo code below. 909 calculate_send_window(qdelay, qdelay_target) 910 # send window is computed differently depending on congestion level 911 if (qdelay <= qdelay_target) 912 send_wnd = cwnd+MSS-bytes_in_flight 913 else 914 send_wnd = cwnd-bytes_in_flight 915 end 917 The send window is updated whenever an RTP packet is transmitted or 918 an RTCP feedback messaged is received. More details around sender 919 transmission control and packet pacing are found in Appendix A.3. 921 4.1.2.5. Resuming fast increase 923 Fast increase can resume in order to speed up the bitrate increase in 924 case congestion abates. The condition to resume fast increase 925 (in_fast_increase = true) is that qdelay_trend is less than 926 QDELAY_TREND_LO for T_RESUME_FAST_INCREASE seconds or more. 928 4.1.3. Media rate control 930 The media rate control algorithm is executed at regular intervals 931 RATE_ADJUSTMENT_INTERVAL, with the exception of a prompt reaction to 932 loss events. The media rate control operates based on the size of 933 the RTP packet send queue and observed loss events. In addition, 934 qdelay_trend is also considered in the media rate control to reduce 935 the amount of induced network jitter. 937 The role of the media rate control is to strike a reasonable balance 938 between a low amount of queuing in the RTP queue(s) and a sufficient 939 amount of data to send in order to keep the data path busy. A too 940 cautious setting leads to possible under-utilization of network 941 capacity leading to the flow being starved out by other more 942 opportunistic traffic. On the other hand too aggressive a setting 943 leads to extra jitter 945 The target_bitrate is adjusted depending on the congestion state. 946 The target bitrate can vary between a minimum value 947 (TARGET_BITRATE_MIN) and a maximum value (TARGET_BITRATE_MAX). 948 TARGET_BITRATE_MIN should be chosen to a low enough value to avoid 949 RTP packets being queued up when the network throughput becomes low. 950 The sender should also be equipped with a mechanism that discards RTP 951 packets in cases where the network throughput becomes very low and 952 RTP packets are excessively delayed. 954 For the overall bitrate adjustment, two network throughput estimates 955 are computed : 957 o rate_transmit: The measured transmit bitrate. 959 o rate_ack: The ACKed bitrate, i.e. the volume of ACKed bits per 960 time unit. 962 Both estimates are updated every 200ms. 964 The current throughput, current_rate, is computed as the maximum 965 value of rate_transmit and rate_ack. The rationale behind the use of 966 rate_ack in addition to rate_transmit is that rate_transmit is 967 affected also by the amount of data that is available to transmit, 968 thus a lack of data to transmit can be seen as reduced throughput 969 that may itself cause an unnecessary rate reduction. To overcome 970 this shortcoming; rate_ack is used as well. This gives a more stable 971 throughput estimate. 973 The rate change behavior depends on whether a loss or ECN event has 974 occurred and if the congestion control is in fast increase or not. 976 # The target_bitrate is updated at a regular interval according 977 # to RATE_ADJUST_INTERVAL 979 on loss: 980 # Loss event detected 981 target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN) 982 exit 983 on ecn_mark: 984 # ECN event detected 985 target_bitrate = max(BETA_ECN* target_bitrate, TARGET_BITRATE_MIN) 986 exit 988 ramp_up_speed_t = min(RAMP_UP_SPEED, target_bitrate/2.0) 989 scale_t = (target_bitrate - target_bitrate_last_max)/ 990 target_bitrate_last_max 991 scale_t = max(0.2, min(1.0, (scale_t*4)^2)) 992 # min scale_t value 0.2 as the bitrate should be allowed to 993 # increase at least slowly --> avoid locking the rate to 994 # target_bitrate_last_max 995 if (in_fast_increase = true) 996 increment_t = ramp_up_speed_t*RATE_ADJUST_INTERVAL 997 increment_t *= scale_t 998 target_bitrate += increment_t 999 else 1000 current_rate_t = max(rate_transmit, rate_ack) 1001 # compute a bitrate change 1002 delta_rate_t = current_rate_t*(1.0-PRE_CONGESTION_GUARD* 1003 queue_delay_trend)-TX_QUEUE_SIZE_FACTOR *rtp_queue_size 1004 # limit a positive increase if close to target_bitrate_last_max 1005 if (delta_rate_t > 0) 1006 delta_rate_t *= scale_t 1007 delta_rate_t = 1008 min(delta_rate_t,ramp_up_speed_t*RATE_ADJUST_INTERVAL) 1009 end 1010 target_bitrate += delta_rate_t 1011 # force a slight reduction in bitrate if RTP queue 1012 # builds up 1013 rtp_queue_delay_t = rtp_queue_size/current_rate_t 1014 if (rtp_queue_delay_t > RTP_QDELAY_TH) 1015 target_bitrate *= TARGET_RATE_SCALE_RTP_QDELAY 1016 end 1017 end 1019 rate_media_limit_t = max(current_rate_t, max(rate_media,rtp_rate_median)) 1020 rate_media_limit_t *= (2.0-qdelay_trend_mem) 1021 target_bitrate = min(target_bitrate, rate_media_limit_t) 1022 target_bitrate = min(TARGET_BITRATE_MAX, 1023 max(TARGET_BITRATE_MIN,target_bitrate)) 1025 In case of a loss event the target_bitrate is updated and the rate 1026 change procedure is exited. Otherwise the rate change procedure 1027 continues. The rationale behind the rate reduction due to loss is 1028 that a congestion window reduction will take effect, a rate reduction 1029 pro actively avoids RTP packets being queued up when the transmit 1030 rate decreases due to the reduced congestion window. A similar rate 1031 reduction happens when ECN events are detected. 1033 The rate update frequency is limited by RATE_ADJUST_INTERVAL, unless 1034 a loss event occurs. The value is based on experimentation with real 1035 life limitations in video coders taken into account 1036 [SCReAM-implementation-experience]. A too short interval is shown to 1037 make the video coder internal rate control loop more unstable, a too 1038 long interval makes the overall congestion control sluggish. 1040 When in fast increase state (in_fast_increase=true), the bitrate 1041 increase is given by the desired ramp-up speed (RAMP_UP_SPEED) . The 1042 ramp-up speed is limited when the target bitrate is low to avoid rate 1043 oscillation at low bottleneck bitrates. The setting of RAMP_UP_SPEED 1044 depends on preferences, a high setting such as 1000kbps/s makes it 1045 possible to quickly get high quality media, this is however at the 1046 expense of a higher risk of jitter, which can manifest itself as e.g. 1047 choppy video rendering. 1049 When in_fast_increase is false, the bitrate increase is given by the 1050 current bitrate and is also controlled by the estimated RTP queue and 1051 the qdelay trend, thus it is sufficient that an increased congestion 1052 level is sensed by the network congestion control to limit the 1053 bitrate. The target_bitrate_last_max is updated when congestion is 1054 detected. 1056 In cases where input stimuli to the media encoder is static, for 1057 instance in "talking head" scenarios, the target bitrate is not 1058 always fully utilized. This may cause undesirable oscillations in 1059 the target bitrate in the cases where the link throughput is limited 1060 and the media coder input stimuli changes between static and varying. 1061 To overcome this issue, the target bitrate is capped to be less than 1062 a given multiplier of a median value of the history of media coder 1063 output bitrates, rate_media_limit. A multiplier is applied to 1064 rate_media_limit, depending on congestion history. The 1065 target_bitrate is then limited by this rate_media_limit. 1067 Finally the target_bitrate is enforced to be within the defined min 1068 and max values. 1070 The aware reader may notice the dependency on the qdelay in the 1071 computation of the target bitrate, this manifests itself in the use 1072 of the qdelay_trend. As these parameters are used also in the 1073 network congestion control one may suspect some odd interaction 1074 between the media rate control and the network congestion control, 1075 this is in fact the case if the parameter PRE_CONGESTION_GUARD is set 1076 to a high value. The use of qdelay_trend in the media rate control 1077 is solely to reduce jitter, the dependency can be removed by setting 1078 PRE_CONGESTION_GUARD=0, the effect is a somewhat faster rate increase 1079 after congestion, at the expense of more jitter in congested 1080 situations. 1082 4.1.3.1. FEC and packet overhead considerations 1084 The target bitrate given by SCReAM depicts the bitrate including RTP 1085 and FEC overhead. Therefore it is necessary that the media encoder 1086 takes this overhead into account when the media bitrate is set. This 1087 means that the media coder bitrate should be computed as 1088 media_rate = target_bitrate - rtp_plus_fec_overhead_bitrate 1090 It is not strictly necessary to make a 100% perfect compensation for 1091 the overhead as the SCReAM algorithm will inherently compensate for 1092 moderate errors. Under-compensation of the overhead has the effect 1093 of increasing jitter while overcompensation will have the effect of 1094 causing the bottleneck link to become under-utilized. 1096 4.2. SCReAM Receiver 1098 The simple task of the SCReAM receiver is to feedback 1099 acknowledgements of received packets and total ECN count to the 1100 SCReAM sender, in addition, the receive time of the RTP packet with 1101 the highest sequence number is echoed back. Upon reception of each 1102 RTP packet the receiver must maintain enough information to send the 1103 aforementioned values to the SCReAM sender via a RTCP transport layer 1104 feedback message. The frequency of the feedback message depends on 1105 the available RTCP bandwidth. More details of the feedback and the 1106 frequency is found in Appendix A.4. 1108 5. Discussion 1110 This section covers a few discussion points 1112 o Clock drift: SCReAM can suffer from the same issues with clock 1113 drift as is the case with LEDBAT [RFC6817]. Section A.2 in 1114 [RFC6817] however describes ways to mitigate issues with clock 1115 drift. 1117 o Support for alternate ECN semantics: This specification adopts the 1118 proposal in [Khademi-alternative-backoff-ECN] to reduce the 1119 congestion window less when ECN based congestion events are 1120 detected. Future work on Low Latency Low Loss for Scalable 1121 throughput (L4S) may lead to updates in a future RFC that 1122 describes SCReAM support for L4S. 1124 6. Implementation status 1126 [Editor's note: Please remove the whole section before publication, 1127 as well reference to RFC 6982] 1129 This section records the status of known implementations of the 1130 protocol defined by this specification at the time of posting of this 1131 Internet-Draft, and is based on a proposal described in [RFC6982]. 1132 The description of implementations in this section is intended to 1133 assist the IETF in its decision processes in progressing drafts to 1134 RFCs. Please note that the listing of any individual implementation 1135 here does not imply endorsement by the IETF. Furthermore, no effort 1136 has been spent to verify the information presented here that was 1137 supplied by IETF contributors. This is not intended as, and must not 1138 be construed to be, a catalog of available implementations or their 1139 features. Readers are advised to note that other implementations may 1140 exist. 1142 According to [RFC6982], "this will allow reviewers and working groups 1143 to assign due consideration to documents that have the benefit of 1144 running code, which may serve as evidence of valuable experimentation 1145 and feedback that have made the implemented protocols more mature. 1146 It is up to the individual working groups to use this information as 1147 they see it". 1149 6.1. OpenWebRTC 1151 The SCReAM algorithm has been implemented in the OpenWebRTC project 1152 [OpenWebRTC], an open source WebRTC implementation from Ericsson 1153 Research. This SCReAM implementation is usable with any WebRTC 1154 endpoint using OpenWebRTC. 1156 o Organization : Ericsson Research, Ericsson. 1158 o Name : OpenWebRTC gst plug-in. 1160 o Implementation link : The GStreamer plug-in code for SCReAM can be 1161 found at github repository [SCReAM-implementation] The wiki 1162 (https://github.com/EricssonResearch/openwebrtc/wiki) contains 1163 required information for building and using OpenWebRTC. 1165 o Coverage : The code implements the specification in this memo. 1166 The current implementation has been tuned and tested to adapt a 1167 video stream and does not adapt the audio streams. 1169 o Implementation experience : The implementation of the algorithm in 1170 the OpenWebRTC has given great insight into the algorithm itself 1171 and its interaction with other involved modules such as encoder, 1172 RTP queue etc. In fact it proves the usability of a self-clocked 1173 rate adaptation algorithm in the real WebRTC system. The 1174 implementation experience has led to various algorithm 1175 improvements both in terms of stability and design. The current 1176 implementation use an n_loss counter for lost packets indication, 1177 this is subject to change in later versions to a list of received 1178 RTP packets. 1180 o Contact : irc://chat.freenode.net/openwebrtc 1182 6.2. A C++ Implementation of SCReAM 1184 o Organization : Ericsson Research, Ericsson. 1186 o Name : SCReAM. 1188 o Implementation link : A C++ implementation of SCReAM is available 1189 at[SCReAM-CPP-implementation]. The code includes full support for 1190 congestion control, rate control and multi stream handling, it can 1191 be integrated in web clients given the addition of extra code to 1192 implement the RTCP feedback and RTP queue(s). The code also 1193 includes a rudimentary implementation of a simulator that allows 1194 for some initial experiments. 1196 o Coverage : The code implements the specification in this memo. 1198 o Contact : ingemar.s.johansson@ericsson.com 1200 7. Suggested experiments 1202 SCReAM has been evaluated in a number of different ways, most of the 1203 evaluation has been in simulator. The OpenWebRTC implementation work 1204 involved extensive testing with artificial bottlenecks with varying 1205 bandwidths and using two different video coders (OpenH264 and VP9), 1206 the experience of this lead to further improvements of the media rate 1207 control logic. 1209 Further experiments are preferably done by means of implementation in 1210 real clients and web browsers. Recommended experiments are: 1212 o Trials with various access technologies: EDGE/3G/4G, WiFi, DSL. 1214 o Trials with different kinds of media: Audio, Video, slide show 1215 content. Evaluation of multi stream handling in SCReAM. 1217 o Evaluation of functionality of competing flows compensation 1218 mechanism: Evaluate how SCReAM performs with competing TCP like 1219 traffic and to what extent the competing flows compensation causes 1220 self-inflicted congestion. 1222 o Determine proper parameters: A set of default parameters are given 1223 that makes SCReAM work over a reasonably large operation range, 1224 however for instance for very low or very high bitrates it may be 1225 necessary to use different values for instance for the 1226 RAMP_UP_SPEED. 1228 8. Acknowledgements 1230 We would like to thank the following persons for their comments, 1231 questions and support during the work that led to this memo: Markus 1232 Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, 1233 Hans Hannu, Nikolas Hermanns, Stefan Haakansson, Erlendur Karlsson, 1234 Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard 1235 Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aalund. Many 1236 additional thanks to RMCAT chairs Karen E. E. Nielsen and Mirja 1237 Kuehlewind for patiently reading, suggesting improvements and also 1238 for asking all the difficult but necessary questions. Thanks to 1239 Stefan Holmer, Xiaoqing Zhu, Safiqul Islam and David Hayes for the 1240 additional review of this document. Thanks to Ralf Globisch for 1241 taking time to try out SCReAM in his challenging low bitrate use 1242 cases. 1244 9. IANA Considerations 1246 A new RFC4585 transport layer feedback message may to be standardized 1247 if the use of the already existing RTCP extensions as described in 1248 Appendix A.4 is not deemed sufficient. 1250 10. Security Considerations 1252 The feedback can be vulnerable to attacks similar to those that can 1253 affect TCP. It is therefore recommended that the RTCP feedback is at 1254 least integrity protected. Furthermore, as SCReAM is self-clocked, a 1255 malicious middlebox can drop RTCP feedback packets and thus cause the 1256 self-clocking in SCReAM to stall. This attack is however mitigated 1257 by the minimum send rate maintained by SCReAM when no feedback is 1258 received. 1260 11. Change history 1262 A list of changes: 1264 o WG-06 to WG-07: Updated based on WGLC review by David Hayes and 1265 Safiqul Islam 1267 o WG-05 to WG-06: Added list of suggested experiments 1269 o WG-04 to WG-05: Congestion control and rate control simplified 1270 somewhat 1272 o WG-03 to WG-04: Editorial fixes 1274 o WG-02 to WG-03: Review comments from Stefan Holmer and Xiaoqing 1275 Zhu addressed, owd changed to qdelay for clarity. Added appendix 1276 section with RTCP feedback requirements, including a suggested 1277 basic feedback format based Loss RLE report block and the Packet 1278 Receipt Times blocks in [RFC3611]. Loss detection added as a 1279 section. Transmission scheduling and packet pacing explained in 1280 appendix. Source quench semantics added to appendix. 1282 o WG-01 to WG-02: Complete restructuring of the document. Moved 1283 feedback message to a separate draft. 1285 o WG-00 to WG-01 : Changed the Source code section to Implementation 1286 status section. 1288 o -05 to WG-00 : First version of WG doc, moved additional features 1289 section to Appendix. Added description of prioritization in 1290 SCReAM. Added description of additional cap on target bitrate 1292 o -04 to -05 : ACK vector is replaced by a loss counter, PT is 1293 removed from feedback, references to source code added 1295 o -03 to -04 : Extensive changes due to review comments, code 1296 somewhat modified, frame skipping made optional 1298 o -02 to -03 : Added algorithm description with equations, removed 1299 pseudo code and simulation results 1301 o -01 to -02 : Updated GCC simulation results 1303 o -00 to -01 : Fixed a few bugs in example code 1305 12. References 1307 12.1. Normative References 1309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1310 Requirement Levels", BCP 14, RFC 2119, 1311 DOI 10.17487/RFC2119, March 1997, 1312 . 1314 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1315 Jacobson, "RTP: A Transport Protocol for Real-Time 1316 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1317 July 2003, . 1319 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1320 "Extended RTP Profile for Real-time Transport Control 1321 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1322 DOI 10.17487/RFC4585, July 2006, 1323 . 1325 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1326 Real-Time Transport Control Protocol (RTCP): Opportunities 1327 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 1328 2009, . 1330 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1331 "Computing TCP's Retransmission Timer", RFC 6298, 1332 DOI 10.17487/RFC6298, June 2011, 1333 . 1335 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 1336 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 1337 DOI 10.17487/RFC6817, December 2012, 1338 . 1340 12.2. Informative References 1342 [I-D.ietf-rmcat-app-interaction] 1343 Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP 1344 Application Interaction with Congestion Control", draft- 1345 ietf-rmcat-app-interaction-01 (work in progress), October 1346 2014. 1348 [I-D.ietf-rmcat-cc-codec-interactions] 1349 Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, 1350 "Congestion Control and Codec interactions in RTP 1351 Applications", draft-ietf-rmcat-cc-codec-interactions-02 1352 (work in progress), March 2016. 1354 [I-D.ietf-rmcat-coupled-cc] 1355 Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion 1356 control for RTP media", draft-ietf-rmcat-coupled-cc-04 1357 (work in progress), October 2016. 1359 [I-D.ietf-rmcat-scream-cc] 1360 Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 1361 for Multimedia", draft-ietf-rmcat-scream-cc-06 (work in 1362 progress), August 2016. 1364 [I-D.ietf-rmcat-wireless-tests] 1365 Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and 1366 M. Ramalho, "Evaluation Test Cases for Interactive Real- 1367 Time Media over Wireless Networks", draft-ietf-rmcat- 1368 wireless-tests-02 (work in progress), May 2016. 1370 [Khademi-alternative-backoff-ECN] 1371 "Alternative Backoff: Achieving Low Latency and High 1372 Throughput with ECN and AQM , CAIA Technical Report", 1373 . 1376 [LEDBAT-delay-impact] 1377 "Assessing LEDBAT's Delay Impact, IEEE communications 1378 letters, vol. 17, no. 5, May 2013", May 2013, 1379 . 1382 [OpenWebRTC] 1383 "Open WebRTC project.", . 1385 [Packet-conservation] 1386 "Congestion Avoidance and Control, ACM SIGCOMM Computer 1387 Communication Review 1988", 1988. 1389 [QoS-3GPP] 1390 TS 23.203, 3GPP., "Policy and charging control 1391 architecture", June 2011, . 1394 [RACK] "RACK: a time-based fast loss detection algorithm for 1395 TCP", . 1398 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 1399 "RTP Control Protocol Extended Reports (RTCP XR)", 1400 RFC 3611, DOI 10.17487/RFC3611, November 2003, 1401 . 1403 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 1404 and K. Carlberg, "Explicit Congestion Notification (ECN) 1405 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1406 2012, . 1408 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1409 Code: The Implementation Status Section", RFC 6982, 1410 DOI 10.17487/RFC6982, July 2013, 1411 . 1413 [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating 1414 TCP to Support Rate-Limited Traffic", RFC 7661, 1415 DOI 10.17487/RFC7661, October 2015, 1416 . 1418 [SCReAM-CPP-implementation] 1419 "C++ Implementation of SCReAM", 1420 . 1422 [SCReAM-implementation] 1423 "SCReAM Implementation", 1424 . 1427 [SCReAM-implementation-experience] 1428 "Updates on SCReAM : An implementation experience", 1429 . 1432 [TFWC] University College London, "Fairer TCP-Friendly Congestion 1433 Control Protocol for Multimedia Streaming", December 2007, 1434 . 1437 Appendix A. Additional information 1439 A.1. Stream prioritization 1441 The SCReAM algorithm makes a good distinction between network 1442 congestion control and the media rate control. This is easily 1443 extended to many streams, in which case RTP packets from two or more 1444 RTP queues are scheduled at the rate permitted by the network 1445 congestion control. 1447 The scheduling can be done by means of a few different scheduling 1448 regimes. For example the method applied in 1449 [I-D.ietf-rmcat-coupled-cc] can be used. The implementation of 1450 SCReAM [SCReAM-CPP-implementation] use credit based scheduling. In 1451 credit based scheduling, credit is accumulated by queues as they wait 1452 for service and are spent while the queues are being serviced. For 1453 instance, if one queue is allowed to transmit 1000bytes, then a 1454 credit of 1000bytes is allocated to the other unscheduled queues. 1455 This principle can be extended to weighted scheduling in which case 1456 the credit allocated to unscheduled queues depends on the relative 1457 weights. 1459 A.2. Computation of autocorrelation function 1461 The autocorrelation function is computed over a vector of values. 1463 Let x be a vector constituting N values, the biased autocorrelation 1464 function for a given lag=k for the vector x is given by . 1466 n=N-k 1467 R(x,k) = SUM x(n)*x(n+k) 1468 n=1 1470 A.3. Sender transmission control and packet pacing 1472 RTP packet transmission is allowed whenever the size of the next RTP 1473 packet in the sender queue is less than or equal to send window. As 1474 explained in Section 4.1.2.4 the send window is updated whenever an 1475 RTP packet is transmitted or RTCP feedback is received, the packet 1476 transmission rate is however restricted by means of packet pacing. 1478 Packet pacing is used in order to mitigate coalescing i.e. that 1479 packets are transmitted in bursts, with the increased risk of more 1480 jitter and potentially increased packet loss. The time interval 1481 between consecutive packet transmissions is enforced to be equal to 1482 or higher than t_pace where t_pace is given by the equations below : 1484 pace_bitrate = max (RATE_PACE_MIN, cwnd* 8 / s_rtt) 1485 t_pace = rtp_size * 8 / pace_bitrate 1487 rtp_size is the size of the last transmitted RTP packet, s_rtt is the 1488 smoothed round trip time. RATE_PACE_MIN=50000 is the minimum pacing 1489 rate. 1491 A.4. RTCP feedback considerations 1493 This section describes the requirements on the RTCP feedback to make 1494 SCReAM function well. First is described the requirements on the 1495 feedback elements, second is described the requirements on the 1496 feedback intensity to keep the SCReAM self-clocking and rate control 1497 loops function properly. 1499 A.4.1. Requirements on feedback elements 1501 SCReAM requires the following elements for its basic functionality, 1502 i.e. only including features that are strictly necessary in order to 1503 make SCReAM function. ECN is not included as basic functionality as 1504 it regarded as an additional feature that is not strictly necessary 1505 even though it can improve quality of experience quite considerably. 1507 o A list of received RTP packets. This list should be sufficiently 1508 long to cover all received RTP packets. This list can be realized 1509 with the Loss RLE report block in [RFC3611]. 1511 o A wall clock timestamp corresponding to the received RTP packet 1512 with the highest sequence number is required in order to compute 1513 the qdelay. This can be realized by means of the Packet Receipt 1514 Times Report Block in [RFC3611]. begin_seq should be set to the 1515 highest received (possibly wrapped around) sequence number, 1516 end_seq should be set to begin_seq+1 % 65536. The timestamp clock 1517 may be set according to [RFC3611] i.e. equal to the RTP timestamp 1518 clock. Detailed individual packet receive times is not necessary 1519 as SCReAM does currently not describe how this can be used. 1521 The basic feedback needed for SCReAM involves the use of the Loss RLE 1522 report block and the Packet Receipt Times block defined in Figure 2. 1524 0 1 2 3 1525 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 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 |V=2|P|reserved | PT=XR=207 | length | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | SSRC | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | BT=2 | rsvd. | T=0 | block length | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | SSRC of source | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | begin_seq | end_seq | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | chunk 1 | chunk 2 | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 : ... : 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | chunk n-1 | chunk n | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | BT=3 | rsvd. | T=0 | block length | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | SSRC of source | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | begin_seq | end_seq | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | Receipt time of packet begin_seq | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 Figure 2: Basic feedback message for SCReAM, based on RFC3611 1554 In a typical use case, no more than four Loss RLE chunks should be 1555 needed, thus the feedback message will be 44bytes. It is obvious 1556 from the figure that there is a lot of redundant information in the 1557 feedback message. A more optimized feedback format, including the 1558 additional feedback elements listed below, could reduce the feedback 1559 message size a bit. 1561 Additional feedback elements that can improve the performance of 1562 SCReAM are: 1564 o Accumulated number of ECN-CE marked packets (n_ECN). This can for 1565 instance be realized with the ECN Feedback Report Format in 1566 [RFC6679]. The given feedback report format is actually a slight 1567 overkill as SCReAM would do quite well with only a counter that 1568 increments by one for each received packet with the ECN-CE code 1569 point set. The more bulky format may be nevertheless be useful 1570 for e.g ECN black-hole detection. 1572 o Source quench bit (Q): Makes it possible to request the sender to 1573 reduce its congestion window. This is useful if WebRTC media is 1574 received from many hosts and it becomes necessary to balance the 1575 bitrates between the streams. This can currently not be realized 1576 with any standardized feedback format, however the ECN counter can 1577 be artificially incremented, even though no ECN-CE marked packets 1578 are received to achieve a similar behavior. 1580 A.4.2. Requirements on feedback intensity 1582 SCReAM benefits from a relatively frequent feedback. The feedback 1583 interval depends on the media bitrate. At low bitrates it is 1584 sufficient with a feedback interval of 100 to 400ms, while at high 1585 bitrates a feedback interval of roughly 20ms is to prefer. 1587 The numbers above can be formulated as feedback interval function 1588 that can be useful for the computation of the desired RTCP bandwidth. 1589 The following equation expresses the feedback rate: 1591 rate_fb = min(50,max(2.5,rate_media/10000)) 1593 rate_media is the RTP media bitrate expressed in [bits/s], rate_fb is 1594 the feedback rate expressed in [packets/s]. Converted to feedback 1595 interval we get: 1597 fb_int = 1.0/min(50,max(2.5,rate_media/10000)) 1599 The transmission interval is not critical, this means that in the 1600 case of multi-stream handling between two hosts, the feedback for two 1601 or more SSRCs can be bundled to save UDP/IP overhead, the final 1602 realized feedback interval should however not exceed 2*fb_int in such 1603 cases meaning that a scheduled feedback transmission event should not 1604 be delayed more that fb_int. 1606 SCReAM works with AVPF regular mode, immediate or early mode is not 1607 required by SCReAM but may nonetheless be useful for e.g RTCP 1608 messages not directly related to SCReAM, such as those specified in 1609 [RFC4585]. It is recommended to use reduced size RTCP [RFC5506] 1610 where regular full compound RTCP transmission is controlled by trr- 1611 int as described in [RFC4585]. 1613 A.5. Q-bit semantics (source quench) 1615 The Q bit in the feedback is set by a receiver to signal that the 1616 sender should reduce the bitrate. The sender will in response to 1617 this reduce the congestion window with the consequence that the video 1618 bitrate decreases. A typical use case for source quench is when a 1619 receiver receives streams from sources located at different hosts and 1620 they all share a common bottleneck, typically it is difficult to 1621 apply any rate distribution signaling between the sending hosts. The 1622 solution is then that the receiver sets the Q bit in the feedback to 1623 the sender that should reduce its rate, if the streams share a common 1624 bottleneck then the released bandwidth due to the reduction of the 1625 congestion window for the flow that had the Q bit set in the feedback 1626 will be grabbed by the other flows that did not have the Q bit set. 1627 This is ensured by the opportunistic behavior of SCReAM's congestion 1628 control. The source quench will have no or little effect if the 1629 flows do not share the same bottleneck. 1631 The reduction in congestion window is proportional to the amount of 1632 SCReAM RTCP feedback with the Q bit set, the below steps outline how 1633 the sender should react to RTCP feedback with the Q bit set. The 1634 reduction is done once per RTT. Let : 1636 o n = Number of received RTCP feedback messages in one RTT 1638 o n_q = Number of received RTCP feedback messages in one RTT, with Q 1639 bit set. 1641 The new congestion window is then expressed as: 1643 cwnd = max(MIN_CWND, cwnd*(1.0-0.5*n_q/n)) 1645 Note that CWND is adjusted at most once per RTT. Furthermore The 1646 CWND increase should be inhibited for one RTT if CWND has been 1647 decreased as a result of Q bits set in the feedback. 1649 The required intensity of the Q-bit set in the feedback in order to 1650 achieve a given rate distribution depends on many factors such as 1651 RTT, video source material etc. The receiver thus need to monitor 1652 the change in the received video bitrate on the different streams and 1653 adjust the intensity of the Q-bit accordingly. 1655 Authors' Addresses 1657 Ingemar Johansson 1658 Ericsson AB 1659 Laboratoriegraend 11 1660 Luleaa 977 53 1661 Sweden 1663 Phone: +46 730783289 1664 Email: ingemar.s.johansson@ericsson.com 1666 Zaheduzzaman Sarker 1667 Ericsson AB 1668 Laboratoriegraend 11 1669 Luleaa 977 53 1670 Sweden 1672 Phone: +46 761153743 1673 Email: zaheduzzaman.sarker@ericsson.com