idnits 2.17.1 draft-ietf-rmcat-coupled-cc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2929 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-ietf-rmcat-gcc-01 == Outdated reference: A later version (-13) exists of draft-ietf-rmcat-nada-02 == Outdated reference: A later version (-11) exists of draft-ietf-rmcat-sbd-04 == Outdated reference: A later version (-17) exists of draft-ietf-rtcweb-transports-11 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTP Media Congestion Avoidance S. Islam 3 Techniques (rmcat) M. Welzl 4 Internet-Draft S. Gjessing 5 Intended status: Experimental University of Oslo 6 Expires: September 22, 2016 March 21, 2016 8 Coupled congestion control for RTP media 9 draft-ietf-rmcat-coupled-cc-01 11 Abstract 13 When multiple congestion controlled RTP sessions traverse the same 14 network bottleneck, it can be beneficial to combine their controls 15 such that the total on-the-wire behavior is improved. This document 16 describes such a method for flows that have the same sender, in a way 17 that is as flexible and simple as possible while minimizing the 18 amount of changes needed to existing RTP applications. It specifies 19 how to apply the method for both the NADA and Google congestion 20 control algorithms. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 22, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Architectural overview . . . . . . . . . . . . . . . . . . . . 5 60 5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.3.1. Example algorithm 1 - Active FSE . . . . . . . . . . . 8 65 5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 8 66 6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 6.1. NADA . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.2. GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.3. General recommendations . . . . . . . . . . . . . . . . . 11 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Appendix A. Scheduling . . . . . . . . . . . . . . . . . . . . . 13 77 Appendix B. Example algorithm - Passive FSE . . . . . . . . . . . 13 78 B.1. Example operation (passive) . . . . . . . . . . . . . . . 16 79 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 20 80 C.1. draft-welzl-rmcat-coupled-cc . . . . . . . . . . . . . . . 20 81 C.1.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 20 82 C.1.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 20 83 C.1.3. Changes from -02 to -03 . . . . . . . . . . . . . . . 21 84 C.1.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 21 85 C.1.5. Changes from -04 to -05 . . . . . . . . . . . . . . . 21 86 C.2. draft-ietf-rmcat-coupled-cc . . . . . . . . . . . . . . . 21 87 C.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 . . . . . 21 88 C.2.2. Changes from -00 to -01 . . . . . . . . . . . . . . . 21 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 When there is enough data to send, a congestion controller must 94 increase its sending rate until the path's capacity has been reached; 95 depending on the controller, sometimes the rate is increased further, 96 until packets are ECN-marked or dropped. This process inevitably 97 creates undesirable queuing delay -- an effect that is amplified when 98 multiple congestion controlled connections traverse the same network 99 bottleneck. 101 The Congestion Manager (CM) [RFC3124] couples flows by providing a 102 single congestion controller. It is hard to implement because it 103 requires an additional congestion controller and removes all per- 104 connection congestion control functionality, which is quite a 105 significant change to existing RTP based applications. This document 106 presents a method to combine the behavior of congestion control 107 mechanisms that is easier to implement than the Congestion Manager 108 [RFC3124] and also requires less significant changes to existing RTP 109 based applications. It attempts to roughly approximate the CM 110 behavior by sharing information between existing congestion 111 controllers. It is able to honor user-specified priorities, which is 112 required by rtcweb [RFC7478]. 114 2. Definitions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 Available Bandwidth: 121 The available bandwidth is the nominal link capacity minus the 122 amount of traffic that traversed the link during a certain time 123 interval, divided by that time interval. 125 Bottleneck: 126 The first link with the smallest available bandwidth along the 127 path between a sender and receiver. 129 Flow: 130 A flow is the entity that congestion control is operating on. 131 It could, for example, be a transport layer connection, an RTP 132 session, or a subsession that is multiplexed onto a single RTP 133 session together with other subsessions. 135 Flow Group Identifier (FGI): 136 A unique identifier for each subset of flows that is limited by 137 a common bottleneck. 139 Flow State Exchange (FSE): 140 The entity that maintains information that is exchanged between 141 flows. 143 Flow Group (FG): 144 A group of flows having the same FGI. 146 Shared Bottleneck Detection (SBD): 147 The entity that determines which flows traverse the same 148 bottleneck in the network, or the process of doing so. 150 3. Limitations 152 Sender-side only: 153 Coupled congestion control as described here only operates 154 inside a single host on the sender side. This is because, 155 irrespective of where the major decisions for congestion 156 control are taken, the sender of a flow needs to eventually 157 decide the transmission rate. Additionally, the necessary 158 information about how much data an application can currently 159 send on a flow is often only available at the sender side, 160 making the sender an obvious choice for placement of the 161 elements and mechanisms described here. 163 Shared bottlenecks do not change quickly: 164 As per the definition above, a bottleneck depends on cross 165 traffic, and since such traffic can heavily fluctuate, 166 bottlenecks can change at a high frequency (e.g., there can be 167 oscillation between two or more links). This means that, when 168 flows are partially routed along different paths, they may 169 quickly change between sharing and not sharing a bottleneck. 170 For simplicity, here it is assumed that a shared bottleneck is 171 valid for a time interval that is significantly longer than the 172 interval at which congestion controllers operate. Note that, 173 for the only SBD mechanism defined in this document 174 (multiplexing on the same five-tuple), the notion of a shared 175 bottleneck stays correct even in the presence of fast traffic 176 fluctuations: since all flows that are assumed to share a 177 bottleneck are routed in the same way, if the bottleneck 178 changes, it will still be shared. 180 4. Architectural overview 182 Figure 1 shows the elements of the architecture for coupled 183 congestion control: the Flow State Exchange (FSE), Shared Bottleneck 184 Detection (SBD) and Flows. The FSE is a storage element that can be 185 implemented in two ways: active and passive. In the active version, 186 it initiates communication with flows and SBD. However, in the 187 passive version, it does not actively initiate communication with 188 flows and SBD; its only active role is internal state maintenance 189 (e.g., an implementation could use soft state to remove a flow's data 190 after long periods of inactivity). Every time a flow's congestion 191 control mechanism would normally update its sending rate, the flow 192 instead updates information in the FSE and performs a query on the 193 FSE, leading to a sending rate that can be different from what the 194 congestion controller originally determined. Using information 195 about/from the currently active flows, SBD updates the FSE with the 196 correct Flow State Identifiers (FSIs). This document describes both 197 active and passive versions, however the passive version is put into 198 the appendix as it is extremely experimental. 200 ------- <--- Flow 1 201 | FSE | <--- Flow 2 .. 202 ------- <--- .. Flow N 203 ^ 204 | | 205 ------- | 206 | SBD | <-------| 207 ------- 209 Figure 1: Coupled congestion control architecture 211 Since everything shown in Figure 1 is assumed to operate on a single 212 host (the sender) only, this document only describes aspects that 213 have an influence on the resulting on-the-wire behavior. It does, 214 for instance, not define how many bits must be used to represent 215 FSIs, or in which way the entities communicate. Implementations can 216 take various forms: for instance, all the elements in the figure 217 could be implemented within a single application, thereby operating 218 on flows generated by that application only. Another alternative 219 could be to implement both the FSE and SBD together in a separate 220 process which different applications communicate with via some form 221 of Inter-Process Communication (IPC). Such an implementation would 222 extend the scope to flows generated by multiple applications. The 223 FSE and SBD could also be included in the Operating System kernel. 225 5. Roles 227 This section gives an overview of the roles of the elements of 228 coupled congestion control, and provides an example of how coupled 229 congestion control can operate. 231 5.1. SBD 233 SBD uses knowledge about the flows to determine which flows belong in 234 the same Flow Group (FG), and assigns FGIs accordingly. This 235 knowledge can be derived in three basic ways: 237 1. From multiplexing: it can be based on the simple assumption that 238 packets sharing the same five-tuple (IP source and destination 239 address, protocol, and transport layer port number pair) and 240 having the same Differentiated Services Code Point (DSCP) in the 241 IP header are typically treated in the same way along the path. 242 The latter method is the only one specified in this document: SBD 243 MAY consider all flows that use the same five-tuple and DSCP to 244 belong to the same FG. This classification applies to certain 245 tunnels, or RTP flows that are multiplexed over one transport 246 (cf. [transport-multiplex]). Such multiplexing is also a 247 recommended usage of RTP in rtcweb [rtcweb-rtp-usage]. 249 2. Via configuration: e.g. by assuming that a common wireless uplink 250 is also a shared bottleneck. 252 3. From measurements: e.g. by considering correlations among 253 measured delay and loss as an indication of a shared bottleneck. 255 The methods above have some essential trade-offs: e.g., multiplexing 256 is a completely reliable measure, however it is limited in scope to 257 two end points (i.e., it cannot be applied to couple congestion 258 controllers of one sender talking to multiple receivers). A 259 measurement-based SBD mechanism is described in [I-D.ietf-rmcat-sbd]. 260 Measurements can never be 100% reliable, in particular because they 261 are based on the past but applying coupled congestion control means 262 to make an assumption about the future; it is therefore recommended 263 to implement cautionary measures, e.g. by disabling coupled 264 congestion control if enabling it causes a significant increase in 265 delay and/or packet loss. Measurements also take time, which entails 266 a certain delay for turning on coupling (refer to 267 [I-D.ietf-rmcat-sbd] for details). 269 5.2. FSE 271 The FSE contains a list of all flows that have registered with it. 272 For each flow, it stores the following: 274 o a unique flow number to identify the flow 276 o the FGI of the FG that it belongs to (based on the definitions in 277 this document, a flow has only one bottleneck, and can therefore 278 be in only one FG) 280 o a priority P, which here is assumed to be represented as a 281 floating point number in the range from 0.1 (unimportant) to 1 282 (very important). 284 o The rate used by the flow in bits per second, FSE_R. 286 Note that the priority does not need to be a floating point value and 287 its value range does not matter for this algorithm: the algorithm 288 works with a flow's priority portion of the sum of all priority 289 values. Priority values can therefore also be mapped to the "very- 290 low", "low", "medium" or "high" priority levels described in 291 [I-D.ietf-rtcweb-transports]. 293 The FSE can operate on window-based as well as rate-based congestion 294 controllers (TEMPORARY NOTE: and probably -- not yet tested -- 295 combinations thereof, with calculations to convert from one to the 296 other). In case of a window-based controller, FSE_R is a window, and 297 all the text below should be considered to refer to window, not 298 rates. 300 In the FSE, each FG contains one static variable S_CR which is the 301 sum of the calculated rates of all flows in the same FG. This value 302 is used to calculate the sending rate. 304 The information listed here is enough to implement the sample flow 305 algorithm given below. FSE implementations could easily be extended 306 to store, e.g., a flow's current sending rate for statistics 307 gathering or future potential optimizations. 309 5.3. Flows 311 Flows register themselves with SBD and FSE when they start, 312 deregister from the FSE when they stop, and carry out an UPDATE 313 function call every time their congestion controller calculates a new 314 sending rate. Via UPDATE, they provide the newly calculated rate and 315 optionally (if the algorithm supports it) the desired rate. The 316 desired rate is less than the calculated rate in case of application- 317 limited flows; otherwise, it is the same as the calculated rate. 319 Below, two example algorithms are described. While other algorithms 320 could be used instead, the same algorithm must be applied to all 321 flows. 323 5.3.1. Example algorithm 1 - Active FSE 325 This algorithm was designed to be the simplest possible method to 326 assign rates according to the priorities of flows. Simulations 327 results in [fse] indicate that it does however not significantly 328 reduce queuing delay and packet loss. 330 (1) When a flow f starts, it registers itself with SBD and the FSE. 331 FSE_R is initialized with the congestion controller's initial 332 rate. SBD will assign the correct FGI. When a flow is assigned 333 an FGI, it adds its FSE_R to S_CR. 335 (2) When a flow f stops, its entry is removed from the list. 337 (3) Every time the congestion controller of the flow f determines a 338 new sending rate CC_R, the flow calls UPDATE, which carries out 339 the tasks listed below to derive the new sending rates for all 340 the flows in the FG. A flow's UPDATE function uses a local 341 (i.e. per-flow) temporary variable S_P, which is the sum of all 342 the priorities. 344 (a) It updates S_CR. 346 S_CR = S_CR + CC_R - FSE_R(f) 348 (b) It calculates the sum of all the priorities, S_P. 350 S_P = 0 351 for all flows i in FG do 352 S_P = S_P + P(i) 353 end for 355 (c) It calculates the sending rates for all the flows in an FG 356 and distributes them. 358 for all flows i in FG do 359 FSE_R(i) = (P(i)*S_CR)/S_P 360 send FSE_R(i) to the flow i 361 end for 363 5.3.2. Example algorithm 2 - Conservative Active FSE 365 This algorithm extends algorithm 1 to conservatively emulate the 366 behavior of a single flow by proportionally reducing the aggregate 367 rate on congestion. Simulations results in [fse] indicate that it 368 can significantly reduce queuing delay and packet loss. 370 (1) When a flow f starts, it registers itself with SBD and the FSE. 371 FSE_R is initialized with the congestion controller's initial 372 rate. SBD will assign the correct FGI. When a flow is assigned 373 an FGI, it adds its FSE_R to S_CR. 375 (2) When a flow f stops, its entry is removed from the list. 377 (3) Every time the congestion controller of the flow f determines a 378 new sending rate CC_R, the flow calls UPDATE, which carries out 379 the tasks listed below to derive the new sending rates for all 380 the flows in the FG. A flow's UPDATE function uses a local 381 (i.e. per-flow) temporary variable S_P, which is the sum of all 382 the priorities, and a local variable DELTA, which is used to 383 calculate the difference between CC_R and the previously stored 384 FSE_R. To prevent flows from either ignoring congestion or 385 overreacting, a timer keeps them from changing their rates 386 immediately after the common rate reduction that follows a 387 congestion event. This timer is set to 2 RTTs of the flow that 388 experienced congestion because it is assumed that a congestion 389 event can persist for up to one RTT of that flow, with another 390 RTT added to compensate for fluctuations in the measured RTT 391 value. 393 (a) It updates S_CR based on DELTA. 395 if Timer has expired or not set then 396 DELTA = CC_R - FSE_R(f) 397 if DELTA < 0 then // Reduce S_CR proportionally 398 S_CR = S_CR * CC_R / FSE_R(f) 399 Set Timer for 2 RTTs 400 else 401 S_CR = S_CR + DELTA 402 end if 403 end if 405 (b) It calculates the sum of all the priorities, S_P. 407 S_P = 0 408 for all flows i in FG do 409 S_P = S_P + P(i) 410 end for 412 (c) It calculates the sending rates for all the flows in an FG 413 and distributes them. 415 for all flows i in FG do 416 FSE_R(i) = (P(i)*S_CR)/S_P 417 send FSE_R(i) to the flow i 418 end for 420 6. Application 422 This section specifies how the FSE can be applied to specific 423 congestion control mechanisms and makes general recommendations that 424 facilitate applying the FSE to future congestion controls. 426 6.1. NADA 428 Network-Assisted Dynamic Adapation (NADA) [I-D.ietf-rmcat-nada] is a 429 congestion control scheme for rtcweb. It calculates a reference rate 430 r_ref upon receiving an acknowledgment, and then, based on the 431 reference rate, it calculates a video target rate r_vin and a sending 432 rate for the flows, r_send. 434 When applying the FSE to NADA, the UPDATE function call described in 435 Section 5.3 gives the FSE NADA's reference rate r_ref. The 436 recommended algorithm for NADA is the Active FSE in Section 5.3.1. 437 In step 3 (c), when the FSE_R(i) is "sent" to the flow i, this means 438 updating r_ref(r_vin and r_send) of flow i with the value of 439 FSE_R(i). 441 6.2. GCC 443 Google Congestion Control (GCC) [I-D.ietf-rmcat-gcc] is another 444 congestion control scheme for rtcweb. The rate control of GCC 445 employs two parts: controlling the bandwidth estimate based on delay, 446 and controlling the bandwidth estimate based on loss. Both are 447 designed to estimate the available bandwidth, A_hat. 449 When applying the FSE to GCC, the UPDATE function call described in 450 Section 5.3 gives the FSE GCC's estimate of available bandwidth 451 A_hat. The recommended algorithm for GCC is the Active FSE in 452 Section 5.3.1. In step 3 (c), when the FSE_R(i) is "sent" to the 453 flow i, this means updating A_hat of flow i with the value of 454 FSE_R(i). 456 6.3. General recommendations 458 This section will provides general advice for applying the FSE to 459 congestion control mechanisms. TEMPORARY NOTE: Future versions of 460 this document will contain a longer list. 462 Receiver-side calculations: 463 When receiver-side calculations make assumptions about the rate 464 of the sender, the calculations need to be synchronized or the 465 receiver needs to be updated accordingly. This applies to TFRC 466 [RFC5348], for example, where simulations showed somewhat less 467 favorable results when using the FSE without a receiver-side 468 change [fse]. 470 7. Acknowledgements 472 This document has benefitted from discussions with and feedback from 473 David Hayes, Mirja Kuehlewind, Karen Nielsen, Andreas Petlund, David 474 Ros (who also gave the FSE its name), Zaheduzzaman Sarker, Varun 475 Singh and Kristian Hiorth. The authors would like to thank Xiaoqing 476 Zhu and Stefan Holmer for helping with NADA and GCC. 478 This work was partially funded by the European Community under its 479 Seventh Framework Programme through the Reducing Internet Transport 480 Latency (RITE) project (ICT-317700). 482 8. IANA Considerations 484 This memo includes no request to IANA. 486 9. Security Considerations 488 In scenarios where the architecture described in this document is 489 applied across applications, various cheating possibilities arise: 490 e.g., supporting wrong values for the calculated rate, the desired 491 rate, or the priority of a flow. In the worst case, such cheating 492 could either prevent other flows from sending or make them send at a 493 rate that is unreasonably large. The end result would be unfair 494 behavior at the network bottleneck, akin to what could be achieved 495 with any UDP based application. Hence, since this is no worse than 496 UDP in general, there seems to be no significant harm in using this 497 in the absence of UDP rate limiters. 499 In the case of a single-user system, it should also be in the 500 interest of any application programmer to give the user the best 501 possible experience by using reasonable flow priorities or even 502 letting the user choose them. In a multi-user system, this interest 503 may not be given, and one could imagine the worst case of an "arms 504 race" situation, where applications end up setting their priorities 505 to the maximum value. If all applications do this, the end result is 506 a fair allocation in which the priority mechanism is implicitly 507 eliminated, and no major harm is done. 509 10. References 511 10.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 515 RFC2119, March 1997, 516 . 518 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 519 RFC 3124, DOI 10.17487/RFC3124, June 2001, 520 . 522 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 523 Friendly Rate Control (TFRC): Protocol Specification", 524 RFC 5348, DOI 10.17487/RFC5348, September 2008, 525 . 527 10.2. Informative References 529 [I-D.ietf-rmcat-gcc] 530 Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. 531 Mascolo, "A Google Congestion Control Algorithm for Real- 532 Time Communication", draft-ietf-rmcat-gcc-01 (work in 533 progress), October 2015. 535 [I-D.ietf-rmcat-nada] 536 Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, 537 J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified 538 Congestion Control Scheme for Real-Time Media", 539 draft-ietf-rmcat-nada-02 (work in progress), March 2016. 541 [I-D.ietf-rmcat-sbd] 542 Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared 543 Bottleneck Detection for Coupled Congestion Control for 544 RTP Media.", draft-ietf-rmcat-sbd-04 (work in progress), 545 March 2016. 547 [I-D.ietf-rtcweb-transports] 548 Alvestrand, H., "Transports for WebRTC", 549 draft-ietf-rtcweb-transports-11.txt (work in progress), 550 January 2016. 552 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 553 Time Communication Use Cases and Requirements", RFC 7478, 554 DOI 10.17487/RFC7478, March 2015, 555 . 557 [fse] Islam, S., Welzl, M., Gjessing, S., and N. Khademi, 558 "Coupled Congestion Control for RTP Media", ACM SIGCOMM 559 Capacity Sharing Workshop (CSWS 2014) and ACM SIGCOMM CCR 560 44(4) 2014; extended version available as a technical 561 report from 562 http://safiquli.at.ifi.uio.no/paper/fse-tech-report.pdf , 563 2014. 565 [rtcweb-rtp-usage] 566 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 567 Communication (WebRTC): Media Transport and Use of RTP", 568 draft-ietf-rtcweb-rtp-usage-26.txt (work in progress), 569 March 2016. 571 [transport-multiplex] 572 Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a 573 Single Lower-Layer Transport", 574 draft-westerlund-avtcore-transport-multiplexing-07.txt 575 (work in progress), October 2013. 577 Appendix A. Scheduling 579 When connections originate from the same host, it would be possible 580 to use only one single sender-side congestion controller which 581 determines the overall allowed sending rate, and then use a local 582 scheduler to assign a proportion of this rate to each RTP session. 583 This way, priorities could also be implemented as a function of the 584 scheduler. The Congestion Manager (CM) [RFC3124] also uses such a 585 scheduling function. 587 Appendix B. Example algorithm - Passive FSE 589 Active algorithms calculate the rates for all the flows in the FG and 590 actively distribute them. In a passive algorithm, UPDATE returns a 591 rate that should be used instead of the rate that the congestion 592 controller has determined. This can make a passive algorithm easier 593 to implement; however, when round-trip times of flows are unequal, 594 shorter-RTT flows will update and react to the overall FSE state more 595 often than longer-RTT flows, which can produce unwanted side effects. 596 This problem is more significant when the congestion control 597 convergence depends on the RTT. While the passive algorithm works 598 better for congestion controls with RTT-independent convergence, it 599 can still produce oscillations on short time scales. The algorithm 600 described below is therefore considered as highly experimental. 602 This passive version of the FSE stores the following information in 603 addition to the variables described in Section 5.2: 605 o The desired rate DR. This can be smaller than the calculated rate 606 if the application feeding into the flow has less data to send 607 than the congestion controller would allow. In case of a bulk 608 transfer, DR must be set to CC_R received from the flow's 609 congestion module. 611 The passive version of the FSE contains one static variable per FG 612 called TLO (Total Leftover Rate -- used to let a flow 'take' 613 bandwidth from application-limited or terminated flows) which is 614 initialized to 0. For the passive version, S_CR is limited to 615 increase or decrease as conservatively as a flow's congestion 616 controller decides in order to prohibit sudden rate jumps. 618 (1) When a flow f starts, it registers itself with SBD and the FSE. 619 FSE_R and DR are initialized with the congestion controller's 620 initial rate. SBD will assign the correct FGI. When a flow is 621 assigned an FGI, it adds its FSE_R to S_CR. 623 (2) When a flow f stops, it sets its DR to 0 and sets P to -1. 625 (3) Every time the congestion controller of the flow f determines a 626 new sending rate CC_R, assuming the flow's new desired rate 627 new_DR to be "infinity" in case of a bulk data transfer with an 628 unknown maximum rate, the flow calls UPDATE, which carries out 629 the tasks listed below to derive the flow's new sending rate, 630 Rate. A flow's UPDATE function uses a few local (i.e. per-flow) 631 temporary variables, which are all initialized to 0: DELTA, 632 new_S_CR and S_P. 634 (a) For all the flows in its FG (including itself), it 635 calculates the sum of all the calculated rates, new_S_CR. 636 Then it calculates the difference between FSE_R(f) and 637 CC_R, DELTA. 639 for all flows i in FG do 640 new_S_CR = new_S_CR + FSE_R(i) 642 end for 643 DELTA = CC_R - FSE_R(f) 645 (b) It updates S_CR, FSE_R(f) and DR(f). 647 FSE_R(f) = CC_R 648 if DELTA > 0 then // the flow's rate has increased 649 S_CR = S_CR + DELTA 650 else if DELTA < 0 then 651 S_CR = new_S_CR + DELTA 652 end if 653 DR(f) = min(new_DR,FSE_R(f)) 655 (c) It calculates the leftover rate TLO, removes the terminated 656 flows from the FSE and calculates the sum of all the 657 priorities, S_P. 659 for all flows i in FG do 660 if P(i)<0 then 661 delete flow 662 else 663 S_P = S_P + P(i) 664 end if 665 end for 666 if DR(f) < FSE_R(f) then 667 TLO = TLO + (P(f)/S_P) * S_CR - DR(f)) 668 end if 670 (d) It calculates the sending rate, Rate. 672 Rate = min(new_DR, (P(f)*S_CR)/S_P + TLO) 674 if Rate != new_DR and TLO > 0 then 675 TLO = 0 // f has 'taken' TLO 676 end if 678 (e) It updates DR(f) and FSE_R(f) with Rate. 680 if Rate > DR(f) then 681 DR(f) = Rate 682 end if 683 FSE_R(f) = Rate 685 The goals of the flow algorithm are to achieve prioritization, 686 improve network utilization in the face of application-limited flows, 687 and impose limits on the increase behavior such that the negative 688 impact of multiple flows trying to increase their rate together is 689 minimized. It does that by assigning a flow a sending rate that may 690 not be what the flow's congestion controller expected. It therefore 691 builds on the assumption that no significant inefficiencies arise 692 from temporary application-limited behavior or from quickly jumping 693 to a rate that is higher than the congestion controller intended. 694 How problematic these issues really are depends on the controllers in 695 use and requires careful per-controller experimentation. The coupled 696 congestion control mechanism described here also does not require all 697 controllers to be equal; effects of heterogeneous controllers, or 698 homogeneous controllers being in different states, are also subject 699 to experimentation. 701 This algorithm gives all the leftover rate of application-limited 702 flows to the first flow that updates its sending rate, provided that 703 this flow needs it all (otherwise, its own leftover rate can be taken 704 by the next flow that updates its rate). Other policies could be 705 applied, e.g. to divide the leftover rate of a flow equally among all 706 other flows in the FGI. 708 B.1. Example operation (passive) 710 In order to illustrate the operation of the passive coupled 711 congestion control algorithm, this section presents a toy example of 712 two flows that use it. Let us assume that both flows traverse a 713 common 10 Mbit/s bottleneck and use a simplistic congestion 714 controller that starts out with 1 Mbit/s, increases its rate by 1 715 Mbit/s in the absence of congestion and decreases it by 2 Mbit/s in 716 the presence of congestion. For simplicity, flows are assumed to 717 always operate in a round-robin fashion. Rate numbers below without 718 units are assumed to be in Mbit/s. For illustration purposes, the 719 actual sending rate is also shown for every flow in FSE diagrams even 720 though it is not really stored in the FSE. 722 Flow #1 begins. It is a bulk data transfer and considers itself to 723 have top priority. This is the FSE after the flow algorithm's step 724 1: 726 ---------------------------------------- 727 | # | FGI | P | FSE_R | DR | Rate | 728 | | | | | | | 729 | 1 | 1 | 1 | 1 | 1 | 1 | 730 ---------------------------------------- 731 S_CR = 1, TLO = 0 732 Its congestion controller gradually increases its rate. Eventually, 733 at some point, the FSE should look like this: 735 -------------------------------------- 736 | # | FGI | P | FSE_R | DR | Rate | 737 | | | | | | | 738 | 1 | 1 | 1 | 10 | 10 | 10 | 739 ----------------------------------------- 740 S_CR = 10, TLO = 0 742 Now another flow joins. It is also a bulk data transfer, and has a 743 lower priority (0.5): 745 ---------------------------------------- 746 | # | FGI | P | FSE_R | DR | Rate | 747 | | | | | | | 748 | 1 | 1 | 1 | 10 | 10 | 10 | 749 | 2 | 1 | 0.5 | 1 | 1 | 1 | 750 ------------------------------------------ 751 S_CR = 11, TLO = 0 753 Now assume that the first flow updates its rate to 8, because the 754 total sending rate of 11 exceeds the total capacity. Let us take a 755 closer look at what happens in step 3 of the flow algorithm. 757 CC_R = 8. new_DR = infinity. 758 3 a) new_S_CR = 11; DELTA = 8 - 10 = -2. 759 3 b) FSE_Rf) = 8. DELTA is negative, hence S_CR = 9; 760 DR(f) = 8. 761 3 c) S_P = 1.5. 762 3 d) new sending rate = min(infinity, 1/1.5 * 9 + 0) = 6. 763 3 e) FSE_R(f) = 6. 765 The resulting FSE looks as follows: 766 ---------------------------------------- 767 | # | FGI | P | FSE_R | DR | Rate | 768 | | | | | | | 769 | 1 | 1 | 1 | 6 | 8 | 6 | 770 | 2 | 1 | 0.5 | 1 | 1 | 1 | 771 ------------------------------------------- 772 S_CR = 9, TLO = 0 773 The effect is that flow #1 is sending with 6 Mbit/s instead of the 8 774 Mbit/s that the congestion controller derived. Let us now assume 775 that flow #2 updates its rate. Its congestion controller detects 776 that the network is not fully saturated (the actual total sending 777 rate is 6+1=7) and increases its rate. 779 CC_R=2. new_DR = infinity. 780 3 a) new_S_CR = 7; DELTA = 2 - 1 = 1. 781 3 b) FSE_R(f) = 2. DELTA is positive, hence S_CR = 9 + 1 = 10; 782 DR(f) = 2. 783 3 c) S_P = 1.5. 784 3 d) new sending rate = min(infinity, 0.5/1.5 * 10 + 0) = 3.33. 785 3 e) DR(f) = FSE_R(f) = 3.33. 787 The resulting FSE looks as follows: 788 ------------------------------------------- 789 | # | FGI | P | FSE_R | DR | Rate | 790 | | | | | | | 791 | 1 | 1 | 1 | 6 | 8 | 6 | 792 | 2 | 1 | 0.5 | 3.33 | 3.33 | 3.33 | 793 ------------------------------------------- 794 S_CR = 10, TLO = 0 796 The effect is that flow #2 is now sending with 3.33 Mbit/s, which is 797 close to half of the rate of flow #1 and leads to a total utilization 798 of 6(#1) + 3.33(#2) = 9.33 Mbit/s. Flow #2's congestion controller 799 has increased its rate faster than the controller actually expected. 800 Now, flow #1 updates its rate. Its congestion controller detects 801 that the network is not fully saturated and increases its rate. 802 Additionally, the application feeding into flow #1 limits the flow's 803 sending rate to at most 2 Mbit/s. 805 CC_R=7. new_DR=2. 806 3 a) new_S_CR = 9.33; DELTA = 1. 807 3 b) FSE_R(f) = 7, DELTA is positive, hence S_CR = 10 + 1 = 11; 808 DR = min(2, 7) = 2. 809 3 c) S_P = 1.5; DR(f) < FSE_R(f), hence TLO = 1/1.5 * 11 - 2 = 5.33. 810 3 d) new sending rate = min(2, 1/1.5 * 11 + 5.33) = 2. 811 3 e) FSE_R(f) = 2. 813 The resulting FSE looks as follows: 814 ------------------------------------------- 815 | # | FGI | P | FSE_R | DR | Rate | 816 | | | | | | | 817 | 1 | 1 | 1 | 2 | 2 | 2 | 818 | 2 | 1 | 0.5 | 3.33 | 3.33 | 3.33 | 819 ------------------------------------------- 820 S_CR = 11, TLO = 5.33 822 Now, the total rate of the two flows is 2 + 3.33 = 5.33 Mbit/s, i.e. 823 the network is significantly underutilized due to the limitation of 824 flow #1. Flow #2 updates its rate. Its congestion controller 825 detects that the network is not fully saturated and increases its 826 rate. 828 CC_R=4.33. new_DR = infinity. 829 3 a) new_S_CR = 5.33; DELTA = 1. 830 3 b) FSE_R(f) = 4.33. DELTA is positive, hence S_CR = 12; 831 DR(f) = 4.33. 832 3 c) S_P = 1.5. 833 3 d) new sending rate: min(infinity, 0.5/1.5 * 12 + 5.33 ) = 9.33. 834 3 e) FSE_R(f) = 9.33, DR(f) = 9.33. 836 The resulting FSE looks as follows: 837 ------------------------------------------- 838 | # | FGI | P | FSE_R | DR | Rate | 839 | | | | | | | 840 | 1 | 1 | 1 | 2 | 2 | 2 | 841 | 2 | 1 | 0.5 | 9.33 | 9.33 | 9.33 | 842 ------------------------------------------- 843 S_CR = 12, TLO = 0 845 Now, the total rate of the two flows is 2 + 9.33 = 11.33 Mbit/s. 846 Finally, flow #1 terminates. It sets P to -1 and DR to 0. Let us 847 assume that it terminated late enough for flow #2 to still experience 848 the network in a congested state, i.e. flow #2 decreases its rate in 849 the next iteration. 851 CC_R = 7.33. new_DR = infinity. 852 3 a) new_S_CR = 11.33; DELTA = -2. 853 3 b) FSE_R(f) = 7.33. DELTA is negative, hence S_CR = 9.33; 854 DR(f) = 7.33. 855 3 c) Flow 1 has P = -1, hence it is deleted from the FSE. 856 S_P = 0.5. 857 3 d) new sending rate: min(infinity, 0.5/0.5*9.33 + 0) = 9.33. 858 3 e) FSE_R(f) = DR(f) = 9.33. 860 The resulting FSE looks as follows: 861 ------------------------------------------- 862 | # | FGI | P | FSE_R | DR | Rate | 863 | | | | | | | 864 | 2 | 1 | 0.5 | 9.33 | 9.33 | 9.33 | 865 ------------------------------------------- 866 S_CR = 9.33, TLO = 0 868 Appendix C. Change log 870 C.1. draft-welzl-rmcat-coupled-cc 872 C.1.1. Changes from -00 to -01 874 o Added change log. 876 o Updated the example algorithm and its operation. 878 C.1.2. Changes from -01 to -02 880 o Included an active version of the algorithm which is simpler. 882 o Replaced "greedy flow" with "bulk data transfer" and "non-greedy" 883 with "application-limited". 885 o Updated new_CR to CC_R, and CR to FSE_R for better understanding. 887 C.1.3. Changes from -02 to -03 889 o Included an active conservative version of the algorithm which 890 reduces queue growth and packet loss; added a reference to a 891 technical report that shows these benefits with simulations. 893 o Moved the passive variant of the algorithm to appendix. 895 C.1.4. Changes from -03 to -04 897 o Extended SBD section. 899 o Added a note about window-based controllers. 901 C.1.5. Changes from -04 to -05 903 o Added a section about applying the FSE to specific congestion 904 control algorithms, with a subsection specifying its use with 905 NADA. 907 C.2. draft-ietf-rmcat-coupled-cc 909 C.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 911 o Moved scheduling section to the appendix. 913 C.2.2. Changes from -00 to -01 915 o Included how to apply the algorithm to GCC. 917 o Updated variable names of NADA to be in line with the latest 918 version. 920 o Added a reference to [I-D.ietf-rtcweb-transports] to make a 921 connection to the prioritization text there. 923 Authors' Addresses 925 Safiqul Islam 926 University of Oslo 927 PO Box 1080 Blindern 928 Oslo, N-0316 929 Norway 931 Phone: +47 22 84 08 37 932 Email: safiquli@ifi.uio.no 933 Michael Welzl 934 University of Oslo 935 PO Box 1080 Blindern 936 Oslo, N-0316 937 Norway 939 Phone: +47 22 85 24 20 940 Email: michawe@ifi.uio.no 942 Stein Gjessing 943 University of Oslo 944 PO Box 1080 Blindern 945 Oslo, N-0316 946 Norway 948 Phone: +47 22 85 24 44 949 Email: steing@ifi.uio.no