idnits 2.17.1 draft-bonaventure-iccrg-schedulers-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 912 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Path' is mentioned on line 351, but not defined == Outdated reference: A later version (-27) exists of draft-tuexen-tsvwg-sctp-multipath-22 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICCRG Working Group O. Bonaventure 3 Internet-Draft M. Piraux 4 Intended status: Experimental Q. De Coninck 5 Expires: 28 April 2022 UCLouvain 6 M. Baerts 7 Tessares 8 C. Paasch 9 Apple 10 M. Amend 11 Deutsche Telekom 12 25 October 2021 14 Multipath schedulers 15 draft-bonaventure-iccrg-schedulers-02 17 Abstract 19 This document proposes a series of abstract packet schedulers for 20 multipath transport protocols equipped with a congestion controller. 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 https://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 28 April 2022. 39 Copyright Notice 41 Copyright (c) 2021 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 (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. An abstract multipath transport protocol . . . . . . . . . . 4 57 3. Packet scheduling challenges . . . . . . . . . . . . . . . . 5 58 4. Packet schedulers . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Round-Robin . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.2. Weighted Round-Robin . . . . . . . . . . . . . . . . . . 8 61 4.3. Strict Priority . . . . . . . . . . . . . . . . . . . . . 8 62 4.4. Round-Trip-Time Threshold . . . . . . . . . . . . . . . . 9 63 4.5. Lowest Round-Trip-Time First . . . . . . . . . . . . . . 10 64 4.6. Combination of schedulers type: Priority and Lowest 65 round-trip-time first . . . . . . . . . . . . . . . . . . 11 66 5. Informative References . . . . . . . . . . . . . . . . . . . 12 67 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 14 68 A.1. Since draft-bonaventure-iccrg-schedulers-00 . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 The Internet was designed under the implicit assumption that hosts 74 are equipped with a single network interface while routers are 75 equipped with several ones. Under this assumption, an Internet host 76 is usually identified by the IP address of its network interface. 78 This assumption does not hold anymore today for two reasons. First, 79 a growing fraction of the Internet hosts are equipped with several 80 network interfaces, usually through different datalink networks. 81 These multihomed hosts are reachable via different IP addresses. 82 Second, a growing fraction of the hosts that are attached through a 83 single network interface are dual-stack and are thus reachable over 84 both IPv4 and IPv6. 86 Several Internet transport protocols have been extended to leverage 87 the different paths that are exposed on such hosts: Multipath TCP 88 [RFC6824], the load sharing extensions to SCTP 89 [I-D.tuexen-tsvwg-sctp-multipath], Multipath DCCP 90 [I-D.amend-tsvwg-multipath-dccp] and Multipath QUIC 91 [I-D.deconinck-quic-multipath]. These multipath transport protocols 92 differ in the way they are organized and exchange control information 93 and user data. However, they all include algorithms to handle three 94 problems that any multipath transport protocol needs to solve: 96 * Congestion controller 97 * Path manager 99 * Packet scheduler 101 * Packet re-assembly 103 From a congestion control viewpoint, the main concern for a multipath 104 transport protocol is that a multipath connection should not be 105 unfair to single-path transport connections that share a common 106 bottleneck. This problem can be solved by coupling the congestion 107 windows of the different paths. The solution proposed in [RFC6356] 108 is applicable to any transport protocol. Beside providing fairness, 109 congestion control can also be a valuable input for different kind of 110 traffic distribution algorithm within a packet scheduler. Typically 111 metrics like RTT and available capacity can be derived. 113 A multipath transport protocol uses different flows during the 114 lifetime of a connection. The Path Manager contains the logic that 115 regulates the creation/deletion of these flows. This logic usually 116 depends on the requirements of the application that uses the 117 multipath transport. Some applications use multipath in failover 118 situations. In this case, the connection can use one path and the 119 path manager can create another path when the primary one fails. An 120 application that wishes to share its load among different paths can 121 request the path manager to establish different paths in order to 122 simultaneously use them during the connection. Many path managers 123 have been proposed in the literature [CONEXT15], but these are 124 outside the scope of this document. 126 The packet scheduler is the generic term for the algorithm that 127 selects the path that will be used to transmit each packet on a 128 multipath connection. This logic is obviously only useful when there 129 are at least two active paths for a given multipath transport 130 connection. A variety of packet schedulers have been proposed in the 131 literature [ACMCS14] and implemented in multipath transport 132 protocols. Experience with multipath transport protocols shows that 133 the packet scheduler can have a huge impact on the performance 134 achieved by such protocols. 136 Packet re-assembly or re-ordering in multipath transport has the 137 functionality to equalize the effect of packet scheduling across 138 paths with different characteristics and restore the original packet 139 order to a certain extent. Obviously, packet re-assembly is the 140 counterpart of packet scheduling and located at the far end of the 141 multipath transport. However, packet scheduling schemes exists which 142 render the re-assembly superfluous or lowering at least its effort. 144 In this document, we document a series of multipath packet schedulers 145 that are known to provide performance that matches well the 146 requirements of specific applications. To describe these packet 147 schedulers, we assume an abstract transport that is briefly presented 148 in Section 2. In Section 3 we describe the challenges and 149 constraints around a multipath scheduler. Finally, we describe the 150 different schedulers in Section 4. To keep the description as simple 151 and intuitive as possible, we assume here multipath connections that 152 are composed of two paths, a frequent deployment scenario for 153 multipath transport. This does not restrict the proposed schedulers 154 to using only two paths. Implementations are encouraged to support 155 more than 2 paths. We leave the discussion on how to adapt these 156 abstract schedulers to concrete multipath transport protocols in 157 future drafts. 159 2. An abstract multipath transport protocol 161 For simplicity, we assume a multipath transport protocol which can 162 send packets over different paths. Some protocols such as Multipath 163 TCP [RFC6824] support active and backup paths. We do not assume this 164 in this document and leave the impact of these active/backup paths in 165 specific documents. 167 Furthermore, we assume that there are exactly two active paths for 168 the presentation of the packet schedulers. We consider that a path 169 is active as long as it supports the transmission of packets. 170 Meaning, A Multipath TCP subflow TCP segment with the FIN or RST 171 flags set is not considered as an active path. Other constraints are 172 possible on whether or not a path is active. These are specific to 173 the scheduler and vary depending on the goal of the scheduler. An 174 example of these is that when a path has experienced a certain number 175 N of retransmission timeouts, the path can be considered inactive. 177 We assume that the transport protocol maintains one congestion 178 controller per path as in [RFC6356]. We do not assume a specific 179 congestion controller, but assume that it can be queried by the 180 packet scheduler to verify whether a packet of length l would be 181 blocked or not by the congestion control scheme. A window-based 182 congestion controller such as [RFC6356] can block a packet from being 183 transmitted for some time when its congestion window is full. The 184 same applies to a rate-based congestion controller although the 185 latter could indicate when the packet could be accepted while the 186 former cannot. 188 We assume that the multipath transport protocol maintains some state 189 at the connection level and at the path level. On both level, the 190 multipath transport protocol will maintain send and receive windows, 191 and a Maximum Segment Size that is negotiated at connection 192 establishment. 194 It may also contain some information that is specific to the 195 application (e.g. total amount of data sent or received) and 196 information about non-active flows. At the path level, we expect 197 that the multipath transport protocol will maintain an accurate 198 estimation of the round-trip-time over that path, possibly a send/ 199 receive window, per path MTU information, the state of the congestion 200 controller, and optionally information that is specific to the 201 application or the packet scheduler (e.g. priority for one path over 202 another one). 204 3. Packet scheduling challenges 206 Packet scheduling tries to balance different quality of service goals 207 with different constraints of the paths. The balance depends on 208 which of the goals or constraints is the primary factor for the 209 experience the application is aiming for. In the following we list 210 these goals and constraints and conclude by how they can influence 211 each other. 213 Each path can be subject to a different cost when transmitting data. 214 For example, a path can introduce a per-byte monetary cost for the 215 transmission (e.g., metered cellular link). Another cost can be the 216 power consumption when transmitting or receiving data. These costs 217 are imposing restrictions on when a path can be used compared to the 218 lower-cost path. 220 A goal for many applications is to reduce the latency of their 221 transaction. With multiple paths, each path can have a significantly 222 different latency compared to the other paths. It is thus crucial to 223 schedule the traffic on a path such that the latency requirements of 224 the application are satisfied. 226 Achieving high throughput is another goal of many applications. 227 Streaming applications often require a minimum bit rate to sustain 228 playback. The scheduler should try to achieve this bit rate to allow 229 for a flawless streaming experience. Beyond that, adaptive streaming 230 requires also a more stable throughput experience to ensure that the 231 bit rate of the video stream is consistent. When sending traffic 232 over multiple paths the bit rate can experience more variance and 233 thus the scheduler for such a streaming application needs to take 234 precautions to ensure a smooth experience. 236 Finally, transport protocols impose a receive-window that signals to 237 the sender how much data the application is willing to receive. When 238 the paths have a large latency difference, a multipath transport can 239 quickly become receive-window limited. This limitation comes from 240 the fact that a packet might have been sent on a high-latency path. 241 If the transport imposes in-order delivery of the data, the receiver 242 needs to wait to receive this packet over the high-latency path 243 before providing it to the application. The sender will thus become 244 receive-window limited and may end up under-utilizing the low-latency 245 path. This can become a major challenge when trying to achieve high 246 throughput. 248 All of these quality of service goals and constraints need to be 249 balanced against each other. A scheduler might decide to trade 250 latency for higher throughput. Or reduce the throughput with the 251 goal of reducing the cost. 253 4. Packet schedulers 255 The packet scheduler is executed every time a packet needs to be 256 transmitted by the multipath transport protocol. A packet scheduler 257 can consider three different types of packets: 259 * packets that carry new user data 261 * packets that carry previously transmitted user data 263 * packets that only carry control information (e.g., 264 acknowledgements, address advertisements) 266 In Multipath TCP, the packet scheduler is only used for packets that 267 carry data. Multipath TCP will typically return acknowledgements on 268 the same path as the one over which data packets were received. For 269 Multipath QUIC, the situation is different since Multipath QUIC can 270 acknowledge over one path data that was previously received over 271 another path. In Multipath TCP, this is only partially possible. 272 The subflow level acknowledgements must be sent on the subflow where 273 the data was received while the data-level acknowledgements can be 274 sent over any subflow. 276 This document uses the Python language to represent multipath 277 schedulers. A multipath scheduler is represented as a Python 278 function. This function takes the length of the next packet to 279 schedule as argument and returns the path on which it will be send. 280 A path is represented as a Python class with the following 281 attributes: 283 * srtt: The smoothed RTT of the path [RFC6298]. 285 * cc_state: The state of the congestion controller, i.e. either 286 slow_start, congestion_avoidance or recovery. 288 * blocked(l): A function indicating whether a packet of length l 289 would be rejected by the congestion controller. 291 The schedulers presented can be executed in a simulator 292 [MultipathSim] implementing the abstract multipath protocol presented 293 in Section 2. It can be used to simulate a file transfer between a 294 client and a server over multiple paths. 296 4.1. Round-Robin 298 We use the Round-Robin scheduler as a simple example to illustrate 299 how a packet scheduler can be specified, but we do not recommend its 300 usage. Experiments with Multipath TCP [ACMCS14] indicate that it 301 does not provide good performance. 303 This packet scheduler uses one additional state at the connection 304 level: last_path. This stores the identifier of the last path that 305 was used to send a packet. The scheduler is defined by the code 306 shown in Figure 1. 308 class RoundRobin(Scheduler): 309 """ Chooses an available path in a round-robin manner. """ 310 last_path: Optional[Path] = None 312 def schedule(self, packet_len: int): 313 if self.last_path in self.paths: 314 next_idx = self.paths.index(self.last_path) + 1 315 else: 316 next_idx = 0 317 sorted_paths = self.paths[next_idx:] + self.paths[:next_idx] 318 for p in sorted_paths: 319 if not p.blocked(packet_len): 320 self.last_path = p 321 return p 323 Figure 1: A simple Round Robin scheduler 325 This scheduler does not distinguish between the different types of 326 packets. It iterates over the available paths and sends over the 327 ones whose congestion window is open. 329 4.2. Weighted Round-Robin 331 The Weighted Round-Robin scheduler is a more advanced version of the 332 Round-Robin scheduler. It allows specifying a particular 333 distribution of paths. This can be used to non-uniformly spread 334 packets over paths. 336 This packet scheduler adds two states: 338 * distribution: A list containing the distribution of paths to 339 consider. Paths to which more importance is given will be present 340 several times in the list. The ordering of the list allows to 341 choose whether interleaved or burst sending is preferred. 343 * last_idx: It stores the index in the distribution of the last path 344 used to send a packet. 346 class WeightedRoundRobin(Scheduler): 347 """ Chooses an available path in a following a fixed distribution. """ 348 distribution: List[Path] 349 last_idx: int = -1 351 def schedule(self, packet_len: int) -> Optional[Path]: 352 next_idx = (self.last_idx + 1) % len(self.distribution) 353 sorted_paths = self.distribution[next_idx:] 354 + self.distribution[:next_idx] 355 for i, p in enumerate(sorted_paths): 356 if not p.blocked(packet_len): 357 self.last_idx = 358 (self.last.idx + i) % len(self.distribution) 359 return p 361 Figure 2: A Weighted Round Robin scheduler 363 This scheduler does not distinguish between the different types of 364 packets. It iterates over the available paths following the given 365 distribution and sends over the ones whose congestion window is open. 366 A variant of this algorithm could maintain a deficit per path and 367 consider the length of packets when distributing them. 369 4.3. Strict Priority 371 The Strict Priority scheduler's aim is to select paths based on a 372 priority list. Some paths might go through networks that are more 373 expensive to use than others. Then the idea is to select the path 374 with the highest priority if it is available before looking at others 375 by priority. This scheduler is described by the code shown in 376 Figure 3. 378 class StrictPriority(Scheduler): 379 """ Chooses the first available path in a priority list of paths. """ 381 def schedule(self, packet_len: int): 382 for p in sorted(self.paths, 383 key=lambda p: p.priority, reverse=True): 384 if not p.blocked(packet_len): 385 return p 387 Figure 3: A simple Strict Priority scheduler 389 This scheduler can face performance issues if, compared to others, 390 paths with high priority accept a lot of data but delivered packets 391 with a high latency. When the path is experiencing bufferbloat, the 392 receiver has to store packets for a long time in its buffers to 393 ensure an in-order delivery. It is then recommended to cover these 394 cases in the scheduler implementation with the help of the congestion 395 control algorithm. 397 4.4. Round-Trip-Time Threshold 399 The Round-Trip-Time Threshold scheduler selects the first available 400 path with a smoothed round-trip-time below a certain threshold. The 401 goal is to keep the RTT of the multipath connection to a small value 402 and avoid having the whole connection impacted by "bad" paths. A 403 prototype is shown in Figure 4. 405 @dataclass 406 class RTTThreshold(Scheduler): 407 """ Chooses the first available path below a certain RTT threshold. """ 408 threshold: float 410 def schedule(self, packet_len: int): 411 for p in self.paths: 412 if p.srtt < self.threshold and not p.blocked(packet_len): 413 return p 415 Figure 4: A simple Round-Trip-Time Threshold scheduler 417 This kind of protection can of course be added to other existing 418 schedulers. 420 4.5. Lowest Round-Trip-Time First 422 The Lowest round-trip-time first scheduler's goal is to minimize 423 latency for short flows while at the same time achieving high 424 throughput for long flows [ACMCS14]. To handle the latency 425 differences across the paths when being limited by the receive- 426 window, this scheduler deploys a fast reinjection mechanism to 427 quickly recover from the head-of-line blocking. 429 At each round, the scheduler iterates over the list of paths that are 430 eligible for transmission. To decide whether or not a path is 431 eligible, a few conditions need to be satisfied: 433 * The congestion window needs to provide enough space for the 434 segment 436 * The path is not in fast-recovery or experiencing retransmission 437 timeouts 439 Among all the eligible paths, the scheduler will choose the path with 440 the lowest RTT and transmit the segment with the new data on that 441 path. Figure 5 illustrates a simple lowest RTT scheduler which does 442 not include fast reinjections. 444 class LowestRTTFirst(Scheduler): 445 """ Chooses the first available path with the lowest RTT. """ 447 def schedule(self, packet_len: int): 448 # Sort paths by ascending SRTT 449 for p in sorted(self.paths, key=lambda path: path.srtt): 450 if not p.blocked(packet_len) \ 451 and p.cc_state != 'recovery': 452 return p 454 Figure 5: A simple Lowest RTT First scheduler 456 To handle head-of-line blocking situations when the paths have a 457 large delay difference the scheduler uses a strategy of opportunistic 458 retransmission and path penalization as described in [NSDI12]. 460 Opportunistic retransmission kicks in whenever a path is eligible for 461 transmission but the receive-window advertised by the receiver 462 prevents the sender from transmitting new data. In that case the 463 sender can transmit previously transmitted data over the eligible 464 path. To overcome the head-of-line blocking the sender will thus 465 transmit the packet at the head of the transmission queue over this 466 faster path (if it hasn't been transmitted on this particular path 467 yet). This packet has thus a chance to quickly reach the receiver 468 and fill the hole created by the head-of-line blocking. 470 Whenever the previously mentioned mechanism kicks in, it is and 471 indication that the path's round-trip-time is too high to allow the 472 path with the lower RTT to fully use its capacity. We thus should 473 reduce the transmission rate on this path. This mechanism is called 474 penalization and is achieved by dividing the congestion window by 2. 476 4.6. Combination of schedulers type: Priority and Lowest round-trip- 477 time first 479 Combining some types of schedulers can be a way to address some use 480 cases. For example, a scheduler using the priority and the round- 481 trip-time attributes can be used to give more priorities to some 482 links having a lower cost (e.g. fixed vs. mobile accesses) while 483 still being able to benefit from the advantages of the "Lowest RTT 484 First" scheduler described in Section 4.5. A prototype of this 485 "hybrid" scheduler is shown in Figure 6. 487 class PriorityAndLowestRTTFirst(Scheduler): 488 """ Chooses the first available path with """ 489 """ the highest priority and then the lowest RTT. """ 491 def schedule(self, packet_len: int): 492 # Sort paths by ascending priority (2nd sort) 493 # and then ascending SRTT (1st sort) 494 paths = sorted(self.paths, key=lambda path: path.srtt) 495 paths = sorted(paths, key=lambda path: path.priority, reverse=True) 496 for p in paths: 497 if not p.blocked(packet_len) 498 and p.cc.state is not CCState.recovery: 499 return p 501 Figure 6: A scheduler combining priority and RTT attributes 503 Combining some properties can have new undesired effects. In the 504 case presented here, paths with a higher priority but also a higher 505 RTT can affect performances compared to a setup having a scheduler 506 not looking at the priority but only the round-trip-time. If paths 507 with a higher priority are used first whatever the network conditions 508 are on these paths, it is normal to sacrifice the total bandwidth 509 capacity but fully use the capacity of these links with a higher 510 priority. If the paths with a lower priority are seen as extra 511 capacity that can be used only when the other links are congested, it 512 is fine if they are not fully used when the sender is limited by the 513 global sending window of the multipath connection. 515 For this kind of scheduler, it could be interesting to also associate 516 the benefits associated to a "Round-Trip-Time Threshold" scheduler 517 described in Section 4.4. This scheduler prevents being too impacted 518 by links having a higher priority but a very high RTT while other 519 paths, with a lower priority and a lower RTT, can be used. It is a 520 matter of qualifying what is important: maximizing the use of paths 521 over reducing the latency and probably the total bandwidth as well if 522 the sender and/or the receiver are limited by congestion windows. 524 It is also important to note that the penalization mechanism 525 described in the "Lowest round-trip-time first" scheduler in 526 Section 4.5 also needs to take into account the priority. If the 527 goal is to maximize the use of some links over others, links with a 528 higher priority cannot be penalized over the ones with a lower 529 priority. The consequence of this would be that links with higher 530 priority are under used due to the penalization. 532 ASCII figure 534 Figure 7: A simple figure 536 5. Informative References 538 [ACMCS14] Paasch, C., Ferlin, S., Alay, O., and O. Bonaventure, 539 "Experimental Evaluation of Multipath TCP Schedulers", 540 Proceedings of the 2014 ACM SIGCOMM workshop on Capacity 541 sharing workshop , n.d.. 543 [CONEXT15] Hesmans, B., Detal, G., Barre, S., Bauduin, R., and O. 544 Bonaventure, "SMAPP : Towards Smart Multipath TCP- 545 enabled APPlications", CoNEXT '15: Proceedings of the 11th 546 ACM Conference on Emerging Networking Experiments and 547 Technologies , n.d.. 549 [I-D.amend-tsvwg-multipath-dccp] 550 Amend, M., Hugo, D. V., Brunstrom, A., Kassler, A., 551 Rakocevic, V., and S. Johnson, "DCCP Extensions for 552 Multipath Operation with Multiple Addresses", Work in 553 Progress, Internet-Draft, draft-amend-tsvwg-multipath- 554 dccp-05, 12 July 2021, . 557 [I-D.deconinck-quic-multipath] 558 Coninck, Q. D. and O. Bonaventure, "Multipath Extensions 559 for QUIC (MP-QUIC)", Work in Progress, Internet-Draft, 560 draft-deconinck-quic-multipath-07, 3 May 2021, 561 . 564 [I-D.tuexen-tsvwg-sctp-multipath] 565 Amer, P. D., Becke, M., Dreibholz, T., Ekiz, N., Iyengar, 566 J., Natarajan, P., Stewart, R. R., and M. Tuexen, "Load 567 Sharing for the Stream Control Transmission Protocol 568 (SCTP)", Work in Progress, Internet-Draft, draft-tuexen- 569 tsvwg-sctp-multipath-22, 9 August 2021, 570 . 573 [MultipathSim] 574 Piraux, M., "Multipath simulator for the IETF draft 575 Multipath schedulers", n.d., 576 . 579 [NSDI12] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., 580 Duchene, F., Bonaventure, O., and M. Handley, "How Hard 581 Can It Be? Designing and Implementing a Deployable 582 Multipath TCP", 9th USENIX Symposium on Networked Systems 583 Design and Implementation (NSDI 12) , n.d.. 585 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 586 "Computing TCP's Retransmission Timer", RFC 6298, 587 DOI 10.17487/RFC6298, June 2011, 588 . 590 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 591 Congestion Control for Multipath Transport Protocols", 592 RFC 6356, DOI 10.17487/RFC6356, October 2011, 593 . 595 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 596 "TCP Extensions for Multipath Operation with Multiple 597 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 598 . 600 Appendix A. Change log 602 A.1. Since draft-bonaventure-iccrg-schedulers-00 604 * Renamed Delay Threshold to RTT Threshold 606 * Added the Priority And Lowest RTT First scheduler 608 Authors' Addresses 610 Olivier Bonaventure 611 UCLouvain 613 Email: Olivier.Bonaventure@uclouvain.be 615 Maxime Piraux 616 UCLouvain 618 Email: Maxime.Piraux@uclouvain.be 620 Quentin De Coninck 621 UCLouvain 623 Email: quentin.deconinck@uclouvain.be 625 Matthieu Baerts 626 Tessares 628 Email: Matthieu.Baerts@tessares.net 630 Christoph Paasch 631 Apple 633 Email: cpaasch@apple.com 635 Markus Amend 636 Deutsche Telekom 638 Email: markus.amend@telekom.de