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