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