idnits 2.17.1 draft-boucadair-transport-protocols-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (March 6, 2015) is 3332 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcp-edo-01 == Outdated reference: A later version (-08) exists of draft-ietf-tsvwg-behave-requirements-update-01 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 4996 (Obsoleted by RFC 6846) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft D. Binet 4 Intended status: Informational C. Jacquenet 5 Expires: September 7, 2015 France Telecom 6 L. Contreras 7 Telefonica I+D 8 Y. Lee 9 Comcast 10 March 6, 2015 12 On the Need for Transport Protocol Profiles & Investigating New 13 Evolution Tracks 14 draft-boucadair-transport-protocols-01 16 Abstract 18 The world of Internet transport protocols is changing, after decades 19 of TCP and UDP operation. Several proposals have been submitted for 20 the past years (and counting) to introduce other transport protocols 21 that aim at reducing the web latency of that of TCP or avoiding the 22 burden of the various middle-boxes (NATs, firewalls, for one) 23 encountered along the communication path. Such initiatives, although 24 not new, are motivated by the complexity of some (non-transparent) 25 networking functions. 27 This document advocates for the definition of transport profiles and 28 the need to document recommendations for middleboxes, including 29 Performance Enhancement Proxies (PEPs) behaviors. A collaboration 30 among the involved players (service providers, vendors) is required 31 to soften the current complications encountered in the Internet at 32 large. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 7, 2015. 50 Copyright Notice 52 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. On Transport Services . . . . . . . . . . . . . . . . . . . . 4 69 3. Strategies to Enhance Transport services . . . . . . . . . . 5 70 4. Proliferation of Transport Protocols . . . . . . . . . . . . 5 71 5. On TCP Hegemony . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Need for a Holistic View for TCP Variants . . . . . . . . . . 7 73 7. Adoption Rate of TCP Extensions . . . . . . . . . . . . . . . 8 74 8. A Network Provider's Perspective . . . . . . . . . . . . . . 8 75 8.1. Proposed Approach . . . . . . . . . . . . . . . . . . . . 8 76 8.2. Some Risks: . . . . . . . . . . . . . . . . . . . . . . . 9 77 9. Previous IETF Works . . . . . . . . . . . . . . . . . . . . . 10 78 10. What's Next? . . . . . . . . . . . . . . . . . . . . . . . . 11 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 14. Informative References . . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 The world of Internet transport protocols is changing, after decades 88 of TCP and UDP operation. Several proposals have been submitted for 89 the past years (and counting) to introduce other transport protocols 90 or additional features to existing protocols that aim at reducing the 91 web latency of that of TCP or avoiding the burden of the various 92 middle-boxes (NATs, firewalls, for one) encountered along the 93 communication path. Such initiatives, although not new, are 94 motivated by the complexity of some (non-transparent) networking 95 functions. Further collateral effects (including a thorough 96 identification of various network hindrances) are discussed in this 97 document together with potential contributions from network operators 98 to overcome some of the encountered issues. 100 Advanced service functions (e.g., Performance Enhancement Proxies 101 ([RFC3135]), NATs, firewalls, etc.) are now required to achieve 102 various objectives such as IP address sharing, firewalling, to avoid 103 covert channels, to detect and protect against ever increasing DDoS 104 attacks, etc. Removing those functions is not an option because they 105 are used to address constraints that are often typical of the current 106 yet protean Internet situation (global IPv4 address depletion comes 107 to mind, but also the plethora of services with different 108 QoS/security/robustness requirements, etc.), and this is even 109 exacerbated by environment-specific designs (e.g., the nature and the 110 number of service functions that need to be invoked at the Gi 111 interface of a mobile infrastructure). Moreover, these sophisticated 112 service functions are located in the network but also in service 113 platforms, or intermediate entities (e.g., CDNs). This situation 114 clearly complicates diagnostic procedures whenever service 115 degradation is experienced, given That the responsibility is often 116 shared among various players. 118 Also, there are performance issues that are specific to some wireless 119 networks [I-D.manyfolks-gaia-community-networks]. 121 An important effort was conducted by the IETF (e.g., BEHAVE, PCP, 122 Performance Implications of Link Characteristics (pilc)), but we 123 believe further work is still required to mitigate/soften some of the 124 pending issues. 126 Note, 128 o "Middleboxes" or advanced Flow-Aware Service Functions are here to 129 stay, whatever the progress of IPv6 adoption, in particular. 130 o Several experimental TCP extensions have been defined. These 131 extensions (may) have merits when taken individually but further 132 impact analysis is required when they have to co-exist in 133 operational environments. 134 o HTTP/2 protocol ([I-D.ietf-httpbis-http2]) is being mostly 135 implemented using TLS capabilities. 136 o More transport protocols encapsulated over TCP/UDP are being used 137 by applications providers and vendors. Having a standard 138 encapsulation scheme over TCP and UDP, including transport 139 encapsulation recommendations, will help Network Providers fine 140 tune their engineering rules and tweak of their networks. 141 o TCP proxies are widely present in operators architectures, 142 specifically in mobile networks. 144 o Current evolution of transport and multiplexing services impact 145 traffic patterns and optimization features set up to optimize 146 resources and to improve Quality of Experience (QoS). 147 o Some application agents are not strictly following the "hard" 148 limits of connections as indicated for instance in [RFC2068]. 149 o Proposals to relax some of the TCP features (e.g., ordering) or to 150 adopt an efficient byte stuffing schemes should be investigated. 151 o Transport over some media have specific requirements. An update 152 of [RFC3150][RFC3481], for example, would be useful. 153 o Close collaboration and coordination between applications and 154 networks can simplify if not improve network-inferred policy 155 enforcement schemes. Applications may express their transport 156 services requirements while transport protocols can expose, via 157 advanced APIs, the functionalities they are offering and tweaking 158 parameters that can be customized. 159 o Having a standard notification interface between the physical/link 160 layer and the transport layer is likely to improve transport 161 protocol performances in some networks. 163 Network Providers should be able to keep on delivering differentiated 164 services as a competitive business advantage, while mastering the 165 complexity of the applications, (continuously) evaluating the impacts 166 on middleboxes, and enhancing customer's quality of experience. 167 Because every (new) transport protocol will come with its own 168 problems and perfectible features, leveraging skills and experience 169 of TCP design and operation is a first major step for network 170 providers. 172 This document advocates for the definition of transport profiles and 173 the documentation of recommendations for middleboxes, including 174 Performance Enhancement Proxy (PEPs) behaviors. A collaboration 175 among the usual players is required to soften the current 176 complications encountered in the Internet at large. 178 2. On Transport Services 180 Transport services refer to the set of features that are offered by 181 protocols used to multiplex connections over IP. Examples of 182 transport services include - but are not limited to- ordering 183 delivery, reliable delivery, congestion control, or full or partial 184 integrity protection. 186 A transport protocol can be abstracted as an implementation which 187 exposes a set of transport services. For example, TCP (Transmission 188 Control Protocol, [RFC0793]), which is the universally deployed and 189 implemented transport protocol, offers reliable and ordered delivery, 190 flow and congestion control, as well as primitives to manage a 191 connection. Unlike TCP, UDP (User Datagram Protocol, [RFC0768]) is a 192 connectionless protocol that supports protection against data 193 corruption using a checksum field. 195 3. Strategies to Enhance Transport services 197 Given the hurdles induced by advanced network-located service 198 functions, "Make your own protocol" is not even an option. 200 "Encapsulate over your favorite existing protocol", if transported 201 over TCP, has more chances to experience less session failures. 203 This assumes that the remote server is also upgraded to support 204 such transport scheme, while failures are likely to occur when the 205 encapsulation is implemented over UDP. 207 Examples of proposals that follow such mitigation strategy are 208 [I-D.cheshire-tcp-over-udp], or [I-D.iyengar-minion-protocol]. 210 A fallback to TCP (or UDP) must be supported anyway, let alone the 211 complications related to the discovery of the capabilities of the 212 remote server. 214 Even if protocols encapsulated over UDP can make use of NAT 215 traversal techniques, these protocols are still suffering from 216 issues related to the presence of NATs and firewalls. For 217 example, there is no mechanism to notify endpoints that an entry 218 is no more active in the NAT/Firewall. Immediate notification and 219 state recovery can be solved by activating specific Port Control 220 Protocol (PCP) feature: (PCP ANNOUNCE OPCODE, [RFC6887]). 222 The strategy that consists in "extending your favorite widely 223 deployed transport protocol" is more viable from a deployment 224 perspective. 226 TCP can be extended [Options][ExtendTCP]. For example, extensions 227 have been proposed to enhance user's quality of experience when 228 TCP is in use such as: TCP Fast Open ([RFC7413]), Proportional 229 Rate Reduction ([RFC6937]), increase the initial window 230 ([RFC6928]), TCP Extensions for high performance ([RFC7323]), TCP- 231 EDO [I-D.ietf-tcpm-tcp-edo], unordered TCP/TLS, etc. 233 4. Proliferation of Transport Protocols 235 Plethora of transport protocols have been proposed by the Internet 236 community to accommodate requirements raised by emerging 237 applications. Overall, these applications are either requiring more 238 transport services than what is actually offered by TCP and UDP, or 239 less transport services. 241 For example, SCTP (Stream Control Transmission Protocol, [RFC4960]) 242 was specified to accommodate applications which need more transport 243 services than what can be offered by TCP (e.g., preserve 244 (application) data boundaries, support of out-of-order delivery, 245 built-in support of multiple streams). 247 DCCP (Datagram Congestion Control Protocol, [RFC4340]) is another 248 protocol that was promoted to accommodate requirements from 249 applications which need more transport services than what is offered 250 by UDP (e.g., congestion control), but without suffering from the 251 constraints of a connection-oriented protocol like TCP (e.g., 252 reliable delivery mechanisms). 254 UDP-lite ([RFC3828]) is a light version of UDP that was designed for 255 applications that need less features than what is offered by UDP 256 (e.g., partial data corruption detection), whereas DTLS (Datagram 257 Transport Layer Security, [RFC6347]) and TLS ([RFC5246]) were 258 specified for applications requiring encryption capabilities at the 259 transport layer. 261 Other candidate transport protocols are currently investigated to 262 reduce the delay required to invoke a resource located in the 263 Internet. Typically, this consists in retrieving some contents by 264 minimizing the delay induced by TCP or SCTP handshakes required for 265 establishing a connection. Yet, such approaches can take advantage 266 of the transport services provided by connection-oriented protocols. 268 It is worth mentioning that reducing the delay to access a requested 269 resource is not only the responsibility of transport protocols, but 270 also depends on various other services such as DNS and access service 271 functions. The whole chain should be optimized! Reduce the delay 272 when invoking a service objective should be moderated with other 273 considerations such as policy enforcement at the server side 274 (including rate-limit and actions taken to protect against DDoS 275 attacks). 277 5. On TCP Hegemony 279 Despite the effort made by the Internet community to specify new 280 transport protocols or propose improvements of existing ones (mainly 281 TCP), the deployment reality is that TCP remains hegemonic. Even 282 worse, only connections destined to some TCP port numbers are allowed 283 in some networks. 285 Recent studies (e.g., [Traffic]) revealed that TCP accounts for 286 84.35% of the total amount of packets forwarded over the Internet and 287 92% of the bytes. DCCP and SCTP were not found in those studies. 289 The main reasons that explain the poor adoption of new transport- 290 related features at the scale of the Internet are: 292 1. The presence of advanced network-located service functions (used 293 to be called "middelboxes"), and 295 2. The lack of support by OSes. 297 Typical examples of service functions include: traditional NAT 298 (Network Address Translation, [RFC3022]), CGN (Carrier Grade NAT; 299 including IPv4-IPv4 CGN ([RFC6888]), DS-Lite AFTR ([RFC6333]) or 300 NAT64 ([RFC6146])), firewall, application proxies, Performance 301 Enhancement Proxies (PEP, [RFC3135]), traffic uniformizers, etc. 303 Transport-related solutions that assume that the remedy to the 304 problem formulated above would be to withdraw all flow-aware service 305 functions are not realistic. The presence of advanced service 306 functions must be considered by solution designers as the rule rather 307 than the exception. 309 Obviously, this does not mean that network providers should not 310 question the pertinence to maintain some of these service functions 311 active. Even if a rationalization effort is required in this area 312 (still this is deployment-specific), solution designers should 313 propose solutions that are robust in the presence of these functions. 315 6. Need for a Holistic View for TCP Variants 317 For example, variants have been proposed to enhance user's quality of 318 experience when TCP is in use such as: TCP Fast Open ([RFC7413]), 319 Proportional Rate Reduction ([RFC6937]), increase the initial window 320 size ([RFC6928]), TCP Extensions for high performance ([RFC7323]) , 321 unordered TCP/TLS, etc. More can be found in [RFC7414]. 323 These variants may have merits when taken individually, but the 324 question is whether those merits are still valid when co-existing 325 with other features. In addition, these merits are a function of the 326 deployment context (for example in fixed or mobile networks). 328 Implementing small changes at large is here to stay. Moreover, 329 changing a transport protocol stack may is subject to the 330 amplification principle (See Section 2.2.1 of [RFC3439]) since 331 changes may not only have local impacts but may also impact the 332 stability of a network (e.g., MPTCP hosts are more aggressive than 333 TCP hosts). Assessing the impact of these variants on legacy hosts 334 is critical. 336 7. Adoption Rate of TCP Extensions 338 According to [Traffic], 340 o 34% of TCP segments are data-less ACKs. 341 o 94% of SYN use SACK permitted option [RFC2018]. 342 o MSS option in 96% TCP SYNs: A large number of TCP SYN messages 343 advertise an MSS between 1000-1301 bytes (46% announces an MSS 344 between 1300 bytes and 1460 bytes). 345 o Window Scale (WS) option and the TCP Timestamps (TS) [RFC7323] in 346 63.9% of TCP SYNs. 347 o 39.2% uses the TCP Timestamps (TS) [RFC7323] in TCP SYNs. 348 o Zero flows requesting ECN in TCP SYNs. 350 Risks of unordered delivery is often design-specific. Indeed, 351 [Traffic] also showed that disordering is deployment-specific 352 (because it was observed only in some networks); means that lead to 353 such behavior should be disabled in those networks. This suggests 354 reliable means to minimize such risks. 356 This data shows that several of TCP advances (e.g., WS) are not 357 massively deployed or not deployed at all (e.g., ECN). A recent 358 study about the support of ECN is available at [ECN]. 360 More effort is required to evangelize recent TCP advances and their 361 motivations. 363 8. A Network Provider's Perspective 365 8.1. Proposed Approach 367 Fortunately, there is still an opportunity for network providers to 368 contribute to the improvement of transport services. A technical 369 strategy that would focus on the root causes to properly derive 370 associated recommendations should be encouraged. 372 Every (new) transport protocol will come with its own problems and 373 perfectible features. Too many transport protocols are really 374 painful for all actors, including for network operators (think about 375 the configuration of class of services, fairness access and usage of 376 network resources, and other traffic management services). 378 Leveraging skills and experience of TCP design as well as operation 379 is a first major step for network providers. For example, in order 380 to reduce latency for TCP-based applications, the following technical 381 tracks can be investigated: 383 1. Deactivate ordering management; 384 2. Consider efficient byte stuffing schemes; 386 3. Get rid of the Three-Way Handshake; or 388 4. Consider persistent connections whenever suitable. 390 Network Providers should be able to keep on delivering differentiated 391 services as a competitive business advantage, while mastering the 392 complexity of the applications and enhancing customer's quality of 393 experience. This can be achieved by exposing and communicating 394 reachability information (i.e., routes to access desired contents) 395 that will foster session establishment. This can be achieved using 396 dedicated interfaces that can be used by applications. 398 Reduce complexity at the application level, strengthen the 399 collaboration between the applications and the network layer via 400 clear interfaces should also be encouraged, but this may be subject 401 to agreements. Administrative-related considerations are out of 402 scope of this document. 404 8.2. Some Risks: 406 From a network provider perspective, the following risks need to be 407 taken into account when designing solution(s) that would enhance 408 current transport services: 410 o Emergence of transport-specific proxies given that vendors promote 411 their own transport protocols. 413 o In addition to the support of a fallback mode to TCP (or UDP), 414 some of the proposals may lead to complex clients (application 415 agents). This complexity should be avoided because this is likely 416 to be a source of performance degradation, especially when other 417 sophisticated features are required. 419 o Performance Enhancing Proxies are currently the rule to optimize 420 TCP, especially in mobile networks. There is a need to agree on a 421 TCP Profile, including required features to be supported by TCP 422 acceleration engines (a.k.a., PEPs). 424 o Offloading some of the transport functions to the upper layers may 425 be suitable for some cases (e.g., error detection) but this 426 approach suffers from side effects such as buffering issues at the 427 application level, potential misuse of the underlying transport 428 service, complexity to diagnose degradation when it occurs, 429 battery consumption for mobile devices because of frequent 430 keepalives, etc.). 432 According to [Power], the consumption of a mobile device with a 433 keep-alive interval of 20 seconds (that is the default value) is 434 29 mA (2G)/34 mA (3G). When no keep-alive is issued, the 435 consumption would be 5.2 mA (2G)/6.1 mA (3G). 437 o Covert channels can be made possible if encapsulation schemes are 438 allowed without any security features. 440 o The accuracy of the engineering and tuning of network devices for 441 an optimized service delivery may be impacted by the variety of 442 traffic profiles, and, especially the change of the transport 443 behavior (e.g., aggressive vs. other flows, fairness to make use 444 of network resources, etc.). 446 o Path diversity (e.g., be able to establish a TCP communication 447 over different paths for the sake of optimized bandwidth usage) 448 becomes a typical requirement given the current adoption rate of 449 multi-interfaced devices. 451 Networks can cooperate with applications to help selecting the 452 best path(s) but diverse transport protocols can provoke service 453 disruption when the device re-connects to another network (e.g., 454 via a WLAN Hotspot, mobile, CPE, etc.), where network-assisted 455 functions are hosted. 457 9. Previous IETF Works 459 Some recommendations to improve transport services have been 460 documented for quite some time (e.g., [RFC4787], [RFC5382]). 462 Such recommendations are related to the design and the operation of 463 services in the presence of flow-aware devices (in particular, NATs). 464 A few examples: the use of endpoint-independent NAT mapping (EIM) and 465 filtering (EIF) behaviors, IP address pooling behavior of "Paired" to 466 not break protocols such as RTP/RTCP, the selection of long mapping 467 lifetime values to avoid breaking some applications, the preservation 468 of port parity for RTP/RTCP-based applications (like VoIP), the 469 preservation of port contiguity for some applications, the use of 470 port randomness to avoid session hijacking, the ability to discover 471 the external IP address/port/lifetime ([RFC6887]) so that 472 applications with referral behave with no degradation, the analysis 473 of the use of the HOST_ID ([RFC6967]) to soften issues induced by 474 address sharing at large ([RFC6269]), etc. 476 An effort to clarify some of the behave requirements is ongoing 477 ([I-D.ietf-tsvwg-behave-requirements-update]). 479 Also, the Performance Implications of Link Characteristics (pilc) WG 480 conducted an important effort which led to 481 [RFC3135][RFC3150][RFC3155][RFC3366][RFC3449][RFC3481][RFC3819]. 483 10. What's Next? 485 The following candidate actions are proposed (non-exhaustive list): 487 o Define a TCP profile for hosts. This profile can be an update of 488 [RFC1122]. Or not. 490 o Update PEP recommendations. Edit a BCP document about TCP 491 extensions to be supported by middleboxes vendors and activated by 492 operators. 494 E.g., Update the header compression features recommended in 495 [RFC3150] to include [RFC4996]. 497 o Specify a MPTCP Profile in network regions that are firewall- and 498 NAT-free: One of the promising deployment scenario for MPTCP 499 ([RFC6824]) is to aggregate the resources offered by a CPE that is 500 connected to multiple networks (e.g., DSL, LTE, WLAN), see for 501 example [I-D.deng-mptcp-proxy] or 502 [I-D.lhwxz-hybrid-access-network-architecture]. 504 This deployment scenario requires a kind of "concentrator" at the 505 network side to terminate the aggregated session before relaying 506 it into a legacy TCP session. The concentrator is needed before 507 the adoption rate of MPTCP at the server side is taking. 509 Because the paths between the CPE and the concentrator are 510 firewall- and NAT-free, the complexity of the MPTCP specification 511 that was initially induced by handling the presence of firewalls 512 and the routing asymmetry, is not justified anymore. Such context 513 encourages the specification of a dedicated MPTCP profile that 514 would in turn foster the adoption of MPTCP. 516 o Standardize encapsulation schemes over TCP and UDP. 518 11. IANA Considerations 520 This document makes no request of IANA. 522 12. Security Considerations 524 Add some text about privacy and security. 526 13. Acknowledgements 528 Many thanks to J. Touch for the comments. 530 14. Informative References 532 [ECN] B. Trammell, M. Kuehlewind, D. Boppart, I. Learmonth, G. 533 Fairhurst, and R. Scheffenegger, "Enabling Internet-Wide 534 Deployment of Explicit Congestion Notification", 2015, 535 . 537 [ExtendTCP] 538 Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 539 Handley, M. and H. Tokuda,, "Is it still possible to 540 extend TCP?", November 2011, 541 . 543 [I-D.cheshire-tcp-over-udp] 544 Cheshire, S., Graessley, J., and R. McGuire, 545 "Encapsulation of TCP and other Transport Protocols over 546 UDP", draft-cheshire-tcp-over-udp-00 (work in progress), 547 July 2013. 549 [I-D.deng-mptcp-proxy] 550 Lingli, D., Liu, D., Sun, T., Boucadair, M., and G. 551 Cauchie, "Use-cases and Requirements for MPTCP Proxy in 552 ISP Networks", draft-deng-mptcp-proxy-01 (work in 553 progress), October 2014. 555 [I-D.ietf-httpbis-http2] 556 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 557 Protocol version 2", draft-ietf-httpbis-http2-17 (work in 558 progress), February 2015. 560 [I-D.ietf-tcpm-tcp-edo] 561 Touch, J. and W. Eddy, "TCP Extended Data Offset Option", 562 draft-ietf-tcpm-tcp-edo-01 (work in progress), October 563 2014. 565 [I-D.ietf-tsvwg-behave-requirements-update] 566 Penno, R., Perreault, S., Kamiset, S., Boucadair, M., and 567 K. Naito, "Network Address Translation (NAT) Behavioral 568 Requirements Updates", draft-ietf-tsvwg-behave- 569 requirements-update-01 (work in progress), February 2015. 571 [I-D.iyengar-minion-protocol] 572 Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire 573 Protocol", draft-iyengar-minion-protocol-02 (work in 574 progress), October 2013. 576 [I-D.lhwxz-hybrid-access-network-architecture] 577 Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. 578 Zhang, "Hybrid Access Network Architecture", draft-lhwxz- 579 hybrid-access-network-architecture-02 (work in progress), 580 January 2015. 582 [I-D.manyfolks-gaia-community-networks] 583 Saldana, J., Arcia-Moret, A., Braem, B., Navarro, L., 584 Pietrosemoli, E., Rey-Moreno, C., Sathiaseelan, A., and M. 585 Zennaro, "Alternative Network Deployments. Taxonomy and 586 characterization", draft-manyfolks-gaia-community- 587 networks-02 (work in progress), January 2015. 589 [Options] Alberto Medina, Mark Allman, Sally Floyd, "Measuring 590 Interactions Between Transport Protocols and Middleboxes", 591 2005, . 594 [Power] Haverinen, H., Siren, J., and P. Eronen, "Energy 595 Consumption of Always-On Applications in WCDMA Networks", 596 April 2007, . 599 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 600 August 1980. 602 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 603 793, September 1981. 605 [RFC1122] Braden, R., "Requirements for Internet Hosts - 606 Communication Layers", STD 3, RFC 1122, October 1989. 608 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 609 Selective Acknowledgment Options", RFC 2018, October 1996. 611 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 612 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 613 RFC 2068, January 1997. 615 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 616 Address Translator (Traditional NAT)", RFC 3022, January 617 2001. 619 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 620 Shelby, "Performance Enhancing Proxies Intended to 621 Mitigate Link-Related Degradations", RFC 3135, June 2001. 623 [RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, 624 "End-to-end Performance Implications of Slow Links", BCP 625 48, RFC 3150, July 2001. 627 [RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. 628 Vaidya, "End-to-end Performance Implications of Links with 629 Errors", BCP 50, RFC 3155, August 2001. 631 [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on 632 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, 633 August 2002. 635 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 636 Guidelines and Philosophy", RFC 3439, December 2002. 638 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 639 Sooriyabandara, "TCP Performance Implications of Network 640 Path Asymmetry", BCP 69, RFC 3449, December 2002. 642 [RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and 643 F. Khafizov, "TCP over Second (2.5G) and Third (3G) 644 Generation Wireless Networks", BCP 71, RFC 3481, February 645 2003. 647 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 648 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 649 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 650 RFC 3819, July 2004. 652 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 653 G. Fairhurst, "The Lightweight User Datagram Protocol 654 (UDP-Lite)", RFC 3828, July 2004. 656 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 657 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 659 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 660 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 661 RFC 4787, January 2007. 663 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 664 4960, September 2007. 666 [RFC4996] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 667 "RObust Header Compression (ROHC): A Profile for TCP/IP 668 (ROHC-TCP)", RFC 4996, July 2007. 670 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 671 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 673 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 674 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 675 RFC 5382, October 2008. 677 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 678 NAT64: Network Address and Protocol Translation from IPv6 679 Clients to IPv4 Servers", RFC 6146, April 2011. 681 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 682 Roberts, "Issues with IP Address Sharing", RFC 6269, June 683 2011. 685 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 686 Stack Lite Broadband Deployments Following IPv4 687 Exhaustion", RFC 6333, August 2011. 689 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 690 Security Version 1.2", RFC 6347, January 2012. 692 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 693 "TCP Extensions for Multipath Operation with Multiple 694 Addresses", RFC 6824, January 2013. 696 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 697 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 698 2013. 700 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 701 and H. Ashida, "Common Requirements for Carrier-Grade NATs 702 (CGNs)", BCP 127, RFC 6888, April 2013. 704 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 705 "Increasing TCP's Initial Window", RFC 6928, April 2013. 707 [RFC6937] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional 708 Rate Reduction for TCP", RFC 6937, May 2013. 710 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 711 "Analysis of Potential Solutions for Revealing a Host 712 Identifier (HOST_ID) in Shared Address Deployments", RFC 713 6967, June 2013. 715 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 716 Scheffenegger, "TCP Extensions for High Performance", RFC 717 7323, September 2014. 719 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 720 Fast Open", RFC 7413, December 2014. 722 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 723 Zimmermann, "A Roadmap for Transmission Control Protocol 724 (TCP) Specification Documents", RFC 7414, February 2015. 726 [Traffic] David Murray, Terry Koziniec, "The State of Enterprise 727 Network Traffic in 2012", 2012, 728 . 731 Authors' Addresses 733 Mohamed Boucadair 734 France Telecom 735 Rennes 35000 736 France 738 Email: mohamed.boucadair@orange.com 740 David Binet 741 France Telecom 742 Rennes 35000 743 France 745 Email: david.binet@orange.com 747 Christian Jacquenet 748 France Telecom 749 Rennes 750 France 752 Email: christian.jacquenet@orange.com 753 Luis M. Contreras 754 Telefonica I+D 755 Ronda de la Comunicacion, s/n 756 Madrid 28050 757 Spain 759 Email: lmcm@tid.es 760 URI: http://people.tid.es/LuisM.Contreras/ 762 Yiu Lee 763 Comcast 764 US 766 Email: Yiu_Lee@Cable.Comcast.com