idnits 2.17.1 draft-iyengar-ford-tng-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (July 6, 2009) is 5379 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1644 (Obsoleted by RFC 6247) ** Obsolete normative reference: RFC 2140 (Obsoleted by RFC 9040) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-03) exists of draft-ford-mptcp-multiaddressed-00 Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Iyengar 3 Internet-Draft Franklin and Marshall College 4 Intended status: Informational B. Ford 5 Expires: January 7, 2010 Max Planck Institute for Software 6 Systems 7 July 6, 2009 9 A Next Generation Transport Services Architecture 10 draft-iyengar-ford-tng-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 While there is substantial community interest in next-generation 49 multipath-capable Internet transports, evolutionary pressures have 50 gradually eroded the simplicity of the Internet's original transport 51 architecture to a point where it is no longer realistically 52 applicable to new tranports. This document proposes a new 53 architectural framework for next-generation multipath-capable 54 transport protocols, focusing immediately on multipath TCP but taking 55 care to allow for generalization to other multipath-capable 56 transports. The architecture places emphasis on enabling new 57 multipath features in a safe, TCP-friendly, and backward-compatible 58 fashion, retaining full interoperability with both existing 59 applications and existing network infrastructure, and enabling reuse 60 of existing protocols as much as possible while providing incremental 61 deployment paths to new, more powerful and/or more efficient 62 protocols. The architecture re-establishes the long-lost principles 63 of end-to-end reliability and fate sharing, in the presence of 64 existing and future network middleboxes, and enables the deployment 65 of transport-neutral end-to-end protection without interfering with 66 these policy-enforcing or performance-enhancing middleboxes. This 67 document describes architecture goals, a layering model supporting 68 these goals, abstract properties of the interfaces between the 69 architecture's new layers, general approaches to multipath congestion 70 control and how they fit into the architecture, realistic protocol 71 design and incremental deployment paths, and ways in which this 72 document complements and relates to ongoing protocol design 73 activities in the IETF. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Architecture Goals . . . . . . . . . . . . . . . . . . . . . . 5 79 2.1. Functional Goals . . . . . . . . . . . . . . . . . . . . . 6 80 2.2. Performance/Efficiency Goals . . . . . . . . . . . . . . . 7 81 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 8 82 3.1. Addressing Operational Concerns . . . . . . . . . . . . . 9 83 3.2. Endpoint Layer . . . . . . . . . . . . . . . . . . . . . . 12 84 3.3. The Flow Regulation Layer . . . . . . . . . . . . . . . . 13 85 3.4. The Isolation Layer . . . . . . . . . . . . . . . . . . . 14 86 3.5. The Semantic Layer . . . . . . . . . . . . . . . . . . . . 15 87 4. Multipath Congestion Control . . . . . . . . . . . . . . . . . 15 88 5. Protocol Implementation and Incremental Deployment Paths . . . 17 89 6. How Tng Complements Current Projects . . . . . . . . . . . . . 20 90 7. Experiences with Running Code . . . . . . . . . . . . . . . . 22 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 96 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 99 1. Introduction 101 While there is substantial community interest in developing next- 102 generation Internet transports supporting concurrent multipath 103 communication and other new features, the Internet's evolution over 104 the past decades have left us in a situation in which the Internet's 105 traditional transport architecture is not well-suited to support new 106 transports in general, or multipath transports in particular. This 107 document attempts to address this problem by defining a new 108 conceptual framework for Internet transports, which is both 109 compatible with the pragmatic reality of the Internet today and the 110 backward compatibility constraints new transports must face, while 111 effectively enabling the deployment of compelling new features and 112 the further long-term evolution of Internet transports. 114 The Internet's transport layer traditionally combines many functions, 115 whose combination in one layer has led to numerous pragmatic 116 challenges to transport evolution. Concurrent multipath transport 117 requires decoupling congestion control state from application-visible 118 transport instances and associating one transport instance with 119 multiple per-path congestion control contexts [iyengar06concurrent]. 120 Avoiding an explosion in congestion control contexts in the presence 121 of applications like HTTP [RFC2616], which frequently use multiple 122 transport instances in parallel, similarly requires decoupling and 123 sharing congestion control contexts among transport instances 124 [RFC2140] [RFC3124]. 126 Some transport functions have pragmatically proven to be of concern 127 to network operators and the policy-enforcing and performance- 128 enhancing devices they now frequently deploy within the network, 129 despite the the transport's original role as a purely "end-to-end" 130 layer. For example, already-ubiquitous firewalls [RFC2979], NATs 131 [RFC3022], and flow-aware routers [roberts03next] need access to 132 transport layer port numbers to enforce application-sensitive access 133 and traffic management policies, and performance enhancing proxies 134 (PEPs) [RFC3135] need to interact with the transport's congestion 135 control mechanisms [RFC2581] to optimize communication performance 136 across diverse network technologies such as high-speed [RFC3649] and 137 wireless [balakrishnan97comparison] links. Middlebox traversal 138 challenges have rendered the traditional Network/Transport layer 139 interface effectively useless for deploying new transports 140 [I-D.rosenberg-internet-waist-hourglass], and the TCP header's 141 limited 40-byte option space is almost consumed by options now 142 considered "essential", such as SACK [RFC2018], leaving little leeway 143 for further extending TCP in-place. Deploying end-to-end security is 144 problematic because IP-level mechanisms such as IPsec [RFC4301] and 145 HIP [RFC4423] interfere with middleboxes [RFC3947] [RFC5207], and 146 transport-level mechanisms such as TLS [RFC5246] must be modified for 147 each transport [RFC4347] [RFC5238]. 149 All of these challenges point to a pressing need to decompose the 150 Internet's traditional monolithic transport layer; this document 151 proposes such a decomposition as a guide for current and future 152 transport evolution efforts. 154 The proposed architecture, which we refer to as Tng ("Transport next- 155 generation"), decomposes traditional transport functions into four 156 layers, described in detail in Section 3. Tng factors out endpoint- 157 related functions into a separate Endpoint Layer, and performance- 158 related transport layer functions such as congestion-control into a 159 Flow Layer, leaving end-to-end semantic functions such as reliability 160 and ordering in a Semantic Layer, and end-to-end security functions 161 to an optional Security/Identity Layer. 163 The architecture described here is based on ideas proposed earlier 164 [ford08breaking] [iyengar09flow], and builds on previous research in 165 concurrent multipath transfer [iyengar06concurrent], congestion 166 control state sharing [RFC2140] [RFC3124], and transport efficiency 167 [RFC1644] [ford07structured]. We argue that addition of new non- 168 trivial functionality to existing transport protocols must recognize, 169 at least implicitly, the existence of these distinct components 170 within the transport layer; we illustrate this point in Section 6 by 171 juxtaposing the multipath TCP work currently underway with the Tng 172 model. Our intent is for this architecture to define a framework 173 into which specific protocols can fit in a modular fashion; the 174 architecture further permits existing transport protocols to be 175 reused and combined in new ways with only minor modifications to 176 support a wide variety of important deployment scenarios. 178 The rest of this draft is organized as follows: Section Section 2 179 outlines the most important architectural goals for a next-generation 180 transport architecture, with a particular emphasis on multipath 181 transport; Section Section 3 describes our Tng architecture with 182 specific details on how this architecture cleanly satisfies the goals 183 identified above; Section Section 4 discusses the applicability of 184 multipath congestion control work and its place in Tng; Section 185 Section 5 identifies specific protocol stack designs that are 186 compelling instantiations of Tng, with discussions about incremental 187 deployability; and finally, Section Section 6 discusses Tng's 188 relevance and potential contributions to current projects in and 189 outside the IETF. 191 2. Architecture Goals 193 This section outlines what we perceive to be the most important goals 194 for a next-generation transport architecture, and for multipath- 195 capable transport protocols conforming to such an architecture. We 196 divide these goals into two categories: functional goals and 197 performance/efficiency goals. We acknowledge that these goals and 198 their categorization is subjective and invite debate on what the true 199 goals and priorities should be. 201 2.1. Functional Goals 203 o Multihoming: The transport architecture must allow for a logical 204 transport endpoint as seen by the application to correspond to 205 multiple physical network attachment points, such as multiple IP 206 addresses on the same or different network interfaces. 208 o Application Compatibility: The architecture must enable next- 209 generation equivalents of existing transports, such as concurrent 210 multipath versions of TCP, SCTP, or DCCP, to serve as "drop-in" 211 replacements for the corresponding existing transports 212 transparently to existing applications using those transports, 213 merely by upgrading the operating systems of the end hosts. 215 o Network Compatibility: The architecture must enable next- 216 generation transport instances to remain backward compatible with 217 the Internet as it exists today, including being able to traverse 218 predominant existing middleboxes such as firewalls, NATs, and 219 performance enhancing proxies. 221 o Automatic Negotiation: A host supporting a next-generation 222 equivalent of an existing transport must be able to detect 223 reliably whether a new communication partner supports the next- 224 generation protocol, using it if so, and otherwise automatically 225 falling back to the existing protocol (e.g., standard TCP, SCTP, 226 or DCCP). 228 o Naming/Addressing Neutrality: The transport architecture should 229 cleanly abstract over specific naming/addressing schemes for 230 hosts, endpoints, and services, with a goal of permitting 231 transports conforming to this architecture to support multiple 232 endpoint address formats (e.g., IPv4 and IPv6), cryptographic 233 endpoint identities [RFC4423] [ford06persistent], and/or name- 234 based endpoint identification [cheriton00triad] 236 o Coexistence with End-to-End Security: The architecture must allow 237 for the optional deployment of end-to-end authentication and/or 238 privacy protection in a transport-neutral but network-compatible 239 fashion: i.e., supporting any transport conforming to this 240 architecture without requiring modifications specific to each 241 transport, while maintaining compatibility with legacy 242 middleboxes. 244 2.2. Performance/Efficiency Goals 246 o Multihoming and Multipath Capable: The architecture must enable a 247 next-generation transport to detect and utilize multiple available 248 paths between two logical endpoints, either one path at a time 249 (fail-over multipath) or several at once (concurrent multipath). 251 o Resource Pooling: Transports should be able to balance traffic 252 among available paths, optimizing network utility in a global 253 sense by shifting load away from congested bottlenecks and taking 254 advantage of spare capacity wherever it may be located 255 [wischik08resource]. 257 o Congestion State Sharing: Since popular applications such as HTTP 258 often use multiple transport instances between the same pair of 259 hosts, the architecture must avoid multiplicative explosions in 260 multipath congestion control contexts - i.e., N transport 261 instances times M multipath flows each - by enabling a multipath 262 "bundle" of congestion control contexts to be shared cleanly among 263 application-visible transport instances. 265 o TCP Friendliness: The architecture must enable new multipath 266 transport flows to coexist gracefully with predominant existing 267 transport flows, competing for bandwidth neither unduly 268 aggressively or unduly timidly (unless low-precedence operation is 269 specifically requested by the application, such as with LEDBAT 270 [I-D.shalunov-ledbat-congestion]). 272 o Support Small Transactions: Recognizing that many applications 273 today make heavy use of frequent small communications, such as 274 HTTP conditional GET transactions or streaming media frames, next- 275 generation transports should minimize the performance costs of 276 supporting these common application behaviors, including by 277 minimizing unnecessary protocol overhead on small packets and by 278 unnecessary round-trip delays or state maintenance costs when 279 applications use short transactions. 281 o Simplicity: The architecture should enable implementations of 282 next-generation transports to be as simple as possible while 283 remaining consistent with the above goals. In particular, end 284 host implementations that never need certain transport features 285 (e.g., embedded hosts) should ideally not have to incur the costs 286 of implementing and validating those features. 288 3. Architecture Overview 290 This section presents an overview of one possible transport 291 architecture that we believe can effectively support the above goals 292 and provides a clean framework for next-generation multipath-capable 293 transport protocols. We refer to this architecture for now simply as 294 Tng, for "Transport next-generation". Tng as described here is based 295 on ideas we proposed earlier [ford08breaking] [iyengar09flow]. While 296 by no means the only possible architecture supporting multipath 297 transport, our proposal incorporates many lessons learned from 298 previous transport research and development practice, should fit well 299 with the protocol design and congestion control work already in 300 progress in the SCTP and multipath TCP communities, and we believe 301 offers a strong starting point from which to develop a long-term 302 architecture for next-generation Internet transports. 304 Tng is based on a decomposition of the Internet's traditional 305 Transport Layer into up to four new layers, as illustrated below in 306 Figure 1: 308 +---------------+ 309 | Application | ^ 310 --> +---------------+ | 311 +---------------+ / | Semantic | | 312 | Application | / +---------------+ | Application- 313 +---------------+ <-- | Isolation | | Oriented 314 | Transport | +---------------+ -------------- 315 +---------------+ <-- | Flow | | Network- 316 | Network | \ +---------------+ | Oriented 317 +---------------+ \ | Endpoint | | 318 --> +---------------+ | 319 | Network | v 320 +---------------+ 322 Existing Layers Tng Layers 324 Figure 1 326 We first summarize Tng's new layers briefly here, then further 327 discuss their functions and interactions below. 329 o Semantic Layer: implements whatever communication abstractions are 330 to be made available to applications, including providing the end- 331 to-end reliability and ordering properties of abstractions like 332 TCP's byte streams or SCTP's message-based multi-streams. 334 o Isolation Layer (optional): provides end-to-end protection of the 335 application's communication and of the end-to-end reliability 336 mechanisms it builds on. 338 o Flow Regulation Layer or Flow Layer: implements congestion control 339 and other performance management functions. 341 o Endpoint Layer: Implements endpoint/service identification 342 functions (e.g., port numbers) that network operators and their 343 middleboxes require to enforce network access and security 344 policies. 346 We loosely classify Tng's layers into "application-oriented" and 347 "network-oriented" layers, as shown in Figure 1. We describe the top 348 two layers as "application-oriented" because their functions are 349 driven primarily by concerns of supporting and protecting the 350 application's end-to-end communication. We consider the bottom two 351 layers "network-oriented" because they represent functions that, 352 while traditionally located in the ostensibly "end-to-end" Transport 353 Layer, have proven in practice to be of great concern to network 354 operators and the middleboxes they deploy in the network to enforce 355 network usage policies [RFC3022] [RFC2979] or optimize communication 356 performance [RFC3135]. 358 Not all of Tng's functional layers need be present in the form 359 described above in a particular instantiation of the architecture: 360 e.g., the Isolation Layer may be omitted whenever strong end-to-end 361 authentication or encryption are not needed. Similarly, layers may 362 be recombined when pragmatic considerations require: e.g., we discuss 363 later in Section Section 5 how legacy TCP connections may serve as 364 one combined implementation of the Endpoint and Flow Layers for 365 maximum compatibility with legacy networks and middleboxes. The 366 layering diagram above is intended to serve as a conceptual model 367 that helps appropriately place new functionality in the transport 368 suite, and not a protocol design straitjacket. 370 3.1. Addressing Operational Concerns 372 Tng's decomposition of traditional transport functions serves several 373 pragmatically important purposes at once concerning the operation of 374 next-generation transports on today's and tomorrow's Internet: 376 o Multihoming and Multipath Transfer: By separating congestion 377 control state from the semantic state of application-visible 378 transport instances such as reliable byte streams, one transport 379 instance may be associated with multiple congestion control (CC) 380 contexts representing individual physical network paths to 381 implement concurrent multipath transfer cleanly, as illustrated in 382 Figure 2 below. The congestion control contexts for different 383 paths may still interact, for example to achieve global resource 384 pooling as discussed later in Section Section 4, but the ability 385 to maintain per-path congestion control state is a basic 386 prerequisite for concurrent multipath operation on the Internet 387 [iyengar06concurrent]. 389 +-----------------------+ 390 Application | HTTP, SMTP, etc. | 391 +-----------+-----------+ 392 | 393 +-----------------------+ 394 Semantic | Byte Stream | 395 +-----------+-----------+ 396 | 397 Path 1 Path 2 | Path 3 Path 4 398 /-----------/-----+-----\-----------\ 399 | | | | 400 +------+ +------+ +------+ +------+ 401 | Per- | | Per- | | Per- | | Per- | 402 Flow | Path | | Path | | Path | | Path | 403 | CC | | CC | | CC | | CC | 404 +------+ +------+ +------+ +------+ 405 | | | | 406 +------+ +------+ +------+ +------+ 407 Endpoint | Port | | Port | | Port | | Port | 408 +------+ +------+ +------+ +------+ 409 | | | | 410 +------------------------------------------+ 411 Network | IP Forwarding | 412 +------------------------------------------+ 414 Figure 2 416 o Congestion State Sharing: Separating congestion control state from 417 semantic state further enables multiple application-visible 418 transport instances to share a single underlying congestion 419 control context, or a single multipath bundle of congestion 420 control contexts, as illustrated in Figure 3 below. Compelling 421 even in the absence of multipath transport [RFC2140] [RFC3124] 422 [ford07structured], congestion state sharing becomes essential in 423 the presence of multipath transfer, to avoid an otherwise N x M 424 explosion in congestion control contexts resulting from 425 applications like HTTP that use N concurrent transport instances, 426 each using M communication paths. 428 +------------------------------------------+ 429 Application | HTTP | 430 +----------+---------------------+---------+ 431 | | 432 +------+------+ +------+------+ 433 Semantic | Stream 1 | | Stream 2 | 434 +------+------+ +------+------+ 435 | | 436 \----------+----------/ 437 | 438 Path 1 Path 2 | Path 3 Path 4 439 /-----------/-----+-----\-----------\ 440 | | | | 441 +------+ +------+ +------+ +------+ 442 | Per- | | Per- | | Per- | | Per- | 443 Flow | Path | | Path | | Path | | Path | 444 | CC | | CC | | CC | | CC | 445 +------+ +------+ +------+ +------+ 446 | | | | 447 +------+ +------+ +------+ +------+ 448 Endpoint | Port | | Port | | Port | | Port | 449 +------+ +------+ +------+ +------+ 450 | | | | 451 +------------------------------------------+ 452 Network | IP Forwarding | 453 +------------------------------------------+ 455 Figure 3 457 o Middlebox Compatibility: Decomposing the "network-oriented" 458 functions of endpoint identification and congestion control 459 enables middleboxes to enforce network policies and optimize 460 performance without interfering with end-to-end reliability 461 [saltzer84endtoend], fate sharing [clark88design], or end-to-end 462 security [RFC3135]. In particular, the architecture allows 463 middleboxes to interpose on the lower network-oriented layers, as 464 illustrated below in Figure 4, without having to understand or 465 interfere with the end-to-end application-oriented layers, 466 yielding a variety of practical benefits [ford08breaking]. 467 Through suitable reuse of existing protocols, a Tng protocol stack 468 can even remain fully compatible with existing middleboxes, as 469 described below in Section 5. 471 +-------------+ +-------------+ 472 | Application |<------------ end-to-end ------------->| Application | 473 +-------------+ +-------------+ 474 | Semantic |<------------ end-to-end ------------->| Semantic | 475 +-------------+ +-------------+ 476 | Isolation |<------------ end-to-end ------------->| Isolation | 477 +-------------+ +-------------+ +-------------+ 478 | Flow |<------------------->| Flow |<->| Flow | 479 +-------------+ +-------------+ +-------------+ +-------------+ 480 | Endpoint |<->| Endpoint |<->| Endpoint |<->| Endpoint | 481 +-------------+ +-------------+ +-------------+ +-------------+ 482 | Network |<->| Network |<->| Network |<->| Network | 483 +-------------+ +-------------+ +-------------+ +-------------+ 484 Firewall Performance 485 End Host or NAT Enhancing Proxy End Host 487 Figure 4 489 o End-to-End Security: By locating the Isolation Layer precisely on 490 the boundary between "network-oriented" and "application-oriented" 491 functions, in a position effectively corresponding to somewhere in 492 the middle of the classical Transport Layer, end-to-end security 493 mechanisms at this position avoid interfering with network 494 middleboxes as described above, while retaining IPsec's benefit of 495 operating in a "transport neutral" fashion and protecting all 496 application communication regardless of transport, without having 497 to be modified for each new transport as application-level 498 solutions such as TLS/DTLS does [RFC5246] [RFC4347]. 500 Tng's contribution as an architecture is not to find a perfect or 501 complete decomposition of the transport layer, but to identify 502 specific transport functions that have proven in practice to be 503 "network-oriented" contrary to their traditional placement in the 504 transport layer, and to construct a new but incrementally deployable 505 layering that reflects this reality and restores the "end-to-endness" 506 of the remaining application-oriented functions. 508 The following subsections outline each Tng layer in more detail, 509 including a brief summary of the interface each layer provides to 510 higher layers. 512 3.2. Endpoint Layer 514 As in the OSI model, TCP/IP traditionally breaks application endpoint 515 identifiers into Network Layer (IP address) and Transport Layer (port 516 number) components, including only the former in the IP header on the 517 assumption that the network need know only how to route to a given 518 host, and leaving port numbers to be parsed and demultiplexed by the 519 transport. As the Internet's size and diversity exploded, however, 520 network operators needed to enforce access policies that depend on 521 exactly who is communicating--not just which hosts, but which 522 applications and users. Now-ubiquitous middleboxes such as 523 Firewalls, traffic shapers, and NATs must therefore understand 524 transport headers in order to enforce these network policies. Since 525 middleboxes cannot forward traffic for transports whose headers they 526 do not understand, new transports have become effectively 527 undeployable other than atop TCP or UDP 528 [I-D.rosenberg-internet-waist-hourglass]. 530 Recognizing that communicating rich endpoint information is a 531 network-oriented function relevant to in-network policy enforcement, 532 Tng factors this function into its Endpoint Layer so that middleboxes 533 can extract this information without having to understand 534 application-oriented headers. Tng reinterprets UDP as an initial 535 Endpoint Layer protocol already supported by most middleboxes, but 536 TCP can be used as well. In the longer term, we envision the 537 Endpoint Layer evolving in a backward-compatible fashion to 538 incorporate ideas from NAT traversal mechanisms [ford05p2p] [RFC5389] 539 [I-D.ietf-mmusic-ice] and delegation-friendly architectures 540 [walfish04middleboxes] [guha07end], thereby incorporating these 541 mechanisms as required into the protocol stack and eventually 542 eliminating the need for applications to manage connectivity 543 challenges like these. 545 The Endpoint Layer's interface to higher layers is almost identical 546 to the Network Layer's interface - it provides a simple best-effort 547 packet delivery service - but with richer endpoint names than IP 548 addresses alone provide. These endpoint names will initially consist 549 simply of (IP address, port number) pairs for compatibility with TCP 550 and UDP, but may later evolve in a backward-compatible fashion to 551 include extensions such as service/port names 552 [I-D.touch-tcp-portnames]. 554 3.3. The Flow Regulation Layer 556 As Tng's Endpoint Layer factors out endpoint identification, the Flow 557 Regulation Layer similarly factors out performance related functions 558 such as congestion control, with the recognition that these functions 559 have likewise become "network-oriented" in practice. The Flow Layer 560 assumes that the underlying Endpoint Layer provides only best-effort 561 packet delivery between application endpoints, and builds a flow- 562 regulated best-effort delivery service for higher layers to build on. 563 In particular, the Flow Layer's interface to higher layers includes 564 an explicit signal indicating when the higher layer may transmit new 565 packets. 567 To perform this flow regulation, the Flow Layer may either implement 568 standard TCP-like congestion control, or, as we discuss in 569 [iyengar09flow], may use more specific knowledge of an underlying 570 network technology or administrative domain. In order to support 571 multipath transports effectively, the Flow Layer also needs to enable 572 higher layers to indicate sets of flows or "bundles" representing a 573 single logical communication activity, and adjust the Flow Layer's 574 congestion control algorithms to perform resource pooling as 575 discussed later in Section 4. Tng's flow layer might eventually 576 incorporate other performance-enhancing mechanisms as well, such as 577 forward error correction. 579 3.4. The Isolation Layer 581 Having factored out network-oriented transport functions into the 582 Endpoint and Flow Layers, the optional Isolation Layer "isolates" the 583 application from the network, and protects the "end-to-endness" of 584 higher layers. This isolation includes two elements. First, the 585 Isolation Layer protects the application's end-to-end communication 586 from interference or eavesdropping within the path, via transport- 587 neutral cryptographic security as in IPsec. Second, the Isolation 588 Layer protects the application and end-to-end transport from 589 unnecessary exposure to details of network topology and attachment 590 points, by implementing location-independent endpoint identities as 591 in HIP [RFC4423] or UIA [ford06persistent], which remain stable even 592 as devices move or the network reconfigures. 594 The Isolation Layer's interface to higher layers is functionally 595 equivalent to the interface exported by the Flow Layer, but with 596 transformed packet payloads and/or endpoint identities. We believe 597 the Isolation Layer represents a suitable location for end-to-end 598 security precisely because it defines the boundary between network- 599 oriented and application-oriented functions, thus ensuring integrity 600 and security of the latter, while allowing middleboxes to interact 601 with the former. In contrast with SSL/TLS, the Isolation layer is 602 neutral to transport semantics and does not need to be adapted to 603 each transport. In contrast with IPsec's standard location 604 immediately above IP, the Isolation Layer does give up the ability to 605 protect Endpoint and Flow Layer mechanisms from off-path DoS attacks 606 as IPsec protects TCP's signaling mechanisms, but if standard non- 607 cryptographic defenses against such attacks are deemed insufficient, 608 then IPsec authentication can still be deployed in Tng underneath the 609 flow layer, ideally via a delegation-friendly scheme permitting 610 controlled interposition by middleboxes. 612 3.5. The Semantic Layer 614 Tng's Semantic Layer implements the remaining application-oriented 615 end-to-end transport functions, particularly end-to-end reliability. 616 In the case of TCP, these functions are all those in the original TCP 617 protocol [RFC0793] except port numbers, including acknowledgment and 618 retransmission, order preservation, and receive window management. 619 Other application-visible semantics, such as RDP's reliable datagrams 620 and SCTP's message-based multistreaming [RFC4960], could fit equally 621 well into Tng's Semantic Layer as distinct protocols. 623 The Semantic Layer's interface to lower layers differs from that of 624 traditional Internet transports in two ways. First, a Tng semantic 625 protocol uses the Endpoint Layer's endpoint identities (possibly 626 transformed by the Isolation Layer) instead of implementing its own 627 port number demultiplexing. Second, a Tng semantic protocol 628 implements no congestion control but relies on the underlying Flow 629 Layer to signal when packets may be transmitted. The Semantic 630 Layer's interface to higher layers (e.g., the application) depends on 631 the transport semantics it implements, but need not differ in any 632 application-visible way from existing transport APIs--a fact that 633 could aid deployment as discussed later in Section 5. 635 4. Multipath Congestion Control 637 Tng's decomposition of the Flow Layer from the Semantic Layer 638 provides a natural decoupling for per-path congestion state in the 639 Flow Layer from the per-transport-instance state in the Semantic 640 Layer, allowing for a one-to-one, one-to-many, many-to-one, or many- 641 to-many relationship between flows and transport instances in support 642 of efficient multipath transport. An important outstanding issue, 643 however, is how and whether multipath operation should affect the 644 congestion control algorithm implemented in the Flow Layer. In 645 particular, when a host is transmitting packets from one logical 646 transport instance over multiple flows concurrently, how should the 647 host adjust its congestion control behavior for each path? We 648 briefly summarize here a few alternative high-level approaches, while 649 making no attempt to explore the details or identify the "right" 650 approach: 652 o No Adjustment: Each flow independently runs a standard, unmodified 653 TCP congestion control algorithm [RFC2581]. This approach is 654 simple and inherits all the well-understood properties of TCP 655 congestion control, but creates fairness concerns: if M flows 656 happen to share a congestion bottleneck, such as a home broadband 657 link, then the multipath aggregate competes at that bottleneck M 658 times as aggressively as a single-path TCP connection. The 659 effects of this approach are essentially the same - no better but 660 also no worse - as the effects that BitTorrent clients cause as 661 they utilize many parallel streams at application level. 663 o Static Weight Adjustments: Each flow independently runs standard 664 TCP congestion control, but with each flow's aggressiveness 665 lowered equally using known techniques [crowcroft98differentiated] 666 so that the multipath aggregate as a whole exhibits the same 667 aggressiveness as a single traditional TCP stream (or perhaps 668 equivalent to two traditional TCP streams, if we take HTTP's 669 allowance for two parallel streams [RFC2616] as a "de facto" 670 fairness benchmark). This approach addresses the above fairness 671 issue, at the cost of potentially underutilizing network capacity 672 when some paths are more congested than others. 674 o Dynamic Weight Adjustments: As above, but dynamically adjust the 675 relative weights of each flow to take greater advantage of lightly 676 loaded paths while maintaining aggregate fairness 677 [honda09multipath]. Such an approach can provide both fairness 678 and resource pooling [wischik08resource], but it is not clear that 679 these adjustments will converge to stability as many multipath 680 aggregates dynamically shifting their flows' weights in response 681 to each others' effects on the network. 683 o New Response Functions: The basic congestion control response 684 function can be modified in a multipath-sensitive fashion so that 685 the flows comprising all multipath aggregates provably converge 686 toward stable and fair use of the network [kelly05stability]. As 687 with most new congestion control schemes that modify the basic 688 congestion response function, however, it is unclear how such a 689 new scheme will behave in competition with existing TCP flows in 690 the existing Internet, especially in the presence of connections 691 with varying round-trip times. 693 Addressing the question of the right approach to adjusting congestion 694 control for multipath operation will require further research and 695 experimentation, which we consider to be independent of and 696 orthogonal to Tng as an architecture. We assume that we will develop 697 multipath transport protocols in parallel with this continuing 698 research in multipath congestion control, and that multipath 699 transports will for the time being need to support multiple 700 alternative multipath congestion control schemes, in the same way 701 that mature single-path transport implementations such as Linux's 702 already support a variety of selectable single-path schemes. 704 To support such a "plug-and-play" selection of multipath congestion 705 control schemes, Tng's Flow Layer will need one new architectural 706 feature: a way for higher layers to indicate which flows should be 707 logically "tied together" and treated as a single logical aggregate 708 for congestion control purposes. For this purpose, the interface 709 that Tng's Flow Layer provides to higher layers provides an operation 710 allowing higher layers to tie multiple flows into a "flow bundle". 711 If we consider this operation to be a function, e.g., 712 flow_bundle(flow1,flow2), and a Semantic Layer protocol opens three 713 flows A, B, and C, to support a particular logical communication 714 session, then the Semantic Layer protocol might call flow_bundle(A,B) 715 followed by flow_bundle(A,C) to tie the three flows together into a 716 bundle. Exactly what effect this action would have depends of course 717 on the specific congestion control algorithm in effect: with the "No 718 Adjustment" approach above, for example, tying together flows will 719 have no effect on congestion control behavior; with the "Static 720 Weight Adjustments" approach, the flow_bundle() calls will cause the 721 Flow Layer to recompute the weights of all the newly-bundled flows so 722 that the bundle as a whole exhibits the same effective aggressiveness 723 as that of one (or two) single-path TCP connections. The Semantic 724 Layer does not generally need to know exactly how these flow_bundle() 725 calls are affecting congestion control, since it merely depends on 726 the Flow Layer to indicate when each individual flow is ready to 727 accept new packets for transmission. 729 While the Tng Flow Layer's flow_bundle operation is primarily 730 intended for use by a multipath-capable Semantic Layer, there is no 731 fundamental reason this operation could not or should not be exported 732 further upwards, all the way to the application. Given a sockets API 733 extension providing access to this operation, for example, an HTTP 734 client could use it to indicate that the multiple concurrent HTTP 735 streams it opens are logically part of the same application-level 736 communication session, mitigating the fairness concerns that HTTP 737 clients currently cause if they open more than one or two concurrent 738 HTTP connections at once. A flow_bundle operation could probably be 739 considered "safe" to export to untrusted applications since bundling 740 can only cause flows to become less aggressive, not more. 741 Nevertheless, exporting a flow bundling operation to applications is 742 outside of Tng's immediate scope and purposes, so we leave it for 743 future exploration. 745 5. Protocol Implementation and Incremental Deployment Paths 747 Any new Internet transport, or even any refactoring of an existing 748 Internet transport, faces major deployment hurdles due to the 749 Internet's inertia, and Tng is no exception. However, we find 750 several reasons for optimism that an architecture incorporating the 751 principles described here could overcome these deployment hurdles. 752 This section therefore outlines potential approaches to overcoming 753 these hurdles and facilitating deployment of next-generation 754 multipath-capable transports. 756 There are many possible protocol stack designs that would be 757 architecturally consistent with Tng and its goals; we make no attempt 758 to specify such a protocol stack design here, but leave that to be 759 decided and standardized by the Internet transport community. Here 760 we merely point out certain compelling possibilities that may be 761 particularly worthy of further exploration, a few of which are 762 illustrated in Figure 1 and discussed below: 764 +------+ +-------+ +-------+ +-------+ 765 Semantic | TCP+ | | SCTP+ | | DCCP+ | | ??? | 766 +------+ +-------+ +-------+ +-------+ 767 \------------\-----+------/-------------/ 768 | 769 /------------/------+------\-------------\ 770 +-------+ +---------+ +-------+ +-------+ 771 Isolation | DTLS | | IPsec | | TLS | | ??? | 772 +-------+ +---------+ +-------+ +-------+ 773 | | | | 774 +---------------------+ +-------+ +-------+ 775 Flow | DCCP | | | | ??? | 776 +---------------------+ | | +-------+ 777 | | TCP | | 778 +---------------------+ | | +-------+ 779 Endpoint | UDP | | | | ??? | 780 +---------------------+ +-------+ +-------+ 781 | | | 782 +------------------------------------------------+ 783 Network | IP | 784 +------------------------------------------------+ 786 Figure 5 788 o Transport Reuse in the Semantic Layer: Any existing Internet 789 transport may be adapted into a Tng Semantic Layer protocol merely 790 by relocating it atop suitable Isolation (optional), Flow, and 791 Endpoint Layers, and disabling the legacy transport's built-in 792 congestion control, if any, in favor of using the Flow Layer's 793 congestion control facilities. Figure 1 above illustrates TCP and 794 SCTP protocols modified in this way, which we refer to as "TCP+" 795 and "SCTP+" respectively to emphasize that they are identical in 796 application-visible semantics but not identical in implementation 797 to the corresponding original protocols. The "DCCP+" protocol 798 illustrated in the figure provides congestion controlled datagram 799 delivery like DCCP does, hence its name, but in fact needs to do 800 little other than provide an application interface to the lower 801 layers, since the Flow Layer implements congestion control. This 802 "DCCP+" protocol is thus likely to be closest to DCCP in 803 application-visible function, but closest to UDP in 804 implementation. 806 o Application Transparency: A Semantic Layer protocol in Tng can 807 offer applications an API similar or identical to that of any 808 legacy Internet transport. Our current Tng prototype already 809 includes a Semantic Layer protocol providing a reliable stream 810 abstraction compatible with TCP's, although it currently operates 811 in user space and does not implement some TCP features such as 812 urgent data. With careful design, a system-level implementation 813 of a Tng protocol stack could replace TCP or another legacy 814 transport completely transparently to applications: a host 815 initiating a connection would dynamically probe the remote host 816 for Tng support, use the new protocol stack if possible 817 transparently to the application, and fall back on standard TCP 818 (again transparently to the application) otherwise. 820 o Transport Reuse in Lower Layers: A protocol stack fully conforming 821 to the Tng architectural model could be composed entirely of 822 existing protocols "top-to-bottom": e.g., TCP with congestion 823 control disabled as the Semantic Layer as described above, either 824 DTLS or IPsec as the Isolation Layer, DCCP as the Flow Layer, and 825 UDP as the Endpoint Layer (see the left two columns of Figure 1.) 826 This approach may not necessarily yield the most far-reaching 827 benefits without allowing some modifications to the original 828 protocols, and may incur overheads due to redundancies between 829 layers. Nevertheless, reuse could mitigate the difficulty of new 830 protocol development and standardization. 832 o Compatibility with Existing Firewalls, NATs, and PEPs: While a 833 DCCP-like protocol is most suited to Tng's Flow Layer, a Tng stack 834 use standard TCP as a fallback "Flow Layer," atop which the Tng 835 stack's true Isolation and Semantic Layer protocols would run as 836 if a TCP "application (see the TLS/TCP column in Figure 1). While 837 TCP's overhead and ordering constraints may incur a performance 838 cost, encapsulation in legacy TCP flows would make the new stack 839 even more compatible with existing networks and capable of 840 benefiting from existing TCP-based PEPs, and could still restore 841 end-to-end fate-sharing by ensuring that the new Semantic Layer 842 retains all end-to-end "hard state" and can restart failed Flow 843 Layer TCP flows. 845 o Single-Ended Operation: If only one end host supports the new Tng 846 protocol stack, maintaining compatibility with legacy TCP hosts 847 constrains the other host to use legacy TCP on the wire as well, 848 making it impossible for the on-the-wire format to be decomposed 849 according to the Tng layering model. On the other hand, even in 850 this case, the Tng layering model can still help guide and 851 conceptually organize protocol stack implementations in the end 852 hosts. For example, the single-ended multipath TCP protocol 853 currently under development [I-D.van-beijnum-1e-mp-tcp], while 854 avoiding any changes to TCP's wire protocol for compatibility 855 reasons, still requires a clean internal separation between per- 856 path congestion control functions and TCP semantic functions such 857 as reliability and ordering, as illustrated in Figure 2. 858 Organizing next-generation transports according to this model, 859 regardless of whether the wire protocol matches the model or not, 860 may simplify the design and implementation of end hosts that wish 861 to support both single-ended and double-ended multipath operation, 862 for example. 864 6. How Tng Complements Current Projects 866 Two drafts are being considered in the IETF as multipath transport 867 solutions: Single-Ended MPTCP [I-D.van-beijnum-1e-mp-tcp], which is a 868 sender-only based multipath TCP, and Two-Ended MPTCP 869 [I-D.ford-mptcp-multiaddressed], which requires receiver 870 participation as well. Having discussed how Tng applies to the One- 871 Ended proposal in Section Section 5, we now focus on how Tng applies 872 to the Two-Ended MPTCP proposal. 874 Two-Ended MPTCP, functionally, divides the Transport Layer into two 875 components: the MPTCP part, which is responsible for global ordering 876 of application data and for reliability; and the "legacy TCP" part, 877 which is essentially responsible for congestion control on each path. 878 MPTCP suggests adding new paths by creating separate connections and 879 adding them into the MPTCP pool and also acknowledges the possibility 880 that new connections may be established from a sender to a multihomed 881 receiver on different ports, since the MPTCP connection is ultimately 882 identified by the MPTCP Sender Token. For all practical purposes, 883 the upper MPTCP component maps to our Semantic Layer with the lower 884 TCP implementing our Flow and Endpoint Layers. We juxtapose the Two- 885 Ended MPTCP architecture from [I-D.ford-mptcp-multiaddressed] with 886 Tng's architecture below: 888 +---------------------------+ +--------------------------+ 889 | Application | | Application | 890 +---------------------------+ +--------------------------+ 891 | MPTCP | | Semantic | 892 + - - - - - + - - - - - - + +--------------------------+ 893 | TCP | TCP | | Flow+Endp | Flow+Endp | 894 +---------------------------+ +--------------------------+ 895 | IP | IP | | IP | IP | 896 +---------------------------+ +--------------------------+ 898 Figure 6 900 There are significant functional and structural similarities between 901 the Tng architecture and MPTCP, and it is not by accident. We argue 902 that adding any new non-trivial functionality into an existing 903 transport must come to terms with this separation of concerns 904 necessary within the transport layer. 906 While [I-D.ford-mptcp-multiaddressed] identifies the same components 907 as we do for implementing a multipath transport protocol, Tng 908 separates these components and places them in a clean framework in 909 which other Semantic protocols (e.g., SCTP) or other Flow protocols 910 (e.g., DCCP over UDP) can also fit and interoperate together. Our 911 work is complementary to the current MPTCP effort, since it describes 912 the architecturally clean space within which MPTCP can exist, and 913 describes clear directions in which this architecture can evolve. 914 Tng defines an architectural blueprint in which MPTCP is one 915 instantiation, providing a TCP-compatible byte streams at the 916 Semantic Layer and legacy TCP as a backward-compatible Flow Layer. 918 We now turn our attention to other multihoming- and multipath-capable 919 transport proposals, showing in turn how their design, explicitly or 920 implicitly, embodies Tng's architectural separation of concerns: 922 o SCTP [RFC4960] has sophisticated mechanisms for multihoming and 923 for managing addition and deletion of endpoints within an end-to- 924 end "association" [RFC5061]. The SCTP protocol design makes a 925 clear distinction between the application-oriented ordering 926 through streams and separate Stream Sequence Numbers (SSNs); this 927 "upper" component maps to our Semantic Layer. SCTP uses a 928 separate Transmission Sequence Number (TSN) space for the flow- 929 level function of congestion control, which maps to our Flow 930 Layer. SCTP does use flow-level TSNs for reliability; and some 931 form of global per-flow sequencing information will be important 932 to enable collusion among streams for loss recovery --- this 933 information does not have to be explicit in packets, but can be 934 signaling between the Semantic and Flow Layers as discussed in 935 Section 4. 937 o LS-SCTP [al04ls-sctp] and pTCP [hsieh02ptcp] are examples of 938 multipath transports that require both sender- and receiver-side 939 modifications to SCTP and TCP, respectively. Both use a separate 940 sequence space for global ordering while using a per-path sequence 941 space for flow functions. Similar to Two-Ended MPTCP, these 942 protocols can be divided into upper and lower parts that map to 943 our Semantic and Flow Layers. 945 o CMT [iyengar06concurrent] and mTCP [zhang04transport] are examples 946 of multipath transports that require modifications only to the 947 sender-side in SCTP and TCP, respectively. Similar to One-Ended 948 MPTCP, as discussed in Section Section 5, such protocols may still 949 benefit from a cleaner conceptualization of functions within the 950 transport suite. 952 o SST [ford07structured] is a new transport protocol that implements 953 Tng's separation of concerns internally in addition to other new 954 application-visible features. SST uses a separate Stream Protocol 955 with stream sequence numbers for application-oriented ordering and 956 reliability functions, a separate Channel Protocol with transmit 957 sequence numbers for security and for network-oriented congestion 958 control, and a separate Endpoint Layer implemented by UDP. Our 959 first prototype of Tng builds on the SST implementation. 961 It should also be possible to implement Tng by adapting other 962 established protocols as well. DCCP [RFC4340] or CM [RFC3124], could 963 implement our Flow Layer; IPsec and/or HIP, modified to run atop the 964 Flow Layer, could provide our Isolation Layer; and TCP, SCTP, or 965 another existing transport, modified to disable its internal 966 congestion control functions and instead use those of the underlying 967 Flow Layer, could provide our Semantic Layer. There would be costs 968 to this approach: the existing protocols were not designed for Tng, 969 and they each independently re-implement considerable functionality; 970 MPTCP is an integrated design that reuses or shares synergistically 971 between layers. Thus, while incremental deployment is possible with 972 Tng, one can build integrated designs for specific protocol 973 combinations that are tighter and better optimized for bit-space. 975 Finally, we note that Tng's Endpoint Layer, being responsible for 976 interaction with NATs, provides an architecturally clean space for 977 NAT traversal work, such as STUN [RFC5389] and TURN 978 [I-D.ietf-behave-turn], that are in progress in the IETF BEHAVE 979 working group. 981 7. Experiences with Running Code 983 We have a working prototype implementation of a protocol stack 984 conforming to Tng's layering model and providing the basic structural 985 benefits described above. The prototype and experiments with it are 986 described in more detail elsewhere [iyengar09flow]. More to be 987 written (perhaps). 989 8. Security Considerations 991 To be written. 993 9. IANA Considerations 995 To be written: endpoint ids, transport protocol numbers, ... 997 10. Acknowledgments 999 To be written. Discussions and participants on the multipathtcp 1000 mailing list. 1002 11. References 1004 11.1. Normative References 1006 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1007 RFC 793, September 1981. 1009 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 1010 Functional Specification", RFC 1644, July 1994. 1012 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1013 Selective Acknowledgment Options", RFC 2018, October 1996. 1015 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 1016 April 1997. 1018 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 1019 Control", RFC 2581, April 1999. 1021 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1022 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1023 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1025 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1026 Firewalls", RFC 2979, October 2000. 1028 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1029 Address Translator (Traditional NAT)", RFC 3022, 1030 January 2001. 1032 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 1033 RFC 3124, June 2001. 1035 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1036 Shelby, "Performance Enhancing Proxies Intended to 1037 Mitigate Link-Related Degradations", RFC 3135, June 2001. 1039 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 1040 RFC 3649, December 2003. 1042 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1043 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1044 January 2005. 1046 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1047 Internet Protocol", RFC 4301, December 2005. 1049 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1050 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1052 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1053 Security", RFC 4347, April 2006. 1055 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1056 (HIP) Architecture", RFC 4423, May 2006. 1058 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1059 RFC 4960, September 2007. 1061 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1062 Kozuka, "Stream Control Transmission Protocol (SCTP) 1063 Dynamic Address Reconfiguration", RFC 5061, 1064 September 2007. 1066 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 1067 Firewall Traversal Issues of Host Identity Protocol (HIP) 1068 Communication", RFC 5207, April 2008. 1070 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 1071 the Datagram Congestion Control Protocol (DCCP)", 1072 RFC 5238, May 2008. 1074 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1075 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1077 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1078 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1079 October 2008. 1081 11.2. Informative References 1083 [I-D.ford-mptcp-multiaddressed] 1084 Ford, A., Raiciu, C., Handley, M., and S. Barre, "TCP 1085 Extensions for Multipath Operation with Multiple 1086 Addresses", draft-ford-mptcp-multiaddressed-00 (work in 1087 progress), May 2009. 1089 [I-D.ietf-behave-turn] 1090 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 1091 Relays around NAT (TURN): Relay Extensions to Session 1092 Traversal Utilities for NAT (STUN)", 1093 draft-ietf-behave-turn-16 (work in progress), July 2009. 1095 [I-D.ietf-mmusic-ice] 1096 Rosenberg, J., "Interactive Connectivity Establishment 1097 (ICE): A Protocol for Network Address Translator (NAT) 1098 Traversal for Offer/Answer Protocols", 1099 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1101 [I-D.rosenberg-internet-waist-hourglass] 1102 Rosenberg, J., "UDP and TCP as the New Waist of the 1103 Internet Hourglass", 1104 draft-rosenberg-internet-waist-hourglass-00 (work in 1105 progress), February 2008. 1107 [I-D.shalunov-ledbat-congestion] 1108 Shalunov, S., "Low Extra Delay Background Transport 1109 (LEDBAT)", draft-shalunov-ledbat-congestion-00 (work in 1110 progress), March 2009. 1112 [I-D.touch-tcp-portnames] 1113 Touch, J., "A TCP Option for Port Names", 1114 draft-touch-tcp-portnames-00 (work in progress), 1115 April 2006. 1117 [I-D.van-beijnum-1e-mp-tcp] 1118 Beijnum, I., "One-ended multipath TCP", 1119 draft-van-beijnum-1e-mp-tcp-00 (work in progress), 1120 May 2009. 1122 [al04ls-sctp] 1123 Al, A., Saadawi, T., and M. Lee, "LS-SCTP: A Bandwidth 1124 Aggregation Technique For Stream Control Transmission 1125 Protocol", Computer Communications Vol. 27, No. 10, 1126 June 2004. 1128 [balakrishnan97comparison] 1129 Balakrishnan, H., Padmanabhan, V., Seshan, S., and R. 1130 Katz, "A Comparison of Mechanisms for Improving TCP 1131 Performance over Wireless Links", IEEE/ACM Transactions on 1132 Networking Vol. 5, No. 6, December 1997. 1134 [cheriton00triad] 1135 Cheriton, D. and M. Gritter, "TRIAD: A New Next-Generation 1136 {Internet} Architecture", Online at: 1137 http://www.dsg.stanford.edu/triad, July 2000. 1139 [clark88design] 1140 Clark, D., "The Design Philosophy of the DARPA Internet 1141 protocols", ACM SIGCOMM, August 1988. 1143 [crowcroft98differentiated] 1144 Crowcroft, J. and P. Oechslin, "Differentiated End-to-End 1145 Internet Services using a Weighted Proportional Fair 1146 Sharing TCP", ACM SIGCOMM Computer Communication 1147 Review Vol. 28, No. 3, July 1998. 1149 [ford05p2p] 1150 Ford, B., "Peer-to-Peer Communication Across Network 1151 Address Translators", USENIX Annual Technical Conference, 1152 April 2005. 1154 [ford06persistent] 1155 Ford, B., Strauss, J., Lesniewski-Laas, C., Rhea, S., 1156 Kaashoek, F., and R. Morris, "Persistent Personal Names 1157 for Globally Connected Mobile Devices", USENIX OSDI, 1158 November 2006. 1160 [ford07structured] 1161 Ford, B., "Structured Streams: a New Transport 1162 Abstraction", ACM SIGCOMM, August 2007. 1164 [ford08breaking] 1165 Ford, B. and J. Iyengar, "Breaking Up the Transport 1166 Logjam", ACM HotNets, October 2008. 1168 [guha07end] 1169 Guha, S. and P. Francis, "An End-Middle-End Approach to 1170 Connection Establishment", ACM SIGCOMM, August 2007. 1172 [honda09multipath] 1173 Honda, M., Nishida, Y., Eggert, L., Sarolahti, P., and H. 1174 Tokuda, "Multipath Congestion Control for Shared 1175 Bottleneck", International Workshop on Protocols for 1176 Future Large-Scale and Diverse Network Transports 1177 (PFLDnet), May 2009. 1179 [hsieh02ptcp] 1180 Hsieh, H-Y. and R. Sivakumar, "pTCP: An End-to-End 1181 Transport Layer Protocol for Striped Connections", IEEE 1182 ICNP, November 2002. 1184 [iyengar06concurrent] 1185 Iyengar, J., Amer, P., and R. Stewart, "Concurrent 1186 Multipath Transfer Using SCTP Multihoming Over Independent 1187 End-to-End Paths", IEEE/ACM Transactions on 1188 Networking Vol. 15, No. 5, October 2006. 1190 [iyengar09flow] 1191 Iyengar, J. and B. Ford, "Flow Splitting with Fate Sharing 1192 in a Next Generation Transport Services Architecture", 1193 Under submission, Online 1194 at http://www.fandm.edu/jiyengar/papers/flowsplitting.pdf, 1195 June 2009. 1197 [kelly05stability] 1198 Kelly, F. and T. Voice, "Stability of end-to-end 1199 algorithms for joint routing and rate control", ACM 1200 SIGCOMM Computer Communication Review Vol. 35, No. 2, 1201 April 2005. 1203 [roberts03next] 1204 Roberts, L., "The Next Generation of IP --- Flow Routing", 1205 International Conference on Advances in Infrastructure 1206 for Electronic Business, Science, Education, Medicine, and 1207 Mobile Technologies on the Internet, July 2003. 1209 [saltzer84endtoend] 1210 Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments 1211 in System Design", Transactions on Computer Systems Vol. 1212 2, No. 4, November 1984. 1214 [walfish04middleboxes] 1215 Walfish, M. and et. al, "Middleboxes No Longer Considered 1216 Harmful", USENIX OSDI, December 2004. 1218 [wischik08resource] 1219 Wischik, D., Handley, M., and M. Bagnulo-Braun, "The 1220 Resource Pooling Principle", ACM SIGCOMM CCR Vol. 38, No. 1222 5, October 2008. 1224 [zhang04transport] 1225 Zhang, M. and et. al, "", USENIX Annual Technical 1226 Conference, June 2004. 1228 Authors' Addresses 1230 Janardhan Iyengar 1231 Franklin and Marshall College 1232 Mathematics and Computer Science 1233 PO Box 3003 1234 Lancaster, PA 17604-3003 1235 USA 1237 Phone: 717-358-4774 1238 Email: jiyengar@fandm.edu 1240 Bryan Ford 1241 Max Planck Institute for Software Systems 1242 Saarbrucken, 1243 Germany 1245 Email: baford@mpi-sws.org