idnits 2.17.1 draft-ietf-mptcp-architecture-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 8, 2010) is 4887 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '9' is defined on line 1108, but no explicit reference was found in the text ** 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-00 == 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-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 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: June 11, 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 December 8, 2010 14 Architectural Guidelines for Multipath TCP Development 15 draft-ietf-mptcp-architecture-03 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 June 11, 2011. 50 Copyright Notice 52 Copyright (c) 2010 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 . . . . . . . . . . . . . 11 81 5. High-Level Design Decisions . . . . . . . . . . . . . . . . . 13 82 5.1. Sequence Numbering . . . . . . . . . . . . . . . . . . . . 13 83 5.2. Reliability and Retransmissions . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . 21 92 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 99 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 25 100 A.1. Changes since draft-ietf-mptcp-architecture-02 . . . . . . 25 101 A.2. Changes since draft-ietf-mptcp-architecture-01 . . . . . . 26 102 A.3. Changes since draft-ietf-mptcp-architecture-00 . . . . . . 26 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 105 1. Introduction 107 As the Internet evolves, demands on Internet resources are ever- 108 increasing, but often these resources (in particular, bandwidth) 109 cannot be fully utilised due to protocol constraints both on the end- 110 systems and within the network. If these resources could instead be 111 used concurrently, end user experience could be greatly improved. 112 Such enhancements would also reduce the necessary expenditure on 113 network infrastructure that would otherwise be needed to create an 114 equivalent improvement in user experience. 116 By the application of resource pooling[3], these available resources 117 can be 'pooled' such that they appear as a single logical resource to 118 the user. The purpose of a multipath transport, therefore, is to 119 make use of multiple available paths, through resource pooling, to 120 bring two key benefits: 122 o To increase the resilience of the connectivity by providing 123 multiple paths, protecting end hosts from the failure of one. 125 o To increase the efficiency of the resource usage, and thus 126 increase the network capacity available to end hosts. 128 Multipath TCP is a modified version of TCP[1] that implements a 129 multipath transport and achieves these goals by pooling multiple 130 paths within a transport connection, transparently to the 131 application. MPTCP, defined in [4], is a specific protocol that 132 instantiates the Multipath TCP concept. This document looks both at 133 general architectural principles for a Multipath TCP fulfilling the 134 goals described in Section 2, as well as the key design decisions 135 behind MPTCP, which are detailed in Section 5. 137 Although multihoming and multipath functions are not new to transport 138 protocols (SCTP [5] being a notable example), MPTCP aims to gain 139 wide-scale deployment by recognising the importance of application 140 and network compatibility goals. These goals, discussed in detail in 141 Section 2, relate to the appearance of MPTCP to the network (so non- 142 MPTCP-aware entities see it as TCP) and to the application (through 143 providing an equivalent service to TCP to non-MPTCP-aware 144 applications). 146 This document has three key purposes: (i) it describes goals for a 147 multipath transport - goals that MPTCP is designed to meet; (ii) it 148 lays out an architectural basis for MPTCP's design - a discussion 149 that applies to other multipath transports as well; and (iii) it 150 discusses and documents high-level design decisions made in MPTCP's 151 development, and considers their implications. 153 Companion documents to this architectural overview are those which 154 provide details of the protocol extensions[4], congestion control 155 algorithms[6], and application-level considerations[7]. Put 156 together, these components specify a complete Multipath TCP design. 157 We note that specific components are replaceable in accordance with 158 the layer and functional decompositions discussed in this document. 160 1.1. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [2]. 166 1.2. Terminology 168 Path: A sequence of links between a sender and a receiver, defined 169 in this context by a source and destination address pair. 171 Path Identifier: Within the context of a multi-addressed multipath 172 TCP, a path is defined by the source and destination (address, 173 port) pairs (i.e. a 4-tuple). 175 Host: An end host either initiating or terminating a Multipath TCP 176 connection. 178 Multipath TCP: A modified version of the TCP [1] protocol that 179 supports the simultaneous use of multiple paths between hosts. 181 MPTCP: The proposed protocol extensions specified in [4] to provide 182 a Multipath TCP implementation. 184 Subflow: A flow of TCP packets operating over an individual path, 185 which forms part of a larger Multipath TCP connection. 187 (Multipath TCP) Connection: A set of one or more subflows combined 188 to provide a single Multipath TCP service to an application at a 189 host. 191 1.3. Reference Scenario 193 The diagram shown in Figure 1 illustrates a typical usage scenario 194 for Multipath TCP. Two hosts, A and B, are communicating with each 195 other. These hosts are multi-homed and multi-addressed, providing 196 two disjoint connections to the Internet. The addresses on each host 197 are referred to as A1, A2, B1 and B2. There are therefore up to four 198 different paths between the two hosts: A1-B1, A1-B2, A2-B1, A2-B2. 200 +------+ __________ +------+ 201 | |A1 ______ ( ) ______ B1| | 202 | Host |--/ ( ) \--| Host | 203 | | ( Internet ) | | 204 | A |--\______( )______/--| B | 205 | |A2 (__________) B2| | 206 +------+ +------+ 208 Figure 1: Simple Multipath TCP Usage Scenario 210 The scenario could have any number of addresses (1 or more) on each 211 host, so long as the number of paths available between the two hosts 212 is 2 or more (i.e. num_addr(A) * num_addr(B) > 1). The paths created 213 by these address combinations through the Internet need not be 214 entirely disjoint - shared bottlenecks will be addressed by the 215 Multipath TCP congestion controller. Furthermore, the paths through 216 the Internet may be interrupted by any number of middleboxes 217 including NATs and Firewalls. Finally, although the diagram refers 218 to the Internet, Multipath TCP may be used over any network where 219 there are multiple paths that could be used concurrently. 221 2. Goals 223 This section outlines primary goals that Multipath TCP aims to meet. 224 These are broadly broken down into: functional goals, which steer 225 services and features that Multipath TCP must provide; and 226 compatibility goals, which determine how Multipath TCP should appear 227 to entities that interact with it. 229 2.1. Functional Goals 231 In supporting the use of multiple paths, Multipath TCP has the 232 following two functional goals. 234 o Improve Throughput: Multipath TCP MUST support the concurrent use 235 of multiple paths. To meet the minimum performance incentives for 236 deployment, a Multipath TCP connection over multiple paths SHOULD 237 achieve no lesser throughput than a single TCP connection over the 238 best constituent path. 240 o Improve Resilience: Multipath TCP MUST support the use of multiple 241 paths interchangeably for resilience purposes, by permitting 242 packets to be sent and re-sent on any available path. It follows 243 that, in the worst case, the protocol MUST be no less resilient 244 than regular single-path TCP. 246 As distribution of traffic among available paths and responses to 247 congestion are done in accordance with resource pooling 248 principles[3], a secondary effect of meeting these goals is that 249 widespread use of Multipath TCP over the Internet should optimize 250 overall network utility by shifting load away from congested 251 bottlenecks and by taking advantage of spare capacity wherever 252 possible. 254 Furthermore, Multipath TCP SHOULD feature automatic negotiation of 255 its use. A host supporting Multipath TCP that requires the other 256 host to do so too must be able to detect reliably whether this host 257 does in fact support the required extensions, using them if so, and 258 otherwise automatically falling back to single-path TCP. 260 2.2. Compatibility Goals 262 In addition to the functional goals listed above, a Multipath TCP 263 must meet a number of compatibility goals in order to support 264 deployment in today's Internet. These goals fall into the following 265 categories: 267 2.2.1. Application Compatibility 269 Application compatibility refers to the appearance of Multipath TCP 270 to the application both in terms of the API that can be used and the 271 expected service model that is provided. 273 Multipath TCP MUST follow the same service model as TCP [1]: in- 274 order, reliable, and byte-oriented delivery. Furthermore, a 275 Multipath TCP connection SHOULD provide the application with no worse 276 throughput than it would expect from running a single TCP connection 277 over any one of its available paths. 279 A multipath-capable equivalent of TCP SHOULD retain backward 280 compatibility with existing TCP APIs, so that existing applications 281 can use the newer transport merely by upgrading the operating systems 282 of the end-hosts. This does not preclude the use of an advanced API 283 to permit multipath-aware applications to specify preferences, nor 284 for users to configure their systems in a different way from the 285 default, for example switching on or off the automatic use of 286 multipath extensions. 288 2.2.2. Network Compatibility 290 In the traditional Internet architecture, network devices operate at 291 the network layer and lower layers, with the layers above the network 292 layer instantiated only at the end-hosts. While this architecture, 293 shown in Figure 2, was initially largely adhered to, this layering no 294 longer reflects the "ground truth" in the Internet with the 295 proliferation of middleboxes[8]. Middleboxes routinely interpose on 296 the transport layer; sometimes even completely terminating transport 297 connections, thus leaving the application layer as the first real 298 end-to-end layer, as shown in Figure 3. 300 +-------------+ +-------------+ 301 | Application |<------------ end-to-end ------------->| Application | 302 +-------------+ +-------------+ 303 | Transport |<------------ end-to-end ------------->| Transport | 304 +-------------+ +-------------+ +-------------+ +-------------+ 305 | Network |<->| Network |<->| Network |<->| Network | 306 +-------------+ +-------------+ +-------------+ +-------------+ 307 End Host Router Router End Host 309 Figure 2: Traditional Internet Architecture 311 +-------------+ +-------------+ 312 | Application |<------------ end-to-end ------------->| Application | 313 +-------------+ +-------------+ +-------------+ 314 | Transport |<------------------->| Transport |<->| Transport | 315 +-------------+ +-------------+ +-------------+ +-------------+ 316 | Network |<->| Network |<->| Network |<->| Network | 317 +-------------+ +-------------+ +-------------+ +-------------+ 318 Firewall, 319 End Host Router NAT, or Proxy End Host 321 Figure 3: Internet Reality 323 Middleboxes that interpose on the transport layer result in loss of 324 "fate-sharing"[9], that is, they often hold "hard" state that, when 325 lost or corrupted, results in loss or corruption of the end-to-end 326 transport connection. 328 The network compatibility goal requires that the multipath extension 329 to TCP retains compatibility with the Internet as it exists today, 330 including making reasonable efforts to be able to traverse 331 predominant middleboxes such as firewalls, NATs, and performance 332 enhancing proxies[8]. This requirement comes from recognizing 333 middleboxes as a significant deployment bottleneck for any transport 334 that is not TCP, and constrains Multipath TCP to appear as TCP does 335 on the wire and to use established TCP extensions where necessary. 336 To ensure end-to-endness of the transport, we further require 337 Multipath TCP to preserve fate-sharing without making any assumptions 338 about middlebox behavior. 340 A detailed analysis of middlebox behaviour and the impact on the 341 Multipath TCP architecture is presented in Section 7. In addition, 342 network compatibility must be retained to the extent that Multipath 343 TCP MUST fall back to regular TCP if there are insurmountable 344 incompatibilities for the multipath extension on a path. 346 The modifications to support Multipath TCP remain at the transport 347 layer, although some knowledge of the underlying network layer is 348 required. Multipath TCP SHOULD work with IPv4 and IPv6 349 interchangeably, i.e. one connection may operate over both IPv4 and 350 IPv6 networks. 352 2.2.3. Compatibility with other network users 354 As a corollary to both network and application compatibility, the 355 architecture must enable new Multipath TCP flows to coexist 356 gracefully with existing single-path TCP flows, competing for 357 bandwidth neither unduly aggressively nor unduly timidly (unless low- 358 precedence operation is specifically requested by the application, 359 such as with LEDBAT). The use of multiple paths MUST NOT unduly harm 360 users using single-path TCP at shared bottlenecks, beyond the impact 361 that would occur from another single-path TCP flow. Multiple 362 Multipath TCP flows on a shared bottleneck MUST share bandwidth 363 between each other with similar fairness to that which occurs at a 364 shared bottleneck with single-path TCP. 366 2.3. Security Goals 368 The extension of TCP with multipath capabilities will bring with it a 369 number of new threats, analysed in detail in [10]. The security goal 370 for Multipath TCP is to provide a service no less secure than 371 regular, single-path TCP. This will be achieved through a 372 combination of existing TCP security mechanisms (potentially modified 373 to align with the Multipath TCP extensions) and of protection against 374 the new multipath threats identified. The design decisions derived 375 from this goal are presented in Section 5.8. 377 2.4. Related Protocols 379 There are several similarities between SCTP [5] and MPTCP, in that 380 both can make use of multiple addresses at end hosts to give some 381 multi-path capability. In SCTP, the primary use case is to support 382 redundancy and mobility for multihomed hosts (i.e. a single path will 383 change one of its end host addresses); the simultaneous use of 384 multiple paths is not supported . Extensions are proposed to support 385 simultaneous multipath transport [11], but these are yet to be 386 standardised. The de facto standard stream-based transport protocol 387 is, however, TCP [1], and SCTP does not meet the network and 388 application compatibility goals specified in Section 2.2. For 389 network compatibility, there are issues with various middleboxes 390 (especially NATs) that are unaware of SCTP and consequently end up 391 blocking it. For application compatibility, applications need to 392 actively choose to use SCTP, and with the deployment issues very few 393 choose to do so. MPTCP's compatibility goals are in part based on 394 these observations of SCTP's deployment issues. 396 3. An Architectural Basis For Multipath TCP 398 We now present one possible transport architecture that we believe 399 can effectively support the goals for Multipath TCP. The new 400 Internet model described here is based on ideas proposed earlier in 401 Tng ("Transport next-generation") [12]. While by no means the only 402 possible architecture supporting multipath transport, Tng 403 incorporates many lessons learned from previous transport research 404 and development practice, and offers a strong starting point from 405 which to consider the extant Internet architecture and its bearing on 406 the design of any new Internet transports or transport extensions. 408 +------------------+ 409 | Application | 410 +------------------+ ^ Application-oriented transport 411 | | | functions (Semantic Layer) 412 + - - Transport - -+ ---------------------------------- 413 | | | Network-oriented transport 414 +------------------+ v functions (Flow+Endpoint Layer) 415 | Network | 416 +------------------+ 417 Existing Layers Tng Decomposition 419 Figure 4: Decomposition of Transport Functions 421 Tng loosely splits the transport layer into "application-oriented" 422 and "network-oriented" layers, as shown in Figure 4. The 423 application-oriented "Semantic" layer implements functions driven 424 primarily by concerns of supporting and protecting the application's 425 end-to-end communication, while the network-oriented "Flow+Endpoint" 426 layer implements functions such as endpoint identification (using 427 port numbers) and congestion control. These network-oriented 428 functions, while traditionally located in the ostensibly "end-to-end" 429 Transport layer, have proven in practice to be of great concern to 430 network operators and the middleboxes they deploy in the network to 431 enforce network usage policies[13] [14] or optimize communication 432 performance[15]. Figure 5 shows how middleboxes interact with 433 different layers in this decomposed model of the transport layer: the 434 application-oriented layer operates end-to-end, while the network- 435 oriented layer operates "segment-by-segment" and can be interposed 436 upon by middleboxes. 438 +-------------+ +-------------+ 439 | Application |<------------ end-to-end ------------->| Application | 440 +-------------+ +-------------+ 441 | Semantic |<------------ end-to-end ------------->| Semantic | 442 +-------------+ +-------------+ +-------------+ +-------------+ 443 |Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint|<->|Flow+Endpoint| 444 +-------------+ +-------------+ +-------------+ +-------------+ 445 | Network |<->| Network |<->| Network |<->| Network | 446 +-------------+ +-------------+ +-------------+ +-------------+ 447 Firewall Performance 448 End Host or NAT Enhancing Proxy End Host 450 Figure 5: Middleboxes in the new Internet model 452 MPTCP's architectural design follows Tng's decomposition as shown in 453 Figure 6. MPTCP, which provides application compatibility through 454 the preservation of TCP-like semantics of global ordering of 455 application data and reliability, is an instantiation of the 456 "application-oriented" Semantic layer; whereas the subflow TCP 457 component, which provides network compatibility by appearing and 458 behaving as a TCP flow in network, is an instantiation of the 459 "network-oriented" Flow+Endpoint layer. 461 +--------------------------+ +-------------------------------+ 462 | Application | | Application | 463 +--------------------------+ +-------------------------------+ 464 | Semantic | | MPTCP | 465 |------------+-------------| + - - - - - - - + - - - - - - - + 466 | Flow+Endpt | Flow+Endpt | | Subflow (TCP) | Subflow (TCP) | 467 +------------+-------------+ +---------------+---------------+ 468 | Network | Network | | IP | IP | 469 +------------+-------------+ +---------------+---------------+ 471 Figure 6: Relationship between Tng (left) and MPTCP (right) 473 As a protocol extension to TCP, MPTCP thus explicitly acknowledges 474 middleboxes in its design, and specifies a protocol that operates at 475 two scales: the MPTCP component operates end-to-end, while it allows 476 the TCP component to operate segment-by-segment. 478 4. A Functional Decomposition of MPTCP 480 The previous two sections have discussed the goals for a Multipath 481 TCP design, and provided a basis for decomposing the functions of a 482 transport protocol in order to better understand the form a solution 483 should take. This section builds upon this analysis by presenting 484 the functional components that are used within the MPTCP design. 486 MPTCP makes use of (what appear to the network to be) standard TCP 487 sessions, termed "subflows", to provide the underlying transport per 488 path, and as such these retain the network compatibility desired. 489 MPTCP-specific information is carried in a TCP-compatible manner, 490 although this mechanism is separate from the actual information being 491 transferred so could evolve in future revisions. Figure 7 492 illustrates the layered architecture. 494 +-------------------------------+ 495 | Application | 496 +---------------+ +-------------------------------+ 497 | Application | | MPTCP | 498 +---------------+ + - - - - - - - + - - - - - - - + 499 | TCP | | Subflow (TCP) | Subflow (TCP) | 500 +---------------+ +-------------------------------+ 501 | IP | | IP | IP | 502 +---------------+ +-------------------------------+ 504 Figure 7: Comparison of Standard TCP and MPTCP Protocol Stacks 506 Situated below the application, the MPTCP extension in turn manages 507 multiple TCP subflows below it. In order to do this, it must 508 implement the following functions: 510 o Path Management: This is the function to detect and use multiple 511 paths between two hosts. MPTCP uses the presence of multiple IP 512 addresses at one or both of the hosts as an indicator of this. 513 The path management features of the MPTCP protocol are the 514 mechanisms to signal alternative addresses to hosts, and 515 mechanisms to set up new subflows joined to an existing MPTCP 516 connection. 518 o Packet Scheduling: This function breaks the bytestream received 519 from the application into segments to be transmitted on one of the 520 available subflows. The MPTCP design makes use of a data sequence 521 mapping, associating segments sent on different subflows to a 522 connection-level sequence numbering, thus allowing segments sent 523 on different subflows to be correctly re-ordered at the receiver. 524 The packet scheduler is dependent upon information about the 525 availability of paths exposed by the path management component, 526 and then makes use of the subflows to transmit queued segments. 527 This function is also responsible for connection-level re-ordering 528 on receipt of packets from the TCP subflows, according to the 529 attached data sequence mappings. 531 o Subflow (single-path TCP) Interface: A subflow component takes 532 segments from the packet-scheduling component and transmits them 533 over the specified path, ensuring detectable delivery to the host. 535 MPTCP uses TCP underneath for network compatibility; TCP ensures 536 in-order, reliable delivery. TCP adds its own sequence numbers to 537 the segments; these are used to detect and retransmit lost packets 538 at the subflow layer. On receipt, the subflow passes its 539 reassembled data to the packet scheduling component for 540 connection-level reassembly; the data sequence mapping from the 541 sender's packet scheduling component allows re-ordering of the 542 entire bytestream. 544 o Congestion Control: This function coordinates congestion control 545 across the subflows. As specified, this congestion control 546 algorithm MUST ensure that a MPTCP connection does not unfairly 547 take more bandwidth than a single path TCP flow would take at a 548 shared bottlneck. An algorithm to support this is specified in 549 [6]. 551 These functions fit together as follows. The Path Management looks 552 after the discovery (and if necessary, initialisation) of multiple 553 paths between two hosts. The Packet Scheduler then receives a stream 554 of data from the application destined for the network, and undertakes 555 the necessary operations on it (such as segmenting the data into 556 connection-level segments, and adding a connection-level sequence 557 number) before sending it on to a subflow. The subflow then adds its 558 own sequence number, acks, and passes them to network. The receiving 559 subflow re-orders data (if necessary) and passes it to the packet 560 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 packets 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 packet 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 (carying 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 permissable 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 packet 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 packets after acknowledgement on the subflow but 644 before delivery to the application, and this can be facilitated by a 645 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, MPTCP 662 SHOULD feature explicit connection-level acknowledgements, in 663 addition to subflow-level acknowledgements. A connection-level 664 acknowledgement would only be required in order to signal when the 665 receive window moves forward; the heuristics for using such a signal 666 are discussed in more detail in the protocol specification [4]. 668 Regarding retransmissions, it MUST be possible for a packet to be 669 retransmitted on a different subflow to that on which it was 670 originally sent. This is one of MPTCP's core goals, in order to 671 maintain integrity during temporary or permanent subflow failure, and 672 this is enabled by the dual sequence number space. 674 The scheduling of retransmissions will have significant impact on 675 MPTCP user experience. The current MPTCP specification suggests that 676 data outstanding on subflows that have timed out should be 677 rescheduled for transmission on different subflows. This behaviour 678 aims to minimize disruption when a path breaks, and uses the first 679 timeout as indicators. More conservative versions would be to use 680 second or third timeouts for the same packet. 682 Typically, fast retransmit on an individual subflow will not trigger 683 retransmission on another subflow, although this may still be 684 desirable in certain cases, for instance to reduce the receive buffer 685 requirements. However, in all cases with retransmissions on 686 different subflows, the lost packets SHOULD still be sent on the path 687 that lost them. This is currently believed to be necessary to 688 maintain subflow integrity, as per the network compatiblity goal. By 689 doing this, throughput will be wasted, and it is unclear at this 690 point what the optimal retransmit strategy is. 692 Large-scale experiments are therefore required in order to determine 693 the most appropriate retransmission strategy, and recommendations 694 will be refined once more information is available. 696 5.3. Buffers 698 To ensure in-order delivery, MPTCP must use a connection level 699 receive buffer, where segments are placed until they are in order and 700 can be read by the application. 702 In regular, single-path TCP, it is usually recommended to set the 703 receive buffer to 2*BDP (Bandwidth-Delay Product, i.e. BDP = BW*RTT, 704 where BW = Bandwidth and RTT = Round-Trip Time). One BDP allows 705 supporting reordering of segments by the network. The other BDP 706 allows the connection to continue during fast retransmit: when a 707 segment is fast retransmitted, the receiver must be able to store 708 incoming data during one more RTT. 710 For MPTCP, the story is a bit more complicated. The ultimate goal is 711 that a subflow packet loss or subflow failure should not affect the 712 throughput of other working subflows; the receiver should have enough 713 buffering to store all data until the missing packet is re- 714 transmitted and reaches the destination. 716 The worst case scenario would be when the subflow with the highest 717 RTT/RTO (Round-Trip Time or Retransmission TimeOut) experiences a 718 timeout; in that case the receiver has to buffer data from all 719 subflows for the duration of the RTO. Thus, the smallest connection- 720 level receive buffer that would be needed to avoid stalling with 721 subflow failures is sum(BW_i)*RTO_max, where BW_i = Bandwidth for 722 each subflow and RTO_max is the largest RTO across all subflows. 724 This is an order of magnitude more than the receive buffer required 725 for a single connection, and is probably too expensive for practical 726 purposes. A more sensible requirement is to avoid stalls in the 727 absence of timeouts. Therefore, the RECOMMENDED receive buffer is 728 2*sum(BW_i)*RTT_max, where RTT_max is the largest RTT across all 729 subflows. This buffer sizing ensures subflows do not stall when fast 730 retransmit is triggered on any subflow. 732 The resulting buffer size should be small enough for practical use. 733 However, there may be extreme cases where fast, high throughput paths 734 (e.g. 100Mb/s, 10ms RTT) are used in conjunction with slow paths 735 (e.g. 1Mb/s, 1000ms RTT). In that case the required receive buffer 736 would be 12.5MB, which is likely too big. In these cases a Multipath 737 TCP scheduler SHOULD use only the fast path, potentially falling back 738 to the slow path if the fast path fails. 740 Send Buffer: The RECOMMENDED send buffer is the same size as the 741 recommended receive buffer i.e., 2*sum(BW_i)*RTT_max. This is 742 because the sender must store locally the segments sent but 743 unacknowledged by the connection level ACK. The send buffer size 744 matters particularly for hosts that maintain a large number of 745 ongoing connections. If the required send buffer is too large, a 746 host can choose to only send data on the fast subflows, using the 747 slow subflows only in cases of failure. 749 5.4. Signalling 751 Since MPTCP uses TCP as its subflow transport mechanism, a MPTCP 752 connection will also begin as a single TCP connection. Nevertheless, 753 it must signal to the peer that it supports MPTCP and wishes to use 754 it on this connection. As such, a TCP Option will be used to 755 transmit this information, since this is the established mechanism 756 for indicating additional functionality on a TCP session. 758 In addition, further signalling is required during the operation of a 759 MPTCP session, such as that for reassembly for multiple subflows, and 760 for informing the other host about potential other available 761 addresses. 763 The MPTCP protocol design will, however, use TCP Options for this 764 additional signalling. This has been chosen as the mechanism most 765 fitting in with the goals as specified in Section 2. With this 766 mechanism, the signalling requires to operate MPTCP is transported 767 separately from the data, allowing it to be created and processed 768 separately from the data stream, and retaining architectural 769 compatibility with network entities. 771 This decision is the consensus of the Working Group (following 772 detailed discussions at IETF78), and the main reasons for this are as 773 follows: 775 o TCP options are the traditional signalling method for TCP; 776 o A TCP option on a SYN is the most compatible way for an end host 777 to signal it is MPTCP-capable; 779 o If connection-level ACKs are signalled in the payload then they 780 may suffer from packet loss and may be congestion-controlled, 781 which may affect the data throughput in the forward direction and 782 could lead to head-of-line blocking; 784 o Middleboxes, such as NAT traversal helpers, can easily parse TCP 785 options, e. g., to rewrite addresses. 787 On the other hand, the main drawbacks of TCP options compared to TLV 788 encoding in the payload are: 790 o There is limited space for signalling messages; 792 o A middlebox may, potentially, drop a packet with an unknown 793 option; 795 o The transport of control information in options is not necessarily 796 reliable. 798 The detailed design of MPTCP alleviates these issues as far as 799 possible by carefully considering the size of MPTCP options, and 800 seamlessly falling back to regular TCP on the loss of control data. 802 Both option and payload encoding may interfere with offloading of TCP 803 processing to high speed network interface cards, such as 804 segmentation, checksumming, and reassembly. For network cards 805 supporting MPTCP, signalling in TCP options should simplify 806 offloading due to the separate handling of MPTCP signalling and data. 808 5.5. Path Management 810 Currently, the network does not expose multiple paths between hosts. 811 In the typical case, MPTCP uses multiple addresses at one or both 812 hosts to infer different paths across the network. It is expected 813 that these paths, whilst not necesarily entirely non-overlapping, 814 will be sufficiently disjoint to allow multipath to achieve improved 815 throughput and robustness. The use of multiple IP addresses is a 816 simple mechanism that requires no additional features in the network. 818 Multiple different (source, destination) address pairs will thus be 819 used as path selectors in most cases. Each path will be identified 820 by a TCP 4-tuple (i.e. source address, destination address, source 821 port, destination port), however, which can allow the extension of 822 MPTCP to use such 4-tuples as path selectors. This will allow hosts 823 to use MPTCP to load balance to different ports, for example if the 824 network routes different ports over different paths (which may be the 825 case with technologies such as Equal Cost MultiPath (ECMP) routing 826 [16]). 828 For increased chance of successfully setting up additional subflows 829 (such as when one end is behind a firewall, NAT, or other restrictive 830 middlebox), either host SHOULD be able to add new subflows to a MPTCP 831 connection. MPTCP MUST be able to handle paths that appear and 832 disappear during the lifetime of a connection (for example, through 833 the activation of an additional network interface). 835 The modularity of path management will permit alternative mechanisms 836 to be employed if appropriate in the future. 838 5.6. Connection Identification 840 Since a MPTCP connection may not be bound to a traditional 5-tuple 841 (source address and port, destination address and port, protocol 842 number) for the entirety of its existence, it is desirable to provide 843 a new mechanism for connection identification. This will be useful 844 for MPTCP-aware applications, and for the MPTCP implementation (and 845 MPTCP-aware middleboxes) to have a unique identifier with which to 846 associate the multiple subflows. 848 Therefore, each MPTCP connection requires a connection identifier at 849 each host, which is locally unique within that host. In many ways, 850 this is analogous to a port number in regular TCP. The manifestation 851 and purpose of such an identifier is out of the scope of this 852 architecture document. 854 Legacy applications will not, however, have access to this identifier 855 and in such cases a MPTCP connection will be identified by the 856 5-tuple of the first TCP subflow. It is out of the scope of this 857 document, however, to define the behaviour of the MPTCP 858 implementation if the first TCP subflow later fails. If there are 859 MPTCP-unaware applications that make assumptions about continued 860 existence of the initial address pair, their behaviour could be 861 disrupted by carrying on regardless. It is expected that this is a 862 very small, possibly negligible, set of applications, however. In 863 the case of applications that have used an existing API call to bind 864 to a specific address or interface, the MPTCP extension MUST NOT be 865 used, since the applications are indicating a clear choice of path to 866 use and thus will have expectations of behaviour that must be 867 maintained, in order to adhere to the application compatibility 868 goals. 870 Since the requirements of applications are not clear at this stage, 871 however, it is as yet unconfirmed what the best behaviour is. It 872 will be an implementation-specific solution, however, and as such the 873 behaviour is expected to be chosen by implementors once more research 874 has been undertaken to determine its impact. 876 5.7. Congestion Control 878 As discussed in network-layer compatibility requirements 879 Section 2.2.3, there are three goals for the congestion control 880 algorithms used by a MPTCP implementation: improve throughput (at 881 least as well as a single-path TCP connection would perform); do no 882 harm to other network users (do not take up more capacity on any one 883 path than if it was a single path flow using only that route - this 884 is particularly relevant for shared bottlenecks); and balance 885 congestion by moving traffic away from the most congested paths. To 886 achieve these goals, the congestion control algorithms on each 887 subflow must be coupled in some way. A proposal for a suitable 888 congestion control algorithm is given in [6]. 890 5.8. Security 892 A detailed threat analysis for Multipath TCP is presented in a 893 separate document [10]. This focuses on flooding attacks and 894 hijacking attacks that can be launched against a Multipath TCP 895 connection. 897 The basic security goal of Multipath TCP, as introduced in 898 Section 2.3, can be stated as: "provide a solution that is no worse 899 than standard TCP". 901 From the threat analysis, and with this goal in mind, three key 902 security requirements can be identified. A multi-addressed Multipath 903 TCP SHOULD be able to: 905 o Provide a mechanism to confirm that the parties in a subflow 906 handshake are the same as in the original connection setup (e.g. 907 require use of a key exchanged in the initial handshake in the 908 subflow handshake, to limit the scope for hijacking attacks). 910 o Provide verification that the peer can receive traffic at a new 911 address before adding it (i.e. verify that the address belongs to 912 the other host, to prevent flooding attacks). 914 o Provide replay protection, i.e. ensure that a request to add/ 915 remove a subflow is 'fresh'. 917 Additional mechanisms have been deployed as part of standard TCP 918 stacks to provide resistance to Denial-of-Service attacks. For 919 example, there are various mechanisms to protect against TCP reset 920 attacks [17], and Multipath TCP should continue to support similar 921 protection. In addition, TCP SYN Cookies [18] were developed to 922 allow a TCP server to defer the creation of session state in the 923 SYN_RCVD state, and remain stateless until the ESTABLISHED state had 924 been reached. Multipath TCP should, ideally, continue to provide 925 such functionality and, at a minimum, avoid significant computational 926 burden prior to reaching the ESTABLISHED state (of the Multipath TCP 927 connection as a whole). 929 It should be noted that aspects of the Multipath TCP design space 930 place constraints on the security solution: 932 o The use of TCP options significantly limits the amount of 933 information that can be carried in the handshake. 935 o The need to work through middleboxes results in the need to handle 936 mutability of packets. 938 o The desire to support a 'break-before-make' (as well as a 'make- 939 before-break') approach to adding subflows implies that a host 940 cannot rely on using a pre-existing subflow to support the 941 addition of a new one. 943 The MPTCP protocol will be designed with these security requirements 944 in mind, and the protocol specification [4] will document how these 945 are met. 947 6. Interactions with Applications 949 Interactions with applications are presented in [7] - including, but 950 not limited to, performances changes that may be expected, semantic 951 changes, and new features that may be requested through an enhanced 952 API. 954 7. Interactions with Middleboxes 956 As discussed in Section 2.2, it is a goal of MPTCP to be deployable 957 today and thus compatible with the majority of middleboxes. This 958 section summarises the issues that may arise with NATs, firewalls, 959 proxies, intrusion detection systems, and other middleboxes that, if 960 not considered in the protocol design, may hinder its deployment. 962 This section is intended primarily as a description of options and 963 considerations only. Protocol-specific solutions to these issues 964 will be given in the companion documents. 966 Multipath TCP will be deployed in a network that no longer provides 967 just basic datagram delivery. A miriad of middleboxes are deployed 968 to optimize various perceived problems with the Internet protocols: 969 NATs primarily address space shortage [13], Performance Enhancing 970 Proxies (PEPs) optimize TCP for different link characteristics [15], 971 firewalls [14] and intrusion detection systems try to block malicious 972 content from reaching a host, and traffic normalizers [19] ensure a 973 consistent view of the traffic stream to Intrusion Detection Systems 974 (IDS) and hosts. 976 All these middleboxes optimize current applications at the expense of 977 future applications. In effect, future applications will often need 978 to behave in a similar fashion to existing ones, in order to increase 979 the chances of successful deployment. Further, the precise behaviour 980 of all these middleboxes is not clearly specified, and implementation 981 errors make matters worse, raising the bar for the deployment of new 982 technologies. 984 The following list of middlebox classes documents behaviour that 985 could impact the use of MPTCP. This list is used in [4] to describe 986 the features of the MPTCP protocol that are used to mitigate the 987 impact of these middlebox behaviours. 989 o NATs: Network Address Translators decouple the host's local IP 990 address (and, in the case of NAPTs, port) with that which is seen 991 in the wider Internet when the packets are transmitted through a 992 NAT. This adds complexity, and reduces the chances of success, 993 when signalling IP addresses. 995 o PEPs: Performance Enhancing Proxies, which aim to improve the 996 performance of protocols over low-performance (e.g. high latency 997 or high error rate) links. As such, they may "split" a TCP 998 connection and behaviour such as proactive ACKing may occur, and 999 therefore it is no longer guaranteed that one host is 1000 communicating directly with another. PEPs, firewalls or other 1001 middleboxes may also change the declared receive window size. 1003 o Traffic Normalizers: These aim to eliminate ambiguities and 1004 potential attacks at the network level, and amongst other things 1005 are unlikely to permit holes in TCP-level sequence space (which 1006 has impact on MPTCP's retransmission and subflow sequence 1007 numbering design choices). 1009 o Firewalls: on top of preventing incoming connections, firewalls 1010 may also attempt additional protection such as sequence number 1011 randomization (so a sender cannot reliably know what TCP sequence 1012 number the receiver will see). 1014 o Intrusion Detection Systems: IDSs may look for traffic patterns to 1015 protect a network, and may have false positives with MPTCP and 1016 drop the connections during normal operation. Future MPTCP-aware 1017 middleboxes will require the ability to correlate the various 1018 paths in use. 1020 o Content-aware Firewalls: Some middleboxes may actively change data 1021 in packets, such as re-writing URIs in HTTP traffic. 1023 In addition, all classes of middleboxes may affect TCP traffic in the 1024 following ways: 1026 o TCP Options: some middleboxes may drop packets with unknown TCP 1027 options, or strip those options from the packets. 1029 o Segmentation and Colescing: middleboxes (or even something as 1030 close to the end host as TCP Segmentation Offloading (TSO) on a 1031 Network Interface Card (NIC)) may change the packet boundaries 1032 from those which the sender intended. It may do this by splitting 1033 packets, or coalescing them together. This leads to two major 1034 impacts: we cannot guarantee where a packet boundary will be, and 1035 we cannot say for sure what a middlebox will do with TCP options 1036 in these cases (they may be repeated, dropped, or sent only once). 1038 8. Contributors 1040 The authors would like to acknowledge the contributions of Andrew 1041 McDonald and Bryan Ford to this document. 1043 The authors would also like to thank the following people for 1044 detailed reviews: Olivier Bonaventure, Gorry Fairhurst, Iljitsch van 1045 Beijnum, Philip Eardley, and Michael Scharf. 1047 9. Acknowledgements 1049 Alan Ford, Costin Raiciu, Mark Handley, and Sebastien Barre are 1050 supported by Trilogy (http://www.trilogy-project.org), a research 1051 project (ICT-216372) partially funded by the European Community under 1052 its Seventh Framework Program. The views expressed here are those of 1053 the author(s) only. The European Commission is not liable for any 1054 use that may be made of the information in this document. 1056 10. IANA Considerations 1058 None. 1060 11. Security Considerations 1062 This informational document provides an architectural overview for 1063 Multipath TCP and so does not, in itself, raise any security issues. 1064 A separate threat analysis [10] lists threats that can exist with a 1065 Multipath TCP. However, a protocol based on the architecture in this 1066 document will have a number of security requirements. The high level 1067 goals for such a protocol are identified in Section 2.3, whilst 1068 Section 5.8 provides more detailed discussion of security 1069 requirements and design decisions which are applied in the MPTCP 1070 protocol design [4]. 1072 12. References 1074 12.1. Normative References 1076 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1077 September 1981. 1079 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1080 Levels", BCP 14, RFC 2119, March 1997. 1082 12.2. Informative References 1084 [3] Wischik, D., Handley, M., and M. Bagnulo Braun, "The Resource 1085 Pooling Principle", ACM SIGCOMM CCR vol. 38 num. 5, pp. 47-52, 1086 October 2008, 1087 . 1089 [4] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for 1090 Multipath Operation with Multiple Addresses", 1091 draft-ietf-mptcp-multiaddressed-02 (work in progress), 1092 October 2010. 1094 [5] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 1095 September 2007. 1097 [6] Raiciu, C., Handley, M., and D. Wischik, "Coupled Multipath- 1098 Aware Congestion Control", draft-ietf-mptcp-congestion-00 (work 1099 in progress), July 2010. 1101 [7] Scharf, M. and A. Ford, "MPTCP Application Interface 1102 Considerations", draft-ietf-mptcp-api-00 (work in progress), 1103 November 2010. 1105 [8] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", 1106 RFC 3234, February 2002. 1108 [9] Carpenter, B., "Internet Transparency", RFC 2775, 1109 February 2000. 1111 [10] Bagnulo, M., "Threat Analysis for Multi-addressed/Multi-path 1112 TCP", draft-ietf-mptcp-threat-06 (work in progress), 1113 December 2010. 1115 [11] Becke, M., Dreibholz, T., Iyengar, J., Natarajan, P., and M. 1116 Tuexen, "Load Sharing for the Stream Control Transmission 1117 Protocol (SCTP)", draft-tuexen-tsvwg-sctp-multipath-00 (work in 1118 progress), July 2010. 1120 [12] Ford, B. and J. Iyengar, "Breaking Up the Transport Logjam", 1121 ACM HotNets, October 2008. 1123 [13] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1124 Translator (Traditional NAT)", RFC 3022, January 2001. 1126 [14] Freed, N., "Behavior of and Requirements for Internet 1127 Firewalls", RFC 2979, October 2000. 1129 [15] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1130 Shelby, "Performance Enhancing Proxies Intended to Mitigate 1131 Link-Related Degradations", RFC 3135, June 2001. 1133 [16] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", 1134 RFC 2992, November 2000. 1136 [17] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 1137 Robustness to Blind In-Window Attacks", RFC 5961, August 2010. 1139 [18] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", 1140 RFC 4987, August 2007. 1142 [19] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion 1143 Detection: Evasion, Traffic Normalization, and End-to-End 1144 Protocol Semantics", Usenix Security 2001, 2001, . 1147 Appendix A. Changelog 1149 (For removal by the RFC Editor) 1151 A.1. Changes since draft-ietf-mptcp-architecture-02 1152 o Responded to WG last call review comments. Included editorial 1153 fixes, adding Section 2.4, and improving Section 5.4 and 1154 Section 7. 1156 A.2. Changes since draft-ietf-mptcp-architecture-01 1158 o Responded to review comments. 1160 o Added security sections. 1162 A.3. Changes since draft-ietf-mptcp-architecture-00 1164 o Added middlebox compatibility discussion (Section 7). 1166 o Clarified path identification (TCP 4-tuple) in Section 5.5. 1168 o Added brief scenario and diagram to Section 1.3. 1170 Authors' Addresses 1172 Alan Ford (editor) 1173 Roke Manor Research 1174 Old Salisbury Lane 1175 Romsey, Hampshire SO51 0ZN 1176 UK 1178 Phone: +44 1794 833 465 1179 Email: alan.ford@roke.co.uk 1181 Costin Raiciu 1182 University College London 1183 Gower Street 1184 London WC1E 6BT 1185 UK 1187 Email: c.raiciu@cs.ucl.ac.uk 1189 Mark Handley 1190 University College London 1191 Gower Street 1192 London WC1E 6BT 1193 UK 1195 Email: m.handley@cs.ucl.ac.uk 1196 Sebastien Barre 1197 Universite catholique de Louvain 1198 Pl. Ste Barbe, 2 1199 Louvain-la-Neuve 1348 1200 Belgium 1202 Phone: +32 10 47 91 03 1203 Email: sebastien.barre@uclouvain.be 1205 Janardhan Iyengar 1206 Franklin and Marshall College 1207 Mathematics and Computer Science 1208 PO Box 3003 1209 Lancaster, PA 17604-3003 1210 USA 1212 Phone: 717-358-4774 1213 Email: jiyengar@fandm.edu