idnits 2.17.1 draft-johansson-rmcat-scream-cc-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (October 27, 2014) is 3463 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.alvestrand-rmcat-congestion' is defined on line 936, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-alvestrand-rmcat-congestion-02 == Outdated reference: A later version (-02) exists of draft-sarker-rmcat-cellular-eval-test-cases-00 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-newcwv-07 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: Informational Ericsson AB 5 Expires: April 30, 2015 October 27, 2014 7 Self-Clocked Rate Adaptation for Multimedia 8 draft-johansson-rmcat-scream-cc-03 10 Abstract 12 This memo describes a rate adaptation framework for conversational 13 video services. The solution conforms to the packet conservation 14 principle and uses a hybrid loss and delay based congestion control 15 algorithm. The framework is evaluated over both simulated bottleneck 16 scenarios as well as in a LTE (Long Term Evolution) system simulator 17 and is shown to achieve both low latency and high video throughput in 18 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 April 30, 2015. 37 Copyright Notice 39 Copyright (c) 2014 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. The adaptation framework . . . . . . . . . . . . . . . . . . 4 58 3.1. Congestion control . . . . . . . . . . . . . . . . . . . 7 59 3.2. Transmission scheduling . . . . . . . . . . . . . . . . . 8 60 3.3. Media rate control . . . . . . . . . . . . . . . . . . . 8 61 4. Detailed description . . . . . . . . . . . . . . . . . . . . 8 62 4.1. Network congestion control . . . . . . . . . . . . . . . 8 63 4.1.1. Congestion window update . . . . . . . . . . . . . . 9 64 4.1.1.1. Initial steps . . . . . . . . . . . . . . . . . . 9 65 4.1.1.2. Loss event is detected . . . . . . . . . . . . . 11 66 4.1.1.3. If in_exponential_start = true and no loss event 67 detected . . . . . . . . . . . . . . . . . . . . 11 68 4.1.1.4. If in_exponential_start = false and no loss event 69 detected . . . . . . . . . . . . . . . . . . . . 11 70 4.1.1.5. Fairness enforcement . . . . . . . . . . . . . . 11 71 4.1.1.6. Final CWND adjustment step . . . . . . . . . . . 12 72 4.1.1.7. Competing flows compensation, adjustment of 73 owd_target . . . . . . . . . . . . . . . . . . . 12 74 4.1.2. Transmission scheduling . . . . . . . . . . . . . . . 13 75 4.1.2.1. Transmission decision . . . . . . . . . . . . . . 13 76 4.1.2.2. Next transmission attempt . . . . . . . . . . . . 14 77 4.2. Video rate control . . . . . . . . . . . . . . . . . . . 14 78 4.2.1. Frame skipping . . . . . . . . . . . . . . . . . . . 15 79 4.2.2. Rate change . . . . . . . . . . . . . . . . . . . . . 16 80 4.2.2.1. Reduce rate . . . . . . . . . . . . . . . . . . . 17 81 4.2.2.2. Increase rate . . . . . . . . . . . . . . . . . . 18 82 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 10. Change history . . . . . . . . . . . . . . . . . . . . . . . 20 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 90 11.2. Informative References . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 93 1. Introduction 95 Rate adaptation is considered as an important part of a interactive 96 realtime communication as the transmission channel bandwidth may vary 97 over period of time. Wireless access such as LTE (Long Term 98 Evolution), which is an integral part of the current Internet, 99 increases the importance of rate adaptation as the channel bandwidth 100 of a default LTE bearer [QoS-3GPP] can change considerably in a very 101 short time frame. Thus a rate adaptation solution for interactive 102 realtime media, such as WebRTC, in LTE system must be both quick and 103 be able to operate over a large span in available channel bandwidth. 104 This memo describes a solution that borrows the self-clocking 105 principle of TCP and combines it with a new delay based rate 106 adaptation algorithm, LEDBAT [RFC6817]. Because neither TCP nor 107 LEDBAT was designed for interactive realtime media, a few extra 108 features are needed to make the concept work well with in this 109 context. This memo describes these extra features. 111 1.1. Wireless (LTE) access properties 113 [I-D.draft-sarker-rmcat-cellular-eval-test-cases] introduces the 114 complications that can be observed in wireless environments. 115 Wireless access such as LTE can typically not guarantee a given 116 bandwidth, this is true especially for default bearers. The network 117 throughput may vary considerably for instance in cases where the 118 wireless terminal is moving around. 120 Unlike wireline bottlenecks with large statistical multiplexing it is 121 not possible to try to maintain a given bitrate when congestion is 122 detected with the hope that other flows will yield, this because 123 there are generally few other flows competing for the same 124 bottleneck. Each user gets its own variable throughput bottleneck, 125 where the throughput depends on factors like channel quality, load 126 and historical throughput. The bottom line is, if the throughput 127 drops, the sender has no other option than to reduce the bitrate. In 128 addition, the grace time, i.e. allowed reaction time from the time 129 that the congestion is detected until a reaction in terms of a rate 130 reduction is effected, is generally very short, in the order of one 131 RTT (Round Trip Time). 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC2119 [RFC2119] 139 3. The adaptation framework 141 The adaptation framework has similarities to concepts like TFWC 142 [TFWC]. One important property is self-clocking and compliance to 143 the packet conservation principle. The packet conservation principle 144 is described as an important key-factor behind the protection of 145 networks from congestion [FACK]. 147 The packet conservation principle is realized by including a vector 148 of the sequence numbers of received packets in the feedback from the 149 receiver back to the sender, the sender keeps a list of transmitted 150 packets and their respective sizes. This information is then used to 151 determine how many bytes can be transmitted. A congestion window 152 puts an upper limit on how many bytes can be in flight, i.e. 153 transmitted but not yet acknowledged. The congestion window is 154 determined in a way similar to LEDBAT [RFC6817]. This ensures that 155 the e2e latency is kept low. The basic functionality is quite 156 simple, there are however a few steps to take to make the concept 157 work with conversational media. These will be briefly described in 158 sections Section 3.1 to Section 3.3. 160 The feedback is over RTCP [RFC3550] and is based on [RFC4585]. It is 161 implemented as a transport layer feedback message, see proposed 162 example in Figure 1. The feedback control information part (FCI) 163 consists of the following elements. 165 o Timestamp: A timestamp value indicating when the last packet was 166 received which makes it possible to compute the one way (extra) 167 delay (OWD). 169 o The ACK list (Highest received sequence number + ACK vector): 170 Makes it possible to detect lost packets and determine the number 171 of bytes in flight. 173 o Source quench bit (Q): Makes it possible to request the sender to 174 reduce its congestion window. This is useful if WebRTC media is 175 received from many hosts and it becomes necessary to balance the 176 bitrates between the streams. The exact behavior and use for the 177 source quench bit is T.B.D. 179 o ECE (Explicit Congestion Notification) echo: Makes it possible to 180 indicate if packets are ECN-CE (ECN Congestion Experienced) 181 marked. The use for the ECN echo bits is T.B.D. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 |V=2|P| FMT | PT | length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | SSRC of packet sender | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | SSRC of media source | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Timestamp (32bits) | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Highest recv. seq. nr. (16b) |ECN echo |Q|R|R|R|R|R|R|R| 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | ACK vector (32b) | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 1: Transport layer feedback message 201 To make the feedback as frequent as possible, the feedback packets 202 are transmitted as reduced size RTCP according to [RFC5506]. 204 The timestamp clock time base is typically set to the same time base 205 as the media source in question but as the protocol described here is 206 not dependent on the media it can be set to a fixed value defined in 207 this specification. The ACK vector is here a bit vector that 208 indicates the reception of the last 1+32 = 33 RTP packets. 210 Section 4 describes the main algorithm details and how the feedback 211 is used. 213 ---------------------------- ----------------------------- 214 | Video encoder | | Video encoder | 215 ---------------------------- ----------------------------- 216 ^ | ^ ^ | ^ 217 (1)| (2)| (3)| (1)| (2)| (3)| 218 | RTP | | RTP | 219 | V | | V | 220 | ------------- | | ------------- | 221 ----------- | |-- ----------- | |-- 222 | Rate | (4) | Queue | | Rate | (4) | Queue | 223 | control |<----| | | control |<----| | 224 | | |RTP packets| | | |RTP packets| 225 ----------- | | ----------- | | 226 ------------- ------------- 227 | | 228 --------------- -------------- 229 (5)| |(5) 230 RTP RTP 231 | | 232 v v 233 -------------- ---------------- 234 | Network | (8) | Transmission | 235 | congestion |<-------->| scheduler | 236 | control | | | 237 -------------- ---------------- 238 ^ | 239 | (7) |(6) 240 ---------RTCP---------- RTP 241 | | 242 | v 243 ------------- 244 | UDP | 245 | socket | 246 ------------- 248 Figure 2: Rate adaptation framework 250 Figure 2 shows the functional overview of the adaptation framework. 251 Each media type or source implements rate control and a queue, where 252 RTP packets containing encoded media frames are temporarily stored 253 for transmission, the figure shows the details for when two video 254 sources are used. Video frames are encoded and forwarded to the 255 queue (2). The media rate adaptation adapts to the age of the oldest 256 RTP frame in the queue and controls the video bitrate (1). It is 257 also possible to make the video encoder skip frames and thus 258 temporarily reduce the frame rate if the queue age exceeds a given 259 threshold (3). The RTP packets are picked from each queue based on 260 some defined priority order or simply in a round robin fashion (5). 261 A transmission scheduler takes care of the transmission of RTP 262 packets, to be written to the UDP socket (6). In the general case 263 all media must go through the packet scheduler and is allowed to be 264 transmitted if the number of bytes in flight is less than the 265 congestion window. However audio frames can be allowed to be 266 transmitted as audio is typically low bitrate and thus contributes 267 little to congestion, this is however something that is left as an 268 implementation choice. RTCP packets are received (7) and the 269 information about bytes in flight and congestion window is exchanged 270 between the network congestion control and the transmission scheduler 271 (8). 273 The rate adaptation solution constitutes three parts; congestion 274 control, transmission scheduling and media rate adaptation. 276 3.1. Congestion control 278 The congestion control sets an upper limit on how much data can be in 279 the network (bytes in flight); this limit is called CWND (congestion 280 window) and is used in the transmission scheduling. 282 A congestion control method, similar to LEDBAT [RFC6817], measures 283 the OWD (one way delay). The congestion window is allowed to 284 increase if the OWD is below a predefined target, otherwise the 285 congestion window decreases. The delay target is typically set to 286 50-100ms. This ensures that the OWD is kept low on the average. The 287 reaction to loss events is similar to that of loss based TCP, i.e. an 288 instant reduction of CWND. 290 LEDBAT is designed with file transfers as main use case which means 291 that the algorithm must be modified somewhat to work with rate- 292 limited sources such as video. The modifications are 294 o Congestion window validation techniques. These are similar in 295 action as the method described in [I-D.ietf-tcpm-newcwv]. 297 o Fast start for bitrate increase. It makes the video bitrate ramp- 298 up within 5 to 10 seconds. The behavior is similar to TCP 299 slowstart. The fast start is exited when congestion is detected. 301 o Adaptive delay target. This helps the congestion control to 302 compete with FTP traffic to some degree. 304 3.2. Transmission scheduling 306 Transmission scheduling limits the output of data, given by the 307 relation between the number of bytes in flight and the congestion 308 window similar to TCP. Packet pacing is used to mitigate issues with 309 coalescing that may cause increased jitter in the media traffic. 311 3.3. Media rate control 313 The media rate control serves to adjust the media bitrate to ramp up 314 quickly enough to get a fair share of the system resources when link 315 throughput increases. 317 The reaction to reduced throughput must be prompt in order to avoid 318 getting too much data queued up in the sender frame queues. The 319 queuing delay is determined and the media bitrate is decreased if it 320 exceeds a threshold. 322 In cases where the sender frame queues increase rapidly such as the 323 case of a RAT (Radio Access Type) handover it may be necessary to 324 implement additional actions, such as discarding of encoded video 325 frames or frame skipping in order to ensure that the sender frame 326 queues are drained quickly. Frame skipping means that the frame rate 327 is temporarily reduced. Discarding of old video frames is a more 328 efficient way to reduce media latency than frame skipping but it 329 comes with a requirement to repair codec state, frame skipping is 330 thus to prefer as a first remedy. 332 4. Detailed description 334 This section describes the algorithm in more detail. It is split 335 between the network congetsion control and the video rate adaptation. 337 4.1. Network congestion control 339 This section explains the network congestion control, it contains two 340 main functions 342 o Computation of congestion window: Gives an upper limit to the 343 number of bytes in flight i.e. how many bytes that have been 344 transmitted but not yet acknowledged. 346 o Transmission scheduling: RTP packets are transmitted if allowed by 347 the relation between the number of bytes in flight and the 348 congestion window 350 Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an 351 RTP packet oriented protocol. Thus it keeps a list of transmitted 352 RTP packets and their respective sending times (wall-clock time). 353 The feedback indicates the highest received RTP sequence number and a 354 timestamp (wall-clock time) when it was received. In addition, an 355 ACK list is included to make it possible to determine lost packets 357 4.1.1. Congestion window update 359 Below is described the actions when an acknowledgement is received. 361 4.1.1.1. Initial steps 363 Bytes in flight (bytes_in_flight) is computed as the sum of the sizes 364 of the RTP packets ranging from the RTP packet most recently 365 transmitted up to but not including the acknowledged packet with the 366 highest sequence number. As an example: If RTP packet was sequence 367 number SN with transmitted and the last ACK indicated SN-5 as the 368 highest received sequence number then bytes in flight is computed as 369 the sum of the size of RTP packets with sequence number SN-4, SN-3, 370 SN-2, SN-1 and SN. 372 The congestion window is computed from the one way (extra) delay 373 estimates (OWD) that are obtained from the send and received 374 timestamp of the RTP packets. LEDBAT [RFC6817] explains the details 375 of the computation of the OWD. An OWD sample is obtained for each 376 received acknowledgement. No smoothing of the OWD samples occur, 377 however some smoothing occurs naturally as the computation of the 378 CWND is in itself a low pass filter function. 380 A variable bytes_newly_acked depicts the number bytes that was 381 acknowledged with the last received acknowledgement. 383 owd_mem is an EWMA (Exponential Weighted Moving Average) filtered OWD 385 owd_mem = max(owd_mem*0.5 + owd*0.5, owd_mem*0.9 + owd*0.1) 387 The OWD fraction is computed as 389 owd_fraction = owd/owd_target 391 where owd_target is the target (extra) delay, owd_target is typically 392 set to owd_target_lo=0.1s but can in certain cases increase to 393 owd_target_hi=0.4s. The OWD fraction is sampled every 50ms and the 394 last 20 samples are stored in a vector (owd_fraction_hist). This 395 vector is used in the computation of an OWD trend that gives a value 396 between 0.0 and 1.0 depending on how close to congestion it gets. 397 The OWD trend is calculated as follows 399 Let R(owd_fraction_hist,K) be the autocorrelation function of 400 owd_fraction_hist at lag K. The 1st order prediction coefficient is 401 formulated as 403 a = R(owd_fraction_hist,1)/R(owd_fraction_hist,0) 405 The prediction coefficient a has positive values if OWD shows an 406 increasing trend, thus one get an indication of congestion before the 407 OWD target is reached. The prediction coefficient is further 408 multiplied with owd_fraction to reduce sensitivity to increasing OWD 409 when OWD is small. The OWD trend is thus computed as 411 owd_trend = max(0.0,min(1.0,a*owd_fraction)) 413 The owd_trend is utilized in the media rate control and to determine 414 when to exit slow start. 416 An EWMA filtered version of owd_trend is computed 418 owd_trend_ewma=max(owd_trend, owd_trend_ewma*(1.0-alpha)+ 419 alpha* owd_trend) 421 alpha = (t_now-t_cwnd_update_prev) / 5000.0 423 t_now is the current wall clock time. 425 owd_fraction_avg is a lowpass filtered version of owd_fraction 427 owd_fraction_avg = 0.9* owd_fraction_avg + 0.1* owd_fraction 429 An off target value is computed as 431 off_target = (owd_target - owd) / owd_target 433 CWND is updated differently depending on whether the congestion 434 control is in fast start or not and if a loss event is detected. A 435 Boolean variable in_exponential_start (initialized to true) indicates 436 if the congestion is in fast start. 438 A loss event indicates one or more lost RTP packets within an RTT. 439 This is detected by means of inspection for holes in the sequence 440 number space in the acknowledgements with some margin for possible 441 packet reordering in the network. 443 4.1.1.2. Loss event is detected 445 If a loss event is detected then in_exponential_start is set to false 446 and CWND is updated according to 448 cwnd = max(min_cwnd,cwnd*0.8) where min_cwnd = 2*mss 450 otherwise the CWND update continues 452 4.1.1.3. If in_exponential_start = true and no loss event detected 454 in_exponential_start is set to false if owd_trend >= 0.2 and 455 otherwise CWND is updated according to 457 cwnd = cwnd + bytes_newly_acked 459 4.1.1.4. If in_exponential_start = false and no loss event detected 461 Values of off_target > 0.0 indicates that the congestion window can 462 be increased. This is done according to the equations below (mss is 463 the maximum RTP packet size). 465 gain = gain_up*(1.0 + max(0.0, 1.0 - owd_trend/ 0.2)) 467 cwnd += gain * off_target * bytes_newly_acked * mss / cwnd 469 Values of off_target <= 0.0 indicates congestion, CWND is then 470 updated according to the equation 472 cwnd += gain_down*off_target*bytes_newly_acked*mss/cwnd 474 4.1.1.5. Fairness enforcement 476 Fairness enforcement is realized by reducing the congestion window by 477 a fraction when a number of conditions are met. They are 479 o owd_target < owd_target_lo*1.2 i.e no competing flows are 480 compensated for 482 o owd_trend > 0.1 i.e. congestion is detected 484 o more than t_delta since the congestion window was reduced the last 485 time 487 t_delta is computed as 489 t_delta = 0.1*min(200.0, max(20.0, 50.0e6/max_paced_bitrate) 490 The bitrate is taken into account in the sense that the lower the 491 bitrate, the more sparse the reductions in congestion window get. 493 If the above conditions are met then cwnd is adjusted according to 495 cwnd *= 0.8 497 4.1.1.6. Final CWND adjustment step 499 The congestion window is limited by the maximum number of bytes in 500 flight over the last 1.0 seconds according to 502 cwnd = min(cwnd, max_bytes_in_flight*max_bytes_in_flight_head_room) 504 where max_bytes_in_flight_head_room = 1.1. This avoids possible 505 over-estimation of the throughput after for example, idle periods- 507 Finally cwnd is set to ensure that it is at least min_cwnd 509 cwnd = max(cwnd, min_cwnd) 511 4.1.1.7. Competing flows compensation, adjustment of owd_target 513 In certain cases it becomes necessary to increase owd_target, one 514 such case is where SCReAM competes with TCP based file transfer over 515 a tail drop bottleneck link and the TCP congestion avoidance is loss 516 based (for example Cubic or NewReno). The technique is to inhibit 517 video long enough to make bytes in flight reach zero (no remaining 518 RTP packets in flight) and then resume video. For the unfortunate 519 case that the last RTP packet was lost, it is necessary to force 520 video to resume after 1.0s as bytes in flight will never reach zero 521 in this case. 523 This interruption is typically in the order of one RTT. Once video 524 is resumed the average OWD (owd_avg_c_flow) is computed over the 525 first 5 acknowledgements after video is resumed. If no competing 526 flows exist then this average should be close to zero, otherwise 527 owd_avg_c_flow has a value that corresponds roughly to the queuing 528 delay caused by the competing flow. The owd_target is updated 529 according to the value of owd_avg_c_flow. 531 The method above is executed if more than a given time since the last 532 time video was inhibited (e.g. 20 seconds) and any of the two 533 conditions below are fulfilled 535 o owd_mem > owd_target 537 o owd_target > owd_target_lo 538 The first condition indicates that another competing flows is 539 possibly driving higher queuing delays in the network. The second 540 condition indicates that the OWD target is increased and it should be 541 determined if this can be lowered. Once owd_avg_c_flow is computed 542 the owd_target is adjusted. The adjustment action depends on the 543 value of owd_avg_c_flow 545 o If owd_avg_c_flow > owd_target_lo/2: 546 Adjust the owd_target upwards according to 547 owd_target = min(owd_target_hi, 548 max(owd_target, owd_avg_c_flow *3.0)) 550 o If owd_avg_c_flow <= owd_target_lo/2: 551 Adjust the owd_target downwards according to 552 owd_target = 0.5*owd_target+ 553 0.5*Math.max(owd_target_lo, owd_avg_c_flow). 554 Furhermore owd_target is set to owd_target_lo if it is less than 555 owd_target_lo*1.2. 557 4.1.2. Transmission scheduling 559 An RTP packet transmission attempt is scheduled at intervals given by 560 t_pace that depends on the estimated throughput, the RTT and the size 561 of the last transmitted RTP packet. This provides with packet pacing 562 which is in some cases necessary in order to break up coalescing 563 tendencies which can otherwise cause unwanted extra jitter or packet 564 loss. 566 4.1.2.1. Transmission decision 568 The principle is to allow packet transmission of an RTP packet only 569 if the number of bytes in flight is less than the congestion window. 570 There are however two reasons why this strict rule will not work 571 optimally 573 o Bitrate variations. The video frame size is always varying to a 574 larger or smaller extent, a strict rule as the one given above 575 will have the effect that the video bitrate have difficulties to 576 increase as the congestion window puts a too hard restriction on 577 the video frame size variation, this further can lead to 578 occasional queuing of RTP packets in the RTP packet queue that 579 will prevent bitrate increase because of the increased queuing 580 delay. 582 o Reverse (feedback) path congestion. Especially in transport over 583 buffer-bloated networks, the one way delay in the reverse 584 direction may jump due to congestion. The effect of this is that 585 the acknowledgements are delayed with the result that the self- 586 clocking is temporarily halted, even though the forward path is 587 not congested. 589 Transmission of an RTP packet of size rtp_size is thus allowed when 590 any of the following conditions is met. 592 o If owd > owd_target: 593 Transmission is allowed if 594 bytes_in_flight + rtp_size <= cwnd. 595 This enforces a strict rule that helps to prevent further queue 596 buildup. 598 o If owd <= owd_target: 599 A helper variable 600 x_cwnd=1.0+bytes_in_flight_slack*max(0.0, 601 min(1.0,1.0-owd_trend/0.5))/100.0 602 is computed. Transmission is allowed if 603 bytes_in_flight+rtp_size <= max(cwnd*x_cwnd, cwnd+mss) . 604 This gives a slack that reduces as congestion increases, 605 bytes_in_flight_slack is a maximum allowed slack in percent. 606 A large value such as 100% increases the robustness to bitrate 607 variations in the source and congested feedback channel issues. 608 The possible drawback is increased delay or packet loss when 609 forward path congestion occur. Recommended values are 20 to 50%. 611 4.1.2.2. Next transmission attempt 613 The interval until the next transmission attempt (t_pace) is set to 614 0.001s if no RTP packet was transmitted according to the decision in 615 previous section. Otherwise it is calculated as 617 max_paced_bitrate = max (50000, cwnd* 8 / s_rtt) 619 t_pace = rtp_size * 8 / max_paced_bitrate 621 4.2. Video rate control 623 The video rate control is based on the queuing delay in the RTP 624 packet queue and loss events. The video rate control function is 625 executed for each video frame. The actual video rate adjustment may 626 however be less frequent. The main reason is that there is typically 627 a lag between the bitrate request and the actual bitrate from the 628 video coder and this lag can be as much as 1 second. This makes it 629 less efficient to try to react to congestion with prompt rate 630 adjustments. The solution is to complement the rate reduction with 631 frame skipping in order to keep the RTP queuing delay limited. 633 The queuing delay is sampled every frame period and the last N_a 634 samples are stored in a vector age_vec. 636 An average queuing delay is computed as a weighted sum over the 637 samples in age_vec. age_avg at the current time instant n is computed 638 as 640 age_avg(n) = SUM age_vec(n-k)*w(k) 642 The sum is computed over k=[0..N_a-1] 644 w(n) are weight factors arranged to give the most recent samples a 645 higher weight. 647 N_a i.e. the number of samples that avg_age is computed over, depends 648 on how slow the video encoder is to respond to video rate change 649 requests. With a slow video encoder N_a is suggested to be set to 651 N_a = 1.0/frame_period 653 where frame_peridod is the video frame interval, 1.0 corresponds 654 roughly to the time constant in the video coder rate control loop 655 (1.0s). 657 If the video encoder is quicker to react to bitrate changes, N_a can 658 be set to a lower value such as N_a = 5. 660 avg_age is used for rate adjustment instead of the current value, the 661 reason is to avoid bitrate reduction because of temporal delay 662 spikes. Instead the video rate control is a combination of slower 663 rate adjustments and adjustments of the temporal frame rate by means 664 of raw frame skipping on a shorter time scale. This is an adaptation 665 to SCReAM as it works best when it has data to send because of its 666 self-clocking properties. The concept also avoids very large rate 667 reduction due to isolated delay spikes. 669 The change in age_avg is computed as 671 age_d = (age_avg(n) - age_avg(n-1))/frame_period 673 4.2.1. Frame skipping 675 Frame skipping is controlled by a flag frame_skip which, if set to 1, 676 dictates that the video coder should skip the next video frame. The 677 frame skipping intensity at the current time instant n is computed as 679 o If age_d > 0 and age_avg > frame_period: 680 The frame skip intensity is computed as 681 frame_skip_intensity = min(1.0, (age_vec(n)-frame_period)/(2* 682 frame_period) 684 o Otherwise frame skip intensity is set to zero 686 Note that the frame skipping intensity is computed based on the 687 current value of the queuing delay. Furthermore, frame skipping is 688 enabled only if the average queue delay increases and is large 689 enough. 691 The skip_frame flag is set depending on three variables 693 o frame_skip_intensity 695 o since_last_frame_skip, i.e the number of consecutive frames 696 without frame skipping 698 o consecutive_frame_skips, i.e the number of consecutive frame skips 700 The flag skip_frame is set to 1 if any of the conditions below is 701 met. 703 o age_vec(n) > 0.2 && consecutive_frame_skips < 5 705 o frame_skip_intensity < 0.5 && since_last_frame_skip >= 1.0/ 706 frame_skip_intensity 708 o frame_skip_intensity >= 0.5 && consecutive_frame_skips < 709 (frame_skip_intensity -0.5)*10 711 The arrangement makes sure that no more than 4 frames are skipped in 712 sequence, the rationale is to ensure that the input to the video 713 encoder does not change to much, something that may give poor 714 prediction gain. 716 4.2.2. Rate change 718 A variable target_bitrate is adjusted depending on the congestion 719 state. The target bitrate can vary between a minimum value 720 (target_bitrate_min) and a maximum value (target_bitrate_max). 722 First of all the target_bitrate is updated if a new loss event was 723 indicated and the rate change procedure is exited. 725 target_bitrate = max(0.9* target_bitrate, target_bitrate_min) 727 If no loss event was indicated then the rate change procedure 728 continues. Based on age_avg(n) and the time span since the last rate 729 reduction. A rate reduction condition is determined. This is 730 evaluated differently depending on whether an ideal video coder is 731 simulated for algorithm evaluation purposes or if the algorithm is 732 executed in a real implement with a video coder that lags behind in 733 the rate adjustment. 735 o Ideal mode: reduce_rate = age_avg(n) > frame_period/2 && t_now- 736 t_last_rate_change >= rate_change_interval && t_now- 737 t_last_rate_reduction > 0.5 739 o Non-ideal mode: reduce_rate = age_avg(n) > frame_period*2 && 740 t_now-t_last_rate_change >= rate_change_interval && t_now- 741 t_last_rate_reduction > video_coder_time_constant 743 rate_change_interval is set to 0.1s, video_coder_time_constant is set 744 to a value that approximates the lag in the video coder rate change. 746 4.2.2.1. Reduce rate 748 If reduce_rate evaluates to true then the bitrate is reduced. First 749 an inflection point is determined for later rate increase 751 target_bitrate_i = target_bitrate * 0.95 753 In addition, a restore point is determined for the case that false 754 congestion was detected, for instance as an effect of congestion in 755 the feedback path. 757 target_bitrate_restore_point = target_bitrate 759 A few varibles are updated for future use 761 t_last_rate_change = t_now 763 max_owd_fraction = max(max_owd_fraction, owd_fraction_avg) 765 A rate reduction factor is determined 767 alpha = min(0.5, max(0.0, 0.9*age_d)) 769 The target bitrate and t_last_rate_reduction are updated if 770 alpha > 0.0 according to 772 target_bitrate = max(target_bitrate_min, target_bitrate*(1.0-alpha)) 774 4.2.2.2. Increase rate 776 A rate increase is allowed if two conditions are met 778 o t_now-t_last_rate_change >= rate_change_interval 780 o age_avg(n) <= frame_period/2 782 First the target bitrate is restored if false congestion was 783 detected. This restoration is allowed if it it is more that 2.0s 784 since the last loss event and target_bitrate_restore_point > 0.0. 785 Further, if an additional condition 787 do_restore = max_owd_fraction < 0.4 && owd_trend_ewma < 0.2 789 evaluates to true then the target bitrate is restored as 791 target_bitrate = max(target_bitrate, target_bitrate_restore_point) 793 Regardless of whether do_restore evaluates to true or false 794 target_bitrate_restore_point is set to -1.0 and max_owd_fraction = 795 0.0 The target bitrate is increased, the increase rate depends on if 796 the algorithm is in slow start or not, indicated by the variable 797 in_exponential_start. 799 4.2.2.2.1. If in_exponential_start = true 801 The bitrate incremented is computed as 803 increment = 804 target_bitrate_max*rate_change_interval*ramp_up_time_fast* 805 (1.0-min(1.0, owd_trend/0.1)) 807 target_bitrate = min(target_bitrate_max, target_bitrate+increment)) 809 The target bitrate is allowed to reach the the highest bitrate within 810 ramp_up_time_fast seconds if no congestion is detected. A 811 recommended value for ramp_up_time_fast is 10.0s. 813 4.2.2.2.2. If in_exponential_start = false 815 The maximum allowed increment of the target bitrate is computed 817 increment_max = target_bitrate*0.2 819 A variable gain factor is computed in a number of steps, first the 820 gain factor is reduced if the target bitrate is close to the 821 inflection point i.e. the target bitrate when congestion was last 822 detected. 824 gain = max(0.2,min(1.0, abs((target_bitrate - target_bitrate_i)/ 825 target_bitrate_i)*4.0)) 827 Furthermore the gain is reduced if near (or past) congestion is 828 detected 830 gain *= min(1.0, max(0.0,(1.0-owd_trend_ewma))) 832 The gain is increased if competing (potentially aggressive) flows are 833 detected, this is indicated by that owd_target/owd_target_lo > 1.0 835 gain *= owd_target/owd_target_lo 837 A ramp-up speed is computed that is adjusted depending on the 838 estimated congestion level 840 ramp_up_time = ramp_up_time_fast+(ramp_up_time_slow- 841 ramp_up_time_fast)* 842 max(0.0,Math.min(1.0, owd_trend_ewma /0.2)) 844 A recommended value for ramp_up_time_slow is 20.0s. The increment is 845 computed and the target_bitrate is updated 847 increment = min(target_bitrate_max*gain*rate_change_interval 848 /(ramp_up_t), 849 increment_max) 851 target_bitrate = min(target_bitrate_max, target_bitrate +increment) 853 5. Conclusion 855 This memo describes a congestion control framework for RMCAT that it 856 is particularly good at handling the quickly changing condition in 857 wireless network such as LTE. The solution conforms to the packet 858 conservation principle and leverages on novel congestion control 859 algorithms and recent TCP research, together with media bitrate 860 determined by sender queuing delay and given delay thresholds. The 861 solution has shown potential to meet the goals of high link 862 utilization and prompt reaction to congestion. The solution is 863 realized with a new RFC4585 transport layer feedback message. 865 6. Open issues 867 A list of open issues. 869 o Describe use of Q bit 871 o Describe how clock drift compensation is done 873 o RTCP AVPF mode. Determine if AVPF early or immediate mode is to 874 prefer 876 o Determine format and use of ECN echo field 878 7. Acknowledgements 880 We would like to thank the following persons for their comments, 881 questions and support during the work that led to this memo: Markus 882 Andersson, Bo Burman, Tomas Frankkila, Laurits Hamm, Hans Hannu, 883 Nikolas Hermanns, Stefan Haekansson, Erlendur Karlsson, Mats 884 Nordberg, Jonathan Samuelsson, Rickard Sjoeberg, Magnus Westerlund. 886 8. IANA Considerations 888 A new RFC4585 transport layer feedback message needs to be 889 standardized. 891 9. Security Considerations 893 The feedback can be vulnerable to attacks similar to those that can 894 affect TCP. It is therefore recommended that the RTCP feedback is at 895 least integrity protected. 897 10. Change history 899 A list of changes: 901 o -02 to -03 : Added algorithm description with equations, removed 902 pseudo code and simulation results 904 o -01 to -02 : Updated GCC simulation results 906 o -00 to -01 : Fixed a few bugs in example code 908 11. References 909 11.1. Normative References 911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", BCP 14, RFC 2119, March 1997. 914 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 915 Jacobson, "RTP: A Transport Protocol for Real-Time 916 Applications", STD 64, RFC 3550, July 2003. 918 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 919 "Extended RTP Profile for Real-time Transport Control 920 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 921 2006. 923 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 924 Real-Time Transport Control Protocol (RTCP): Opportunities 925 and Consequences", RFC 5506, April 2009. 927 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 928 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 929 December 2012. 931 11.2. Informative References 933 [FACK] "Forward Acknowledgement: Refining TCP Congestion 934 Control", 2006. 936 [I-D.alvestrand-rmcat-congestion] 937 Holmer, S., Cicco, L., Mascolo, S., and H. Alvestrand, "A 938 Google Congestion Control Algorithm for Real-Time 939 Communication", draft-alvestrand-rmcat-congestion-02 (work 940 in progress), February 2014. 942 [I-D.draft-sarker-rmcat-cellular-eval-test-cases] 943 Sarker, Z., "Evaluation Test Cases for Interactive Real- 944 Time Media over Cellular Networks", 945 . 948 [I-D.ietf-tcpm-newcwv] 949 Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating 950 TCP to support Rate-Limited Traffic", draft-ietf-tcpm- 951 newcwv-07 (work in progress), September 2014. 953 [QoS-3GPP] 954 TS 23.203, 3GPP., "Policy and charging control 955 architecture", June 2011, . 958 [TFWC] University College London, "Fairer TCP-Friendly Congestion 959 Control Protocol for Multimedia Streaming", December 2007, 960 . 963 Authors' Addresses 965 Ingemar Johansson 966 Ericsson AB 967 Laboratoriegraend 11 968 Luleae 977 53 969 Sweden 971 Phone: +46 730783289 972 Email: ingemar.s.johansson@ericsson.com 974 Zaheduzzaman Sarker 975 Ericsson AB 976 Laboratoriegraend 11 977 Luleae 977 53 978 Sweden 980 Phone: +46 761153743 981 Email: zaheduzzaman.sarker@ericsson.com