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