idnits 2.17.1 draft-ietf-mptcp-architecture-04.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 (January 11, 2011) is 4853 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) == Outdated reference: A later version (-12) exists of draft-ietf-mptcp-multiaddressed-02 -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. '5') (Obsoleted by RFC 9260) == Outdated reference: A later version (-07) exists of draft-ietf-mptcp-congestion-01 == Outdated reference: A later version (-07) exists of draft-ietf-mptcp-api-00 == Outdated reference: A later version (-08) exists of draft-ietf-mptcp-threat-06 == Outdated reference: A later version (-27) exists of draft-tuexen-tsvwg-sctp-multipath-01 -- Obsolete informational reference (is this intentional?): RFC 6093 (ref. '20') (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Ford, Ed. 3 Internet-Draft Roke Manor Research 4 Intended status: Informational C. Raiciu 5 Expires: July 15, 2011 M. Handley 6 University College London 7 S. Barre 8 Universite catholique de 9 Louvain 10 J. Iyengar 11 Franklin and Marshall College 12 January 11, 2011 14 Architectural Guidelines for Multipath TCP Development 15 draft-ietf-mptcp-architecture-04 17 Abstract 19 Hosts are often connected by multiple paths, but TCP restricts 20 communications to a single path per transport connection. Resource 21 usage within the network would be more efficient were these multiple 22 paths able to be used concurrently. This should enhance user 23 experience through improved resilience to network failure and higher 24 throughput. 26 This document outlines architectural guidelines for the development 27 of a Multipath Transport Protocol, with references to how these 28 architectural components come together in the development of a 29 Multipath TCP protocol. This document lists certain high level 30 design decisions that provide foundations for the design of the MPTCP 31 protocol, based upon these architectural requirements. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 15, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.3. Reference Scenario . . . . . . . . . . . . . . . . . . . . 5 71 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 6 73 2.2. Compatibility Goals . . . . . . . . . . . . . . . . . . . 7 74 2.2.1. Application Compatibility . . . . . . . . . . . . . . 7 75 2.2.2. Network Compatibility . . . . . . . . . . . . . . . . 7 76 2.2.3. Compatibility with other network users . . . . . . . . 9 77 2.3. Security Goals . . . . . . . . . . . . . . . . . . . . . . 9 78 2.4. Related Protocols . . . . . . . . . . . . . . . . . . . . 9 79 3. An Architectural Basis For Multipath TCP . . . . . . . . . . . 10 80 4. A Functional Decomposition of MPTCP . . . . . . . . . . . . . 12 81 5. High-Level Design Decisions . . . . . . . . . . . . . . . . . 13 82 5.1. Sequence Numbering . . . . . . . . . . . . . . . . . . . . 14 83 5.2. Reliability and Retransmissions . . . . . . . . . . . . . 15 84 5.3. Buffers . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 5.4. Signalling . . . . . . . . . . . . . . . . . . . . . . . . 17 86 5.5. Path Management . . . . . . . . . . . . . . . . . . . . . 18 87 5.6. Connection Identification . . . . . . . . . . . . . . . . 19 88 5.7. Congestion Control . . . . . . . . . . . . . . . . . . . . 20 89 5.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 6. Interactions with Applications . . . . . . . . . . . . . . . . 21 91 7. Interactions with Middleboxes . . . . . . . . . . . . . . . . 22 92 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 99 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 26 100 A.1. Changes since draft-ietf-mptcp-architecture-03 . . . . . . 26 101 A.2. Changes since draft-ietf-mptcp-architecture-02 . . . . . . 26 102 A.3. Changes since draft-ietf-mptcp-architecture-01 . . . . . . 26 103 A.4. Changes since draft-ietf-mptcp-architecture-00 . . . . . . 27 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 As the Internet evolves, demands on Internet resources are ever- 109 increasing, but often these resources (in particular, bandwidth) 110 cannot be fully utilised due to protocol constraints both on the end- 111 systems and within the network. If these resources could instead be 112 used concurrently, end user experience could be greatly improved. 113 Such enhancements would also reduce the necessary expenditure on 114 network infrastructure that would otherwise be needed to create an 115 equivalent improvement in user experience. 117 By the application of resource pooling [3], these available resources 118 can be 'pooled' such that they appear as a single logical resource to 119 the user. The purpose of a multipath transport, therefore, is to 120 make use of multiple available paths, through resource pooling, to 121 bring two key benefits: 123 o To increase the resilience of the connectivity by providing 124 multiple paths, protecting end hosts from the failure of one. 126 o To increase the efficiency of the resource usage, and thus 127 increase the network capacity available to end hosts. 129 Multipath TCP is a modified version of TCP [1] that implements a 130 multipath transport and achieves these goals by pooling multiple 131 paths within a transport connection, transparently to the 132 application. MPTCP, defined in [4], is a specific protocol that 133 instantiates the Multipath TCP concept. This document looks both at 134 general architectural principles for a Multipath TCP fulfilling the 135 goals described in Section 2, as well as the key design decisions 136 behind MPTCP, which are detailed in Section 5. 138 Although multihoming and multipath functions are not new to transport 139 protocols (SCTP [5] being a notable example), MPTCP aims to gain 140 wide-scale deployment by recognising the importance of application 141 and network compatibility goals. These goals, discussed in detail in 142 Section 2, relate to the appearance of MPTCP to the network (so non- 143 MPTCP-aware entities see it as TCP) and to the application (through 144 providing an equivalent service to TCP to non-MPTCP-aware 145 applications). 147 This document has three key purposes: (i) it describes goals for a 148 multipath transport - goals that MPTCP is designed to meet; (ii) it 149 lays out an architectural basis for MPTCP's design - a discussion 150 that applies to other multipath transports as well; and (iii) it 151 discusses and documents high-level design decisions made in MPTCP's 152 development, and considers their implications. 154 Companion documents to this architectural overview are those which 155 provide details of the protocol extensions [4], congestion control 156 algorithms [6], and application-level considerations [7]. Put 157 together, these components specify a complete Multipath TCP design. 158 We note that specific components are replaceable in accordance with 159 the layer and functional decompositions discussed in this document. 161 1.1. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [2]. 167 1.2. Terminology 169 Multipath TCP: A modified version of the TCP [1] protocol that 170 supports the simultaneous use of multiple paths between hosts. 172 Path: A sequence of links between a sender and a receiver, defined 173 in this context by a source and destination address pair. 175 Host: An end host either initiating or terminating a Multipath TCP 176 connection. 178 MPTCP: The proposed protocol extensions specified in [4] to provide 179 a Multipath TCP implementation. 181 Subflow: A flow of TCP segments operating over an individual path, 182 which forms part of a larger Multipath TCP connection. 184 (Multipath TCP) Connection: A set of one or more subflows combined 185 to provide a single Multipath TCP service to an application at a 186 host. 188 1.3. Reference Scenario 190 The diagram shown in Figure 1 illustrates a typical usage scenario 191 for Multipath TCP. Two hosts, A and B, are communicating with each 192 other. These hosts are multi-homed and multi-addressed, providing 193 two disjoint connections to the Internet. The addresses on each host 194 are referred to as A1, A2, B1 and B2. There are therefore up to four 195 different paths between the two hosts: A1-B1, A1-B2, A2-B1, A2-B2. 197 +------+ __________ +------+ 198 | |A1 ______ ( ) ______ B1| | 199 | Host |--/ ( ) \--| Host | 200 | | ( Internet ) | | 201 | A |--\______( )______/--| B | 202 | |A2 (__________) B2| | 203 +------+ +------+ 205 Figure 1: Simple Multipath TCP Usage Scenario 207 The scenario could have any number of addresses (1 or more) on each 208 host, so long as the number of paths available between the two hosts 209 is 2 or more (i.e. num_addr(A) * num_addr(B) > 1). The paths created 210 by these address combinations through the Internet need not be 211 entirely disjoint - potential fairness issues introduced by shared 212 bottlenecks need to be handled by the Multipath TCP congestion 213 controller. Furthermore, the paths through the Internet often do not 214 provide a pure end-to-end service, and instead may be affected by 215 middleboxes such as NATs and Firewalls. 217 2. Goals 219 This section outlines primary goals that Multipath TCP aims to meet. 220 These are broadly broken down into: functional goals, which steer 221 services and features that Multipath TCP must provide; and 222 compatibility goals, which determine how Multipath TCP should appear 223 to entities that interact with it. 225 2.1. Functional Goals 227 In supporting the use of multiple paths, Multipath TCP has the 228 following two functional goals. 230 o Improve Throughput: Multipath TCP MUST support the concurrent use 231 of multiple paths. To meet the minimum performance incentives for 232 deployment, a Multipath TCP connection over multiple paths SHOULD 233 achieve no lesser throughput than a single TCP connection over the 234 best constituent path. 236 o Improve Resilience: Multipath TCP MUST support the use of multiple 237 paths interchangeably for resilience purposes, by permitting 238 segments to be sent and re-sent on any available path. It follows 239 that, in the worst case, the protocol MUST be no less resilient 240 than regular single-path TCP. 242 As distribution of traffic among available paths and responses to 243 congestion are done in accordance with resource pooling principles 245 [3], a secondary effect of meeting these goals is that widespread use 246 of Multipath TCP over the Internet should improve overall network 247 utility by shifting load away from congested bottlenecks and by 248 taking advantage of spare capacity wherever possible. 250 Furthermore, Multipath TCP SHOULD feature automatic negotiation of 251 its use. A host supporting Multipath TCP that requires the other 252 host to do so too must be able to detect reliably whether this host 253 does in fact support the required extensions, using them if so, and 254 otherwise automatically falling back to single-path TCP. 256 2.2. Compatibility Goals 258 In addition to the functional goals listed above, a Multipath TCP 259 must meet a number of compatibility goals in order to support 260 deployment in today's Internet. These goals fall into the following 261 categories: 263 2.2.1. Application Compatibility 265 Application compatibility refers to the appearance of Multipath TCP 266 to the application both in terms of the API that can be used and the 267 expected service model that is provided. 269 Multipath TCP MUST follow the same service model as TCP [1]: in- 270 order, reliable, and byte-oriented delivery. Furthermore, a 271 Multipath TCP connection SHOULD provide the application with no worse 272 throughput than it would expect from running a single TCP connection 273 over any one of its available paths. 275 A multipath-capable equivalent of TCP MUST retain some level of 276 backward compatibility with existing TCP APIs, so that existing 277 applications can use the newer transport merely by upgrading the 278 operating systems of the end-hosts. This does not preclude the use 279 of an advanced API to permit multipath-aware applications to specify 280 preferences, nor for users to configure their systems in a different 281 way from the default, for example switching on or off the automatic 282 use of multipath extensions. 284 2.2.2. Network Compatibility 286 In the traditional Internet architecture, network devices operate at 287 the network layer and lower layers, with the layers above the network 288 layer instantiated only at the end-hosts. While this architecture, 289 shown in Figure 2, was initially largely adhered to, this layering no 290 longer reflects the "ground truth" in the Internet with the 291 proliferation of middleboxes [8]. Middleboxes routinely interpose on 292 the transport layer; sometimes even completely terminating transport 293 connections, thus leaving the application layer as the first real 294 end-to-end layer, as shown in Figure 3. 296 +-------------+ +-------------+ 297 | Application |<------------ end-to-end ------------->| Application | 298 +-------------+ +-------------+ 299 | Transport |<------------ end-to-end ------------->| Transport | 300 +-------------+ +-------------+ +-------------+ +-------------+ 301 | Network |<->| Network |<->| Network |<->| Network | 302 +-------------+ +-------------+ +-------------+ +-------------+ 303 End Host Router Router End Host 305 Figure 2: Traditional Internet Architecture 307 +-------------+ +-------------+ 308 | Application |<------------ end-to-end ------------->| Application | 309 +-------------+ +-------------+ +-------------+ 310 | Transport |<------------------->| Transport |<->| Transport | 311 +-------------+ +-------------+ +-------------+ +-------------+ 312 | Network |<->| Network |<->| Network |<->| Network | 313 +-------------+ +-------------+ +-------------+ +-------------+ 314 Firewall, 315 End Host Router NAT, or Proxy End Host 317 Figure 3: Internet Reality 319 Middleboxes that interpose on the transport layer result in loss of 320 "fate-sharing" [9], that is, they often hold "hard" state that, when 321 lost or corrupted, results in loss or corruption of the end-to-end 322 transport connection. 324 The network compatibility goal requires that the multipath extension 325 to TCP retains compatibility with the Internet as it exists today, 326 including making reasonable efforts to be able to traverse 327 predominant middleboxes such as firewalls, NATs, and performance 328 enhancing proxies [8]. This requirement comes from recognizing 329 middleboxes as a significant deployment bottleneck for any transport 330 that is not TCP or UDP, and constrains Multipath TCP to appear as TCP 331 does on the wire and to use established TCP extensions where 332 necessary. To ensure end-to-endness of the transport, we further 333 require Multipath TCP to preserve fate-sharing without making any 334 assumptions about middlebox behavior. 336 A detailed analysis of middlebox behaviour and the impact on the 337 Multipath TCP architecture is presented in Section 7. In addition, 338 network compatibility must be retained to the extent that Multipath 339 TCP MUST fall back to regular TCP if there are insurmountable 340 incompatibilities for the multipath extension on a path. 342 Middleboxes may also cause some TCP features to be able to exist on 343 one subflow but not another. Typically these will be at the subflow 344 level (such as SACK [10]) and thus do not affect the connection-level 345 behaviour. In the future, any proposed TCP connection-level 346 extensions should consider how they can co-exist with MPTCP. 348 The modifications to support Multipath TCP remain at the transport 349 layer, although some knowledge of the underlying network layer is 350 required. Multipath TCP SHOULD work with IPv4 and IPv6 351 interchangeably, i.e. one connection may operate over both IPv4 and 352 IPv6 networks. 354 2.2.3. Compatibility with other network users 356 As a corollary to both network and application compatibility, the 357 architecture must enable new Multipath TCP flows to coexist 358 gracefully with existing single-path TCP flows, competing for 359 bandwidth neither unduly aggressively nor unduly timidly (unless low- 360 precedence operation is specifically requested by the application, 361 such as with LEDBAT). The use of multiple paths MUST NOT unduly harm 362 users using single-path TCP at shared bottlenecks, beyond the impact 363 that would occur from another single-path TCP flow. Multiple 364 Multipath TCP flows on a shared bottleneck MUST share bandwidth 365 between each other with similar fairness to that which occurs at a 366 shared bottleneck with single-path TCP. 368 2.3. Security Goals 370 The extension of TCP with multipath capabilities will bring with it a 371 number of new threats, analysed in detail in [11]. The security goal 372 for Multipath TCP is to provide a service no less secure than 373 regular, single-path TCP. This will be achieved through a 374 combination of existing TCP security mechanisms (potentially modified 375 to align with the Multipath TCP extensions) and of protection against 376 the new multipath threats identified. The design decisions derived 377 from this goal are presented in Section 5.8. 379 2.4. Related Protocols 381 There are several similarities between SCTP [5] and MPTCP, in that 382 both can make use of multiple addresses at end hosts to give some 383 multi-path capability. In SCTP, the primary use case is to support 384 redundancy and mobility for multihomed hosts (i.e. a single path will 385 change one of its end host addresses); the simultaneous use of 386 multiple paths is not supported . Extensions are proposed to support 387 simultaneous multipath transport [12], but these are yet to be 388 standardised. By far the most widely used stream-based transport 389 protocol is, however, TCP [1], and SCTP does not meet the network and 390 application compatibility goals specified in Section 2.2. For 391 network compatibility, there are issues with various middleboxes 392 (especially NATs) that are unaware of SCTP and consequently end up 393 blocking it. For application compatibility, applications need to 394 actively choose to use SCTP, and with the deployment issues very few 395 choose to do so. MPTCP's compatibility goals are in part based on 396 these observations of SCTP's deployment issues. 398 3. An Architectural Basis For Multipath TCP 400 We now present one possible transport architecture that we believe 401 can effectively support the goals for Multipath TCP. The new 402 Internet model described here is based on ideas proposed earlier in 403 Tng ("Transport next-generation") [13]. While by no means the only 404 possible architecture supporting multipath transport, Tng 405 incorporates many lessons learned from previous transport research 406 and development practice, and offers a strong starting point from 407 which to consider the extant Internet architecture and its bearing on 408 the design of any new Internet transports or transport extensions. 410 +------------------+ 411 | Application | 412 +------------------+ ^ Application-oriented transport 413 | | | functions (Semantic Layer) 414 + - - Transport - -+ ---------------------------------- 415 | | | Network-oriented transport 416 +------------------+ v functions (Flow+Endpoint Layer) 417 | Network | 418 +------------------+ 419 Existing Layers Tng Decomposition 421 Figure 4: Decomposition of Transport Functions 423 Tng loosely splits the transport layer into "application-oriented" 424 and "network-oriented" layers, as shown in Figure 4. The 425 application-oriented "Semantic" layer implements functions driven 426 primarily by concerns of supporting and protecting the application's 427 end-to-end communication, while the network-oriented "Flow+Endpoint" 428 layer implements functions such as endpoint identification (using 429 port numbers) and congestion control. These network-oriented 430 functions, while traditionally located in the ostensibly "end-to-end" 431 Transport layer, have proven in practice to be of great concern to 432 network operators and the middleboxes they deploy in the network to 433 enforce network usage policies [14] [15] or optimize communication 434 performance [16]. Figure 5 shows how middleboxes interact with 435 different layers in this decomposed model of the transport layer: the 436 application-oriented layer operates end-to-end, while the network- 437 oriented layer operates "segment-by-segment" and can be interposed 438 upon by middleboxes. 440 +-------------+ +-------------+ 441 | Application |<------------ end-to-end ------------->| Application | 442 +-------------+ +-------------+ 443 | Semantic |<------------ end-to-end ------------->| Semantic | 444 +-------------+ +-------------+ +-------------+ +-------------+ 445 |Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint| 446 +-------------+ +-------------+ +-------------+ +-------------+ 447 | Network |<->| Network |<->| Network |<->| Network | 448 +-------------+ +-------------+ +-------------+ +-------------+ 449 Firewall Performance 450 End Host or NAT Enhancing Proxy End Host 452 Figure 5: Middleboxes in the new Internet model 454 MPTCP's architectural design follows Tng's decomposition as shown in 455 Figure 6. MPTCP, which provides application compatibility through 456 the preservation of TCP-like semantics of global ordering of 457 application data and reliability, is an instantiation of the 458 "application-oriented" Semantic layer; whereas the subflow TCP 459 component, which provides network compatibility by appearing and 460 behaving as a TCP flow in the network, is an instantiation of the 461 "network-oriented" Flow+Endpoint layer. 463 +--------------------------+ +-------------------------------+ 464 | Application | | Application | 465 +--------------------------+ +-------------------------------+ 466 | Semantic | | MPTCP | 467 |------------+-------------| + - - - - - - - + - - - - - - - + 468 | Flow+Endpt | Flow+Endpt | | Subflow (TCP) | Subflow (TCP) | 469 +------------+-------------+ +---------------+---------------+ 470 | Network | Network | | IP | IP | 471 +------------+-------------+ +---------------+---------------+ 473 Figure 6: Relationship between Tng (left) and MPTCP (right) 475 As a protocol extension to TCP, MPTCP thus explicitly acknowledges 476 middleboxes in its design, and specifies a protocol that operates at 477 two scales: the MPTCP component operates end-to-end, while it allows 478 the TCP component to operate segment-by-segment. 480 4. A Functional Decomposition of MPTCP 482 The previous two sections have discussed the goals for a Multipath 483 TCP design, and provided a basis for decomposing the functions of a 484 transport protocol in order to better understand the form a solution 485 should take. This section builds upon this analysis by presenting 486 the functional components that are used within the MPTCP design. 488 MPTCP makes use of (what appear to the network to be) standard TCP 489 sessions, termed "subflows", to provide the underlying transport per 490 path, and as such these retain the network compatibility desired. 491 MPTCP-specific information is carried in a TCP-compatible manner, 492 although this mechanism is separate from the actual information being 493 transferred so could evolve in future revisions. Figure 7 494 illustrates the layered architecture. 496 +-------------------------------+ 497 | Application | 498 +---------------+ +-------------------------------+ 499 | Application | | MPTCP | 500 +---------------+ + - - - - - - - + - - - - - - - + 501 | TCP | | Subflow (TCP) | Subflow (TCP) | 502 +---------------+ +-------------------------------+ 503 | IP | | IP | IP | 504 +---------------+ +-------------------------------+ 506 Figure 7: Comparison of Standard TCP and MPTCP Protocol Stacks 508 Situated below the application, the MPTCP extension in turn manages 509 multiple TCP subflows below it. In order to do this, it must 510 implement the following functions: 512 o Path Management: This is the function to detect and use multiple 513 paths between two hosts. MPTCP uses the presence of multiple IP 514 addresses at one or both of the hosts as an indicator of this. 515 The path management features of the MPTCP protocol are the 516 mechanisms to signal alternative addresses to hosts, and 517 mechanisms to set up new subflows joined to an existing MPTCP 518 connection. 520 o Packet Scheduling: This function breaks the bytestream received 521 from the application into segments to be transmitted on one of the 522 available subflows. The MPTCP design makes use of a data sequence 523 mapping, associating segments sent on different subflows to a 524 connection-level sequence numbering, thus allowing segments sent 525 on different subflows to be correctly re-ordered at the receiver. 526 The packet scheduler is dependent upon information about the 527 availability of paths exposed by the path management component, 528 and then makes use of the subflows to transmit queued segments. 529 This function is also responsible for connection-level re-ordering 530 on receipt of packets from the TCP subflows, according to the 531 attached data sequence mappings. 533 o Subflow (single-path TCP) Interface: A subflow component takes 534 segments from the packet-scheduling component and transmits them 535 over the specified path, ensuring detectable delivery to the host. 536 MPTCP uses TCP underneath for network compatibility; TCP ensures 537 in-order, reliable delivery. TCP adds its own sequence numbers to 538 the segments; these are used to detect and retransmit lost packets 539 at the subflow layer. On receipt, the subflow passes its 540 reassembled data to the packet scheduling component for 541 connection-level reassembly; the data sequence mapping from the 542 sender's packet scheduling component allows re-ordering of the 543 entire bytestream. 545 o Congestion Control: This function coordinates congestion control 546 across the subflows. As specified, this congestion control 547 algorithm MUST ensure that a MPTCP connection does not unfairly 548 take more bandwidth than a single path TCP flow would take at a 549 shared bottleneck. An algorithm to support this is specified in 550 [6]. 552 These functions fit together as follows. The Path Management looks 553 after the discovery (and if necessary, initialisation) of multiple 554 paths between two hosts. The Packet Scheduler then receives a stream 555 of data from the application destined for the network, and undertakes 556 the necessary operations on it (such as segmenting the data into 557 connection-level segments, and adding a connection-level sequence 558 number) before sending it on to a subflow. The subflow then adds its 559 own sequence number, ACKs, and passes them to network. The receiving 560 subflow re-orders data (if necessary) and passes it to the packet 561 scheduling component, which performs connection level re-ordering, 562 and sends the data stream to the application. Finally, the 563 congestion control component exists as part of the packet scheduling, 564 in order to schedule which segments should be sent at what rate on 565 which subflow. 567 5. High-Level Design Decisions 569 There is seemingly a wide range of choices when designing a multipath 570 extension to TCP. However, the goals as discussed earlier in this 571 document constrain the possible solutions, leaving relative little 572 choice in many areas. Here, we outline high-level design choices 573 that draw from the architectural basis discussed earlier in 574 Section 3, which the design of MPTCP [4] takes into account. 576 5.1. Sequence Numbering 578 MPTCP uses two levels of sequence spaces: a connection level sequence 579 number, and another sequence number for each subflow. This permits 580 connection-level segmentation and reassembly, and retransmission of 581 the same part of connection-level sequence space on different 582 subflow-level sequence space. 584 The alternative approach would be to use a single connection level 585 sequence number, which gets sent on multiple subflows. This has two 586 problems: first, the individual subflows will appear to the network 587 as TCP sessions with gaps in the sequence space; this in turn may 588 upset certain middleboxes such as intrusion detection systems, or 589 certain transparent proxies, and would thus go against the network 590 compatibility goal. Second, the sender would not be able to 591 attribute packet losses or receptions to the correct path when the 592 same segment is sent on multiple paths (i.e. in the case of 593 retransmissions). 595 The sender must be able to tell the receiver how to reassemble the 596 data, for delivery to the application. In order to achieve this, the 597 receiver must determine how subflow-level data (carrying subflow 598 sequence numbers) maps at the connection level. We refer to this as 599 the Data Sequence Mapping. This mapping takes the form (data seq, 600 subflow seq, length), i.e. for a given number of bytes (the length), 601 the subflow sequence space beginning at the given sequence number 602 maps to the connection-level sequence space (beginning at the given 603 data seq number). This information could conceivably have various 604 sources. 606 One option to signal the Data Sequence Mapping would be to use 607 existing fields in the TCP segment (such as subflow seqno, length) 608 and only add the data sequence number to each segment, for instance 609 as a TCP option. This would be vulnerable, however, to middleboxes 610 that resegment or assemble data, since there is no specified 611 behaviour for coalescing TCP options. If one signalled (data seqno, 612 length), this would still be vulnerable to middleboxes that coalesce 613 segments and do not understand MPTCP signalling so do not correctly 614 rewrite the options. 616 Because of these potential issues, the design decision taken in the 617 MPTCP protocol is that whenever a mapping for subflow data needs to 618 be conveyed to the other host, all three pieces of data (data seq, 619 subflow seq, length) must be sent. To reduce the overhead, it would 620 be permissible for the mapping to be sent periodically and cover more 621 than a single segment. Further experimentation is required to 622 determine what tradeoffs exist regarding the frequency at which 623 mappings should be sent. It could also be excluded entirely in the 624 case of a connection before more than one subflow is used, where the 625 data-level and subflow-level sequence space is the same. 627 5.2. Reliability and Retransmissions 629 MPTCP features acknowledgements at connection-level as well as 630 subflow-level acknowledgements, in order to provide a robust service 631 to the application. 633 Under normal behaviour, MPTCP can use the data sequence mapping and 634 subflow ACKs to decide when a connection-level segment was received. 635 The transmission of TCP ACKs for a subflow are handled entirely at 636 the subflow level, in order to maintain TCP semantics and trigger 637 subflow-level retransmissions. This has certain implications on end- 638 to-end semantics. It means that once a segment is ACKed at the 639 subflow level it cannot be discarded in the re-order buffer at the 640 connection level. Secondly, unlike in standard TCP, a receiver 641 cannot simply drop out-of-order segments if needed (for instance, due 642 to memory pressure). Under certain circumstances, therefore, it may 643 be desirable to drop segments after acknowledgement on the subflow 644 but before delivery to the application, and this can be facilitated 645 by a connection-level acknowledgement. 647 Furthermore, it is possible to conceive of some cases where 648 connection-level acknowledgements could improve robustness. Consider 649 a subflow traversing a transparent proxy: if the proxy ACKs a segment 650 and then crashes, the sender will not retransmit the lost segment on 651 another subflow, as it thinks the segment has been received. The 652 connection grinds to a halt despite having other working subflows, 653 and the sender would be unable to determine the cause of the problem. 654 An example situation where this may occur would be mobility between 655 wireless access points, each of which operates a transport-level 656 proxy. Finally, as an optimisation, it may be feasible for a 657 connection-level acknowledgement to be transmitted over the shortest 658 Round-Trip Time (RTT) path, potentially reducing send buffer 659 requirements (see Section 5.3). 661 Therefore, to provide a fully robust multipath TCP solution given the 662 above constraints, MPTCP for use on the public Internet MUST feature 663 explicit connection-level acknowledgements, in addition to subflow- 664 level acknowledgements. A connection-level acknowledgement would 665 only be required in order to signal when the receive window moves 666 forward; the heuristics for using such a signal are discussed in more 667 detail in the protocol specification [4]. 669 Regarding retransmissions, it MUST be possible for a segments to be 670 retransmitted on a different subflow to that on which it was 671 originally sent. This is one of MPTCP's core goals, in order to 672 maintain integrity during temporary or permanent subflow failure, and 673 this is enabled by the dual sequence number space. 675 The scheduling of retransmissions will have significant impact on 676 MPTCP user experience. The current MPTCP specification suggests that 677 data outstanding on subflows that have timed out should be 678 rescheduled for transmission on different subflows. This behaviour 679 aims to minimize disruption when a path breaks, and uses the first 680 timeout as indicators. More conservative versions would be to use 681 second or third timeouts for the same segment. 683 Typically, fast retransmit on an individual subflow will not trigger 684 retransmission on another subflow, although this may still be 685 desirable in certain cases, for instance to reduce the receive buffer 686 requirements. However, in all cases with retransmissions on 687 different subflows, the lost segments SHOULD still be sent on the 688 path that lost them. This is currently believed to be necessary to 689 maintain subflow integrity, as per the network compatibility goal. 690 By doing this, some efficiency is lost, and it is unclear at this 691 point what the optimal retransmit strategy is. 693 Large-scale experiments are therefore required in order to determine 694 the most appropriate retransmission strategy, and recommendations 695 will be refined once more information is available. 697 5.3. Buffers 699 To ensure in-order delivery, MPTCP must use a connection level 700 receive buffer, where segments are placed until they are in order and 701 can be read by the application. 703 In regular, single-path TCP, it is usually recommended to set the 704 receive buffer to 2*BDP (Bandwidth-Delay Product, i.e. BDP = BW*RTT, 705 where BW = Bandwidth and RTT = Round-Trip Time). One BDP allows 706 supporting reordering of segments by the network. The other BDP 707 allows the connection to continue during fast retransmit: when a 708 segment is fast retransmitted, the receiver must be able to store 709 incoming data during one more RTT. 711 For MPTCP, the story is a bit more complicated. The ultimate goal is 712 that a subflow packet loss or subflow failure should not affect the 713 throughput of other working subflows; the receiver should have enough 714 buffering to store all data until the missing segment is re- 715 transmitted and reaches the destination. 717 The worst case scenario would be when the subflow with the highest 718 RTT/RTO (Round-Trip Time or Retransmission TimeOut) experiences a 719 timeout; in that case the receiver has to buffer data from all 720 subflows for the duration of the RTO. Thus, the smallest connection- 721 level receive buffer that would be needed to avoid stalling with 722 subflow failures is sum(BW_i)*RTO_max, where BW_i = Bandwidth for 723 each subflow and RTO_max is the largest RTO across all subflows. 725 This is an order of magnitude more than the receive buffer required 726 for a single connection, and is probably too expensive for practical 727 purposes. A more sensible requirement is to avoid stalls in the 728 absence of timeouts. Therefore, the RECOMMENDED receive buffer is 729 2*sum(BW_i)*RTT_max, where RTT_max is the largest RTT across all 730 subflows. This buffer sizing ensures subflows do not stall when fast 731 retransmit is triggered on any subflow. 733 The resulting buffer size should be small enough for practical use. 734 However, there may be extreme cases where fast, high throughput paths 735 (e.g. 100Mb/s, 10ms RTT) are used in conjunction with slow paths 736 (e.g. 1Mb/s, 1000ms RTT). In that case the required receive buffer 737 would be 12.5MB, which is likely too big. In extreme cases such as 738 this example, it may be prudent to only use some of the fastest 739 available paths for the MPTCP connection, potentially using the slow 740 path(s) for backup only. 742 Send Buffer: The RECOMMENDED send buffer is the same size as the 743 recommended receive buffer i.e., 2*sum(BW_i)*RTT_max. This is 744 because the sender must store locally the segments sent but 745 unacknowledged by the connection level ACK. The send buffer size 746 matters particularly for hosts that maintain a large number of 747 ongoing connections. If the required send buffer is too large, a 748 host can choose to only send data on the fast subflows, using the 749 slow subflows only in cases of failure. 751 5.4. Signalling 753 Since MPTCP uses TCP as its subflow transport mechanism, a MPTCP 754 connection will also begin as a single TCP connection. Nevertheless, 755 it must signal to the peer that it supports MPTCP and wishes to use 756 it on this connection. As such, a TCP Option will be used to 757 transmit this information, since this is the established mechanism 758 for indicating additional functionality on a TCP session. 760 In addition, further signalling is required during the operation of a 761 MPTCP session, such as that for reassembly for multiple subflows, and 762 for informing the other host about potential other available 763 addresses. 765 The MPTCP protocol design will, however, use TCP Options for this 766 additional signalling. This has been chosen as the mechanism most 767 fitting in with the goals as specified in Section 2. With this 768 mechanism, the signalling requires to operate MPTCP is transported 769 separately from the data, allowing it to be created and processed 770 separately from the data stream, and retaining architectural 771 compatibility with network entities. 773 This decision is the consensus of the Working Group (following 774 detailed discussions at IETF78), and the main reasons for this are as 775 follows: 777 o TCP options are the traditional signalling method for TCP; 779 o A TCP option on a SYN is the most compatible way for an end host 780 to signal it is MPTCP-capable; 782 o If connection-level ACKs are signalled in the payload then they 783 may suffer from packet loss and may be congestion-controlled, 784 which may affect the data throughput in the forward direction and 785 could lead to head-of-line blocking; 787 o Middleboxes, such as NAT traversal helpers, can easily parse TCP 788 options, e. g., to rewrite addresses. 790 On the other hand, the main drawbacks of TCP options compared to TLV 791 encoding in the payload are: 793 o There is limited space for signalling messages; 795 o A middlebox may, potentially, drop a packet with an unknown 796 option; 798 o The transport of control information in options is not necessarily 799 reliable. 801 The detailed design of MPTCP alleviates these issues as far as 802 possible by carefully considering the size of MPTCP options, and 803 seamlessly falling back to regular TCP on the loss of control data. 805 Both option and payload encoding may interfere with offloading of TCP 806 processing to high speed network interface cards, such as 807 segmentation, checksumming, and reassembly. For network cards 808 supporting MPTCP, signalling in TCP options should simplify 809 offloading due to the separate handling of MPTCP signalling and data. 811 5.5. Path Management 813 Currently, the network does not expose path diversity between pairs 814 of IP addresses. In order to achieve path diversity from today's IP 815 networks, in the typical case MPTCP uses multiple addresses at one or 816 both hosts to infer different paths across the network. It is 817 expected that these paths, whilst not necessarily entirely non- 818 overlapping, will be sufficiently disjoint to allow multipath to 819 achieve improved throughput and robustness. The use of multiple IP 820 addresses is a simple mechanism that requires no additional features 821 in the network. 823 Multiple different (source, destination) address pairs will thus be 824 used as path selectors in most cases. Each path will be identified 825 by a standard five-tuple (i.e. source address, destination address, 826 source port, destination port, protocol), however, which can allow 827 the extension of MPTCP to use ports as well as addresses as path 828 selectors. This will allow hosts to use port-based load balancing 829 with MPTCP, for example if the network routes different ports over 830 different paths (which may be the case with technologies such as 831 Equal Cost MultiPath (ECMP) routing [17]). 833 For increased chance of successfully setting up additional subflows 834 (such as when one end is behind a firewall, NAT, or other restrictive 835 middlebox), either host SHOULD be able to add new subflows to a MPTCP 836 connection. MPTCP MUST be able to handle paths that appear and 837 disappear during the lifetime of a connection (for example, through 838 the activation of an additional network interface). 840 The path management is a separate function from the packet 841 scheduling, subflow interface, and congestion control functions of 842 MPTCP, as documented in Section 4. As such it would be feasible to 843 replace this IP-address-based design with an alternative path 844 selection mechanism in the future, with no significant changes to the 845 other functional components. 847 5.6. Connection Identification 849 Since a MPTCP connection may not be bound to a traditional 5-tuple 850 (source address and port, destination address and port, protocol 851 number) for the entirety of its existence, it is desirable to provide 852 a new mechanism for connection identification. This will be useful 853 for MPTCP-aware applications, and for the MPTCP implementation (and 854 MPTCP-aware middleboxes) to have a unique identifier with which to 855 associate the multiple subflows. 857 Therefore, each MPTCP connection requires a connection identifier at 858 each host, which is locally unique within that host. In many ways, 859 this is analogous to a port number in regular TCP. The manifestation 860 and purpose of such an identifier is out of the scope of this 861 architecture document. 863 Legacy applications will not, however, have access to this identifier 864 and in such cases a MPTCP connection will be identified by the 865 5-tuple of the first TCP subflow. It is out of the scope of this 866 document, however, to define the behaviour of the MPTCP 867 implementation if the first TCP subflow later fails. If there are 868 MPTCP-unaware applications that make assumptions about continued 869 existence of the initial address pair, their behaviour could be 870 disrupted by carrying on regardless. It is expected that this is a 871 very small, possibly negligible, set of applications, however. In 872 the case of applications that have used an existing API call to bind 873 to a specific address or interface, the MPTCP extension MUST NOT be 874 used, since the applications are indicating a clear choice of path to 875 use and thus will have expectations of behaviour that must be 876 maintained, in order to adhere to the application compatibility 877 goals. 879 Since the requirements of applications are not clear at this stage, 880 however, it is as yet unconfirmed what the best behaviour is. It 881 will be an implementation-specific solution, however, and as such the 882 behaviour is expected to be chosen by implementors once more research 883 has been undertaken to determine its impact. 885 5.7. Congestion Control 887 As discussed in network-layer compatibility requirements 888 Section 2.2.3, there are three goals for the congestion control 889 algorithms used by a MPTCP implementation: improve throughput (at 890 least as well as a single-path TCP connection would perform); do no 891 harm to other network users (do not take up more capacity on any one 892 path than if it was a single path flow using only that route - this 893 is particularly relevant for shared bottlenecks); and balance 894 congestion by moving traffic away from the most congested paths. To 895 achieve these goals, the congestion control algorithms on each 896 subflow must be coupled in some way. A proposal for a suitable 897 congestion control algorithm is given in [6]. 899 5.8. Security 901 A detailed threat analysis for Multipath TCP is presented in a 902 separate document [11]. This focuses on flooding attacks and 903 hijacking attacks that can be launched against a Multipath TCP 904 connection. 906 The basic security goal of Multipath TCP, as introduced in 907 Section 2.3, can be stated as: "provide a solution that is no worse 908 than standard TCP". 910 From the threat analysis, and with this goal in mind, three key 911 security requirements can be identified. A multi-addressed Multipath 912 TCP SHOULD be able to: 914 o Provide a mechanism to confirm that the parties in a subflow 915 handshake are the same as in the original connection setup (e.g. 916 require use of a key exchanged in the initial handshake in the 917 subflow handshake, to limit the scope for hijacking attacks). 919 o Provide verification that the peer can receive traffic at a new 920 address before adding it (i.e. verify that the address belongs to 921 the other host, to prevent flooding attacks). 923 o Provide replay protection, i.e. ensure that a request to add/ 924 remove a subflow is 'fresh'. 926 Additional mechanisms have been deployed as part of standard TCP 927 stacks to provide resistance to Denial-of-Service attacks. For 928 example, there are various mechanisms to protect against TCP reset 929 attacks [18], and Multipath TCP should continue to support similar 930 protection. In addition, TCP SYN Cookies [19] were developed to 931 allow a TCP server to defer the creation of session state in the 932 SYN_RCVD state, and remain stateless until the ESTABLISHED state had 933 been reached. Multipath TCP should, ideally, continue to provide 934 such functionality and, at a minimum, avoid significant computational 935 burden prior to reaching the ESTABLISHED state (of the Multipath TCP 936 connection as a whole). 938 It should be noted that aspects of the Multipath TCP design space 939 place constraints on the security solution: 941 o The use of TCP options significantly limits the amount of 942 information that can be carried in the handshake. 944 o The need to work through middleboxes results in the need to handle 945 mutability of packets. 947 o The desire to support a 'break-before-make' (as well as a 'make- 948 before-break') approach to adding subflows (within a limited time 949 period) implies that a host cannot rely on using a pre-existing 950 subflow to support the addition of a new one. 952 The MPTCP protocol will be designed with these security requirements 953 in mind, and the protocol specification [4] will document how these 954 are met. 956 6. Interactions with Applications 958 Interactions with applications are presented in [7] - including, but 959 not limited to, performances changes that may be expected, semantic 960 changes, and new features that may be requested through an enhanced 961 API. 963 TCP features the ability to send out-of-band ("Urgent") data. 964 Although the use of Urgent data is not recommended (see [20]), MPTCP 965 SHOULD still support this feature if requested by an application. An 966 MPTCP implementation SHOULD send the Urgent data on one subflow of 967 the MPTCP connection; it MAY choose this to be the best performing 968 subflow. 970 7. Interactions with Middleboxes 972 As discussed in Section 2.2, it is a goal of MPTCP to be deployable 973 today and thus compatible with the majority of middleboxes. This 974 section summarises the issues that may arise with NATs, firewalls, 975 proxies, intrusion detection systems, and other middleboxes that, if 976 not considered in the protocol design, may hinder its deployment. 978 This section is intended primarily as a description of options and 979 considerations only. Protocol-specific solutions to these issues 980 will be given in the companion documents. 982 Multipath TCP will be deployed in a network that no longer provides 983 just basic datagram delivery. A myriad of middleboxes are deployed 984 to optimize various perceived problems with the Internet protocols: 985 NATs primarily address space shortage [14], Performance Enhancing 986 Proxies (PEPs) optimize TCP for different link characteristics [16], 987 firewalls [15] and intrusion detection systems try to block malicious 988 content from reaching a host, and traffic normalizers [21] ensure a 989 consistent view of the traffic stream to Intrusion Detection Systems 990 (IDS) and hosts. 992 All these middleboxes optimize current applications at the expense of 993 future applications. In effect, future applications will often need 994 to behave in a similar fashion to existing ones, in order to increase 995 the chances of successful deployment. Further, the precise behaviour 996 of all these middleboxes is not clearly specified, and implementation 997 errors make matters worse, raising the bar for the deployment of new 998 technologies. 1000 The following list of middlebox classes documents behaviour that 1001 could impact the use of MPTCP. This list is used in [4] to describe 1002 the features of the MPTCP protocol that are used to mitigate the 1003 impact of these middlebox behaviours. 1005 o NATs: Network Address Translators decouple the host's local IP 1006 address (and, in the case of NAPTs, port) with that which is seen 1007 in the wider Internet when the packets are transmitted through a 1008 NAT. This adds complexity, and reduces the chances of success, 1009 when signalling IP addresses. 1011 o PEPs: Performance Enhancing Proxies, which aim to improve the 1012 performance of protocols over low-performance (e.g. high latency 1013 or high error rate) links. As such, they may "split" a TCP 1014 connection and behaviour such as proactive ACKing may occur, and 1015 therefore it is no longer guaranteed that one host is 1016 communicating directly with another. PEPs, firewalls or other 1017 middleboxes may also change the declared receive window size. 1019 o Traffic Normalizers: These aim to eliminate ambiguities and 1020 potential attacks at the network level, and amongst other things 1021 are unlikely to permit holes in TCP-level sequence space (which 1022 has impact on MPTCP's retransmission and subflow sequence 1023 numbering design choices). 1025 o Firewalls: on top of preventing incoming connections, firewalls 1026 may also attempt additional protection such as sequence number 1027 randomization (so a sender cannot reliably know what TCP sequence 1028 number the receiver will see). 1030 o Intrusion Detection Systems: IDSs may look for traffic patterns to 1031 protect a network, and may have false positives with MPTCP and 1032 drop the connections during normal operation. Future MPTCP-aware 1033 middleboxes will require the ability to correlate the various 1034 paths in use. 1036 o Content-aware Firewalls: Some middleboxes may actively change data 1037 in packets, such as re-writing URIs in HTTP traffic. 1039 In addition, all classes of middleboxes may affect TCP traffic in the 1040 following ways: 1042 o TCP Options: some middleboxes may drop packets with unknown TCP 1043 options, or strip those options from the packets. 1045 o Segmentation and Coalescing: middleboxes (or even something as 1046 close to the end host as TCP Segmentation Offloading (TSO) on a 1047 Network Interface Card (NIC)) may change the packet boundaries 1048 from those which the sender intended. It may do this by splitting 1049 packets, or coalescing them together. This leads to two major 1050 impacts: we cannot guarantee where a packet boundary will be, and 1051 we cannot say for sure what a middlebox will do with TCP options 1052 in these cases (they may be repeated, dropped, or sent only once). 1054 8. Contributors 1056 The authors would like to acknowledge the contributions of Andrew 1057 McDonald and Bryan Ford to this document. 1059 The authors would also like to thank the following people for 1060 detailed reviews: Olivier Bonaventure, Gorry Fairhurst, Iljitsch van 1061 Beijnum, Philip Eardley, Michael Scharf, Lars Eggert, and Cullen 1062 Jennings. 1064 9. Acknowledgements 1066 Alan Ford, Costin Raiciu, Mark Handley, and Sebastien Barre are 1067 supported by Trilogy (http://www.trilogy-project.org), a research 1068 project (ICT-216372) partially funded by the European Community under 1069 its Seventh Framework Program. The views expressed here are those of 1070 the author(s) only. The European Commission is not liable for any 1071 use that may be made of the information in this document. 1073 10. IANA Considerations 1075 None. 1077 11. Security Considerations 1079 This informational document provides an architectural overview for 1080 Multipath TCP and so does not, in itself, raise any security issues. 1081 A separate threat analysis [11] lists threats that can exist with a 1082 Multipath TCP. However, a protocol based on the architecture in this 1083 document will have a number of security requirements. The high level 1084 goals for such a protocol are identified in Section 2.3, whilst 1085 Section 5.8 provides more detailed discussion of security 1086 requirements and design decisions which are applied in the MPTCP 1087 protocol design [4]. 1089 12. References 1091 12.1. Normative References 1093 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1094 September 1981. 1096 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1097 Levels", BCP 14, RFC 2119, March 1997. 1099 12.2. Informative References 1101 [3] Wischik, D., Handley, M., and M. Bagnulo Braun, "The Resource 1102 Pooling Principle", ACM SIGCOMM CCR vol. 38 num. 5, pp. 47-52, 1103 October 2008, 1104 . 1106 [4] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for 1107 Multipath Operation with Multiple Addresses", 1108 draft-ietf-mptcp-multiaddressed-02 (work in progress), 1109 October 2010. 1111 [5] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 1112 September 2007. 1114 [6] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion 1115 Control for Multipath Transport Protocols", 1116 draft-ietf-mptcp-congestion-01 (work in progress), 1117 January 2011. 1119 [7] Scharf, M. and A. Ford, "MPTCP Application Interface 1120 Considerations", draft-ietf-mptcp-api-00 (work in progress), 1121 November 2010. 1123 [8] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 1124 RFC 3234, February 2002. 1126 [9] Carpenter, B., "Internet Transparency", RFC 2775, 1127 February 2000. 1129 [10] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1130 Selective Acknowledgment Options", RFC 2018, October 1996. 1132 [11] Bagnulo, M., "Threat Analysis for Multi-addressed/Multi-path 1133 TCP", draft-ietf-mptcp-threat-06 (work in progress), 1134 December 2010. 1136 [12] Becke, M., Dreibholz, T., Iyengar, J., Natarajan, P., and M. 1137 Tuexen, "Load Sharing for the Stream Control Transmission 1138 Protocol (SCTP)", draft-tuexen-tsvwg-sctp-multipath-01 (work in 1139 progress), December 2010. 1141 [13] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam", 1142 ACM HotNets, October 2008. 1144 [14] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1145 Translator (Traditional NAT)", RFC 3022, January 2001. 1147 [15] Freed, N., "Behavior of and Requirements for Internet 1148 Firewalls", RFC 2979, October 2000. 1150 [16] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1151 Shelby, "Performance Enhancing Proxies Intended to Mitigate 1152 Link-Related Degradations", RFC 3135, June 2001. 1154 [17] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", 1155 RFC 2992, November 2000. 1157 [18] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 1158 Robustness to Blind In-Window Attacks", RFC 5961, August 2010. 1160 [19] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", 1161 RFC 4987, August 2007. 1163 [20] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP 1164 Urgent Mechanism", RFC 6093, January 2011. 1166 [21] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion 1167 Detection: Evasion, Traffic Normalization, and End-to-End 1168 Protocol Semantics", Usenix Security 2001, 2001, . 1171 Appendix A. Changelog 1173 (For removal by the RFC Editor) 1175 A.1. Changes since draft-ietf-mptcp-architecture-03 1177 o Responded to AD review comments. 1179 A.2. Changes since draft-ietf-mptcp-architecture-02 1181 o Responded to WG last call review comments. Included editorial 1182 fixes, adding Section 2.4, and improving Section 5.4 and 1183 Section 7. 1185 A.3. Changes since draft-ietf-mptcp-architecture-01 1187 o Responded to review comments. 1189 o Added security sections. 1191 A.4. Changes since draft-ietf-mptcp-architecture-00 1193 o Added middlebox compatibility discussion (Section 7). 1195 o Clarified path identification (TCP 4-tuple) in Section 5.5. 1197 o Added brief scenario and diagram to Section 1.3. 1199 Authors' Addresses 1201 Alan Ford (editor) 1202 Roke Manor Research 1203 Old Salisbury Lane 1204 Romsey, Hampshire SO51 0ZN 1205 UK 1207 Phone: +44 1794 833 465 1208 Email: alan.ford@roke.co.uk 1210 Costin Raiciu 1211 University College London 1212 Gower Street 1213 London WC1E 6BT 1214 UK 1216 Email: c.raiciu@cs.ucl.ac.uk 1218 Mark Handley 1219 University College London 1220 Gower Street 1221 London WC1E 6BT 1222 UK 1224 Email: m.handley@cs.ucl.ac.uk 1226 Sebastien Barre 1227 Universite catholique de Louvain 1228 Pl. Ste Barbe, 2 1229 Louvain-la-Neuve 1348 1230 Belgium 1232 Phone: +32 10 47 91 03 1233 Email: sebastien.barre@uclouvain.be 1234 Janardhan Iyengar 1235 Franklin and Marshall College 1236 Mathematics and Computer Science 1237 PO Box 3003 1238 Lancaster, PA 17604-3003 1239 USA 1241 Phone: 717-358-4774 1242 Email: jiyengar@fandm.edu