idnits 2.17.1 draft-arkko-arch-low-latency-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2486 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-dunbar-e2e-latency-arch-view-and-gaps-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-04 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-13 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational J. Tantsura 5 Expires: January 4, 2018 Futurewei, Future Networks 6 July 3, 2017 8 Low Latency Applications and the Internet Architecture 9 draft-arkko-arch-low-latency-01 11 Abstract 13 Some recent Internet technology developments relate to improvements 14 in communications latency. For instance, improvements in radio 15 communications or the recent work in IETF transport, security, and 16 web protocols. There are also potential applications where latency 17 would play a more significant role than it has traditionally been in 18 the Internet communications. Modern networking systems offer many 19 tools for building low-latency networks, from highly optimised 20 individual protocol components to software controlled, virtualised 21 and tailored network functions. This memo views the developments 22 from a system viewpoint, and considers the potential future stresses 23 that the strive for low-latency support for applications may bring. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 4, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Applications with Special Focus on Low Latency . . . . . . . 3 61 3. Role of Low-Latency vs. Other Communications . . . . . . . . 4 62 4. Selected Improvements to Communications Latency . . . . . . . 5 63 5. Architectural Considerations . . . . . . . . . . . . . . . . 5 64 5.1. Background . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Implications . . . . . . . . . . . . . . . . . . . . . . 7 66 5.2.1. Service Distribution . . . . . . . . . . . . . . . . 7 67 5.2.2. Edge Computing . . . . . . . . . . . . . . . . . . . 8 68 5.2.3. Routing and tunnels . . . . . . . . . . . . . . . . . 8 69 5.2.4. Alternative Paths and Control Tension . . . . . . . . 8 70 5.2.5. Cross-Layer Optimisations . . . . . . . . . . . . . . 9 71 5.3. Recommendations for Further Work . . . . . . . . . . . . 10 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 73 7. Informative References . . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 Some recent Internet technology developments relate to improvements 79 in communications latency. For instance, improvements in radio 80 communications or the recent work in IETF transport, security, and 81 web protocols. 83 There are also potential applications where latency would play a more 84 significant role than it has traditionally been in the Internet 85 communications. 87 New applications or technologies do not necessarily imply that 88 latency should be the main driving concern, or that any further 89 efforts are needed, beyond those already ongoing. Indeed, modern 90 networking systems offer many tools for building low-latency 91 networks, across the stack. At the IETF, for instance, there has 92 been a recent increase in work related to transport, security, and 93 web application protocols, in part to make significant improvements 94 in latency and connection set-up times. Similar efforts for other 95 components of communications technology exist in 3GPP, IEEE, and 96 other standards organisations. 98 Despite a large number of specific developments, it may be 99 interesting to view the developments from a system viewpoint, and to 100 consider the potential future stresses that the strive for low- 101 latency support applications may bring. 103 The rest of this memo is organised as follows: Section 2 discusses 104 potential applications for low-latency communications. Section 4 105 reviews some of the recent work across the stack, related to latency 106 improvements. Finally, Section 5 discusses some of the implications 107 (and non-implications) from an architectural perspective. 109 2. Applications with Special Focus on Low Latency 111 Most Internet applications enjoy significant benefits from low- 112 latency communications in the form of faster setup and response times 113 as well as higher bandwidth communications enabled by transport 114 protocol behaviour [RFC7323]. 116 There are also potential applications where latency would play an 117 even more significant role. For instance, embedding communications 118 technology in automation or traffic systems, or consumer applications 119 such as augmented or virtual reality where due to the human brain's 120 perceptual limits variability in latency may not be feasible, i.e., 121 render the service unusable due to motion sickness caused. 123 Many of the Internet-of-Things and critical services use cases in 5G, 124 for instance, have been listed as requiring low latency and high 125 reliability for communications [ER2015] [HU2015] [NGMN2015] [NO2015] 126 [QU2016] [IMT2020]. 128 Some example use cases include optimisation of utility services such 129 as electricity networks, connected automation systems in factories, 130 remote control of machinery such as mining equipment, or embedded 131 technology in road or railway traffic. 133 The different applications vary in terms of their needs. Some may be 134 very focused on high-speed local area communication, others need to 135 connect at optimal speed over a wide-area network, and yet others 136 need to find the right ways to provide global services without 137 incurring unreasonable delays. 139 For these reasons it is difficult to specify what "low latency" means 140 in terms of specific delays. Applications and network scenarios 141 differ. Reaching a 50ms latency may be enough for some applications 142 while others may require 50us. Obviously, latency is ultimately 143 limited by physics, location, and topology. Individual link 144 characteristics are important, but system level communication needs 145 both in terms of what is being communicated and between what parties 146 matter more. 148 Note that when we say "low-latency capabilities", there is no intent 149 to imply any specific implementation of those capabilities. In 150 particular, we look at the low-latency requirements from a broader 151 perspective than Quality-of-Service guarantees or separating traffic 152 onto different classes. Indeed, while today's virtualisation and 153 software-driven technologies give us more tools to deal with those 154 kinds of arrangements as well, past experience on deploying Quality- 155 of-Service mechanisms in the Internet should give us a pause 156 [CC2015]. 158 It is not the purpose of this memo to analyse the application 159 requirements for low-latency applications much further; for our 160 purposes it suffices to note that there are applications that are 161 enabled by low-latency capabilities of the underlying network 162 infrastructure. 164 3. Role of Low-Latency vs. Other Communications 166 There are some limited applications that rely solely on local 167 communication. One example of such an application is vehicles 168 communicating braking status to nearby ones. 170 Also, while many applications run in the global Internet, some are 171 designed for specialised networks that may not have full or even any 172 Internet connectivity, but yet use IP technology. 174 However, many applications will include also wide-area communication. 175 If the factory automation machines are not talking other than with 176 themselves, at least their control systems are doing so in order to 177 ensure parts orders, monitoring and maintenance by equipment 178 manufacturers, and so on. This does not imply that these perhaps 179 critical applications are openly accessible from the Internet, but 180 many of them are likely to communicate outside their immediate 181 surroundings. 183 Many applications also rely on wide-area connectivity for software 184 updates. 186 As a result, this document recommends that when building 187 architectures for low-latency applications it is important to take 188 into account that these applications can also benefit from 189 communications elsewhere. Or at the very least, the existence of a 190 specialised communications link or network should not be immediately 191 taken to mean that no other communications are needed. 193 4. Selected Improvements to Communications Latency 195 It should be noted that latency is a very broad topic in 196 communications protocol design, almost as broad as "security", or 197 even "correctness". 199 Implementation techniques to satisfy these requirements vary, some 200 applications can be built with sufficient fast local networking 201 capabilities, others may require, for instance, building world-wide, 202 distributed content delivery mechanisms. 204 Modern networking systems offer many tools for building low-latency 205 networks, across the stack. from highly optimised individual protocol 206 components [I-D.ietf-tls-tls13] [I-D.ietf-quic-transport] [RFC7413] 207 [RFC7540] to software controlled, virtualised and tailored network 208 functions [NFV2012] [RFC7665] [I-D.ietf-sfc-nsh] [OF2008]. Data- and 209 software-driven network management and orchestration tools enable 210 networks to be built to serve particular needs as well as to optimize 211 workload placement in a way low-latency requirements could be met. 213 Across the stack there are also many other tools, as well as tools 214 being in development, e.g., a new transport design [L4S] at the IETF. 216 On the lower layers, improvements in radio communications are being 217 made. For instance, the IEEE 802.1 Time-Sensitive Networking Task 218 Group [TSN8021] has worked to define precise time synchronization 219 mechanisms for a local area network, and scheduling mechanisms to 220 enable different classes of traffic to use the same network while 221 minimising jitter and latency. At the IETF, the DETNET working group 222 is taking these capabilities and applying them for layer 3 networking 223 [DETNET]. 225 The 3GPP 5G requirements for next-generation access technology are 226 stringent, and are leading to the optimization of the radio 227 interfaces. The requirements specify a one-way latency limit of 228 0.5ms for ultra-reliable low-latency communications [TS38913]. But 229 again, mere latency numbers mean very little without the context of a 230 system and what an application needs to communicate and with whom. 232 5. Architectural Considerations 234 Despite a large number of specific developments, it may be 235 interesting to view the developments from a system viewpoint, and to 236 consider the potential future stresses that the strive for low- 237 latency support for applications may bring. 239 5.1. Background 241 To begin with, it may be useful to observe that the requirements and 242 developments outlined above do not necessarily imply that any 243 specific new technology is needed or that the nature of 244 communications in the Internet would somehow fundamentally change. 245 And certainly not that latency should be the only or primary concern 246 in technology development. 248 With the drive for a new class of applications, there is often an 249 expectation that this means significant changes. However, all 250 changes need to stand on their own, be justifiable and deployable on 251 a global network. For instance, the discussion around the 252 introduction of the newest 4K or 8K high-definition video streaming 253 applications is reminiscent of the discussions about the introduction 254 of VoIP applications in the Internet. At the time, there was some 255 expectation that special arrangements and Quality-of-Service 256 mechanisms might be needed to support this new traffic class. This 257 turned out to be not true, at least not in general networks. 259 Experience tells us, for instance, that deploying Quality-of-Service 260 mechanisms in the Internet is hard, not so much because of the 261 technology itself, but due to lack of forces that would be able to 262 drive the necessary business changes in the ecosystem for the 263 technology to be feasibly deployable [CC2015]. As claffy and Clark 264 note: 266 "Although the Internet has a standards body (the IETF) to resolve 267 technical issues, it lacks any similar forum to discuss business 268 issues such as how to allocate revenues among competing ISPs 269 offering enhanced services. In the U.S., ISPs feared such 270 discussions would risk anti-trust scrutiny. Thus, lacking a way 271 to negotiate the business implications of QoS, it was considered a 272 cost rather than a potential source of revenue. Yet, the 273 relentless growth of a diversity of applications with widely 274 varying performance requirements continued on the public Internet, 275 with ISPs using relatively primitive, and not always completely 276 benign, mechanisms for handling them." 278 These difficulties should not be read as prohibiting all changes. Of 279 course, change can also seem unlikely even in cases where it becomes 280 absolutely necessary or the forces necessary to make a change have 281 actually built up. As a result, statements regarding change in the 282 Internet should be carefully evaluated on their merits from both 283 technical and ecosystem perspective. 285 Secondly, we often consider characteristics from a too narrow 286 viewpoint. In the case of latency, it is easy to focus on a 287 particular protocol or link, whereas from the user perspective 288 latency is a property of the system, not a property of an individual 289 component. 291 For instance, improvements on the performance of one link on a 292 communications path can be insignificant, if the other parts make up 293 a significant fraction of the system-level latency. That may seem 294 obvious, but many applications are highly dependent on communications 295 between a number of different parties which may reside in different 296 places. For instance, a third party may perform authentication for a 297 cloud-based service that also interacts with user's devices and a 298 number of different sensors and actuators. 300 We cannot change the speed of light, and a single exchange with 301 another part of the world may result in a 100ms delay, or about 200 302 times longer than the expected 5G radio link delay for critical 303 applications. It is clear that designing applications from a system 304 perspective is very important. 306 5.2. Implications 308 This section discusses a selected set of architectural effects and 309 design choices within applications that desire low latency 310 communications. 312 5.2.1. Service Distribution 314 As noted above, low-latency applications need to pay particular 315 attention to the placement of services in the global network. 316 Operations that are on the critical path for the low-latency aspects 317 of an application are unlikely to work well if those communications 318 need to traverse half of the Internet. 320 Many widely used services are already distributed and replicated 321 throughout the world, to minimise communications latency. But many 322 other services are not distributed in this manner. For low-latency 323 applications such distribution becomes necessary. Hosting a global 324 service in one location is not feasible due to latency, even when 325 from a scale perspective a single server might otherwise suffice for 326 the service. All major public cloud providers offer CDN services to 327 their customers - AWS's CloudFront, Google's Cloud CDN and Azure's 328 CDN to mention a few. 330 Content-Delivery Networks (CDNs) and similar arrangements are likely 331 to flourish because of this. These arrangements can bring content 332 close to end-users, and have a significant impact on latency. 333 Typical CDN arrangements provide services that are on a global scale 334 nearby, e.g., in the same country or even at the ISP's datacenter. 336 Today's CDNs are of course just one form of distributed service 337 implementation. Previous generations, such as web caching, have 338 existed as well, and it is likely that the current arrangements will 339 evolve in the future. CDN evolution is also naturally affected not 340 only by the need to provide services closer to the user, but also 341 through the fine-grained control and visibility mechanisms that it 342 gives to the content owners. Such factors continue to affect also 343 future evolution, e.g., any information-centric networking solutions 344 that might emerge. 346 5.2.2. Edge Computing 348 Recent advances in "edge computing" take the more traditional type 349 service like CDN as well as a new class of services that require 350 "local compute" capabilities placement even further by providing 351 services near the users. This would enable more extreme uses cases 352 where latency from, say, ISP datacenter to the users is considered 353 too high. An important consideration is what is considered an edge, 354 however. From Internet perspective edge usually refers to the IP 355 point of presence or the first IP hop. But given the centralised 356 nature of many access networks, some of the discussions around the 357 use of edge computing also involve components at the edge that are 358 much closer to user than the first IP hop. Special arrangements are 359 needed to enable direct IP connectivity from the user equipment to 360 these components. 362 5.2.3. Routing and tunnels 364 How the communications are routed also matters. For instance, 365 architectures based on tunneling to a central point may incur extra 366 delay. One way to address this pressure is to use SDN- and 367 virtualisation-based networks that can be provisioned in the desired 368 manner, so that, for instance, instances of tunnel servers can be 369 placed in the topologically optimal place for a particular 370 application. 372 5.2.4. Alternative Paths and Control Tension 374 Recent developments in multipath transport protocols [RFC6824] also 375 provide application- and service-level control of some of the 376 networking behaviour. Similar choices among alternative paths also 377 exist in simpler techniques, ranging from server selection algorithms 378 to IPv6 "Happy Eyeballs" algorithms [RFC6555]. In all of these cases 379 an application makes some observations of the environment and decides 380 to use an alternative path or target that is perceived to be best 381 suited for the application's needs. 383 In all of these multipath and alternative selection techniques there 384 is tension between application control (often by content providers) 385 and network control (often by network operators). 387 One special case where that tension has appeared in the past is 388 whether there should be ways to provide information from applications 389 to networks on how packets should be treated. This was extensively 390 discussed during the discussion stemming from implications of 391 increased use of encryption in the Internet, and how that affects 392 operators [I-D.nrooney-marnew-report]. 394 Another case where there is tension is between mechanisms designed 395 for a single link or network vs. end-to-end mechanisms. Many of the 396 stated requirements for low-latency applications are explicitly about 397 end-to-end characteristics and capabilities. Yet, the two mechanisms 398 are very different, and most of the deployment difficulties reported 399 in [CC2015] relate to end-to-end mechanisms. 401 Note that some of the multipath techniques can be used either by 402 endpoints or by the network. Proxy-based Multipath TCP is one 403 example of this [I-D.boucadair-mptcp-plain-mode]. 405 5.2.5. Cross-Layer Optimisations 407 In the search for even faster connection setup times one obvious 408 technique is cross-layer optimisation. We have seen some of this in 409 the IETF in the rethinking of the layers for transport, transport 410 layer security, and application framework protocols. By taking into 411 account the protocol layer interactions or even bundling the protocol 412 design together, it is relatively easy to optimise the connection 413 setup time, as evidenced by recent efforts to look for "0-RTT" 414 designs in various protocols. 416 But while cross-layer optimisation can bring benefits, it also has 417 downsides. In particular, it connects different parts of the stack 418 in additional ways. This can lead to difficulties in further 419 evolution of the technology, if done wrong. 421 In the case of the IETF transport protocol evolution, significant 422 improvements were made to ensure better evolvability of the 423 protocols than what we've experienced with TCP, starting from an 424 ability to implement the new protocols in applications rather than 425 in the kernel. 427 While the connection setup is an obvious example, cross-layer 428 optimisations are not limited to them. Interfaces between 429 application, transport, networking, and link layers can provide 430 information and set parameters that improve latency. For instance, 431 setting DSCP values or requesting a specialised L2 service for a 432 particular application. Cross-Layer optimisations between lower 433 layers will be discussed in the upcoming versions of the draft. 435 The effects of badly designed cross-layer optimisation are a 436 particular form of Internet ossification. The general networking 437 trend, however, is for greater flexibility and programmability. 438 Arguably, the ease at which networks can evolve is probably even more 439 important than their specific characteristics. 441 These comments about cross-layer optimisation should not be 442 interpreted to mean that protocol design should not take into account 443 how other layers behave. The IETF has a long tradition of discussing 444 link layer design implications for Internet communications (see, 445 e.g., the results of the PILC working group [RFC3819]. 447 5.3. Recommendations for Further Work 449 Low-latency applications continue to be a hot topic in networking. 450 The following topics in particular deserve further work from an 451 architectural point of view: 453 o Application architectures for globally connected but low-latency 454 services. 456 o What are the issues with inter-domain Quality-of-Service 457 mechanisms? Are there approaches that would offer progress on 458 this field? 460 o Network architectures that employ tunneling, and mitigations 461 against the delay impacts of tunnels (such as tunnel server 462 placement or "local breakout" techniques). Low latency often 463 implies high reliability, special care is to be taken of network 464 convergence, and other, relevant characteristics of the underlying 465 infrastructure. 467 o The emergence of cross-layer optimisations and how that affects 468 the Internet architecture and its future evolution. 470 o Inter-organisatorial matters, e.g., to what extent different 471 standards organisations need to talk about low latency effects and 472 ongoing work, to promote system-level understanding? 474 Overall, this memo stresses the importance of the system-level 475 understanding of Internet applications and their latency issues. 476 Efforts to address specific sub-issues are unlikely to be fruitful 477 without a holistic plan. 479 In the authors' opinion, the most extreme use cases (e.g., 1ms or 480 smaller latencies) are not worth building general-purpose networks 481 for. But having the necessary tools so that networks can be flexible 482 for the more general cases is very useful, as there are many 483 applications that can benefit from the added flexibility. The key 484 tools for this include ability to manage network function placement 485 and topology. 487 6. Acknowledgements 489 The author would like to thank Brian Trammell, Mirja Kuehlewind, 490 Linda Dunbar, Goran Rune, Ari Keranen, James Kempf, Stephen Farrell, 491 Mohamed Boucadair, Kumar Balachandran, Goran AP Eriksson, and many 492 others for interesting discussions in this problem space. 494 The author would also like to acknowledge the important contribution 495 that [I-D.dunbar-e2e-latency-arch-view-and-gaps] made in this topic. 497 7. Informative References 499 [CC2015] claffy, kc. and D. Clark, "Adding Enhanced Services to the 500 Internet: Lessons from History", September 2015 501 (https://www.caida.org/publications/papers/2015/ 502 adding_enhanced_services_internet/ 503 adding_enhanced_services_internet.pdf). 505 [DETNET] "Deterministic Networking (DETNET) Working Group", March 506 2016 (https://tools.ietf.org/wg/detnet/charters). 508 [ER2015] Yilmaz, O., "5G Radio Access for Ultra-Reliable and Low- 509 Latency Communications", Ericsson Research Blog, May 2015 510 (https://www.ericsson.com/research-blog/5g/5g-radio- 511 access-for-ultra-reliable-and-low-latency- 512 communications/). 514 [HU2015] "5G Vision: 100 Billion connections, 1 ms Latency, and 10 515 Gbps Throughput", Huawei 2015 516 (http://www.huawei.com/minisite/5g/en/defining-5g.html). 518 [I-D.boucadair-mptcp-plain-mode] 519 Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, 520 D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 521 Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., 522 Contreras, L., and B. Peirens, "Extensions for Network- 523 Assisted MPTCP Deployment Models", draft-boucadair-mptcp- 524 plain-mode-10 (work in progress), March 2017. 526 [I-D.dunbar-e2e-latency-arch-view-and-gaps] 527 Dunbar, L., "Architectural View of E2E Latency and Gaps", 528 draft-dunbar-e2e-latency-arch-view-and-gaps-01 (work in 529 progress), March 2017. 531 [I-D.ietf-quic-transport] 532 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 533 and Secure Transport", draft-ietf-quic-transport-04 (work 534 in progress), June 2017. 536 [I-D.ietf-sfc-nsh] 537 Quinn, P. and U. Elzur, "Network Service Header", draft- 538 ietf-sfc-nsh-13 (work in progress), June 2017. 540 [I-D.ietf-tls-tls13] 541 Rescorla, E., "The Transport Layer Security (TLS) Protocol 542 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 543 April 2017. 545 [I-D.nrooney-marnew-report] 546 Rooney, N., "IAB Workshop on Managing Radio Networks in an 547 Encrypted World (MaRNEW) Report", draft-nrooney-marnew- 548 report-03 (work in progress), June 2017. 550 [IMT2020] "Framework and overall objectives of the future 551 development of IMT for 2020 and beyond", ITU 552 Recommendation M.2083-0, September 2015 553 (http://www.itu.int/rec/R-REC-M.2083-0-201509-I/en). 555 [L4S] "Low Latency Low Loss Scalable throughput (L4S) Birds-of- 556 Feather Session", July 2016 557 (https://datatracker.ietf.org/wg/l4s/charter/). 559 [NFV2012] "Network Functions Virtualisation - Introductory White 560 Paper", ETSI, 561 http://portal.etsi.org/NFV/NFV_White_Paper.pdf, October 562 2012. 564 [NGMN2015] 565 "5G White Paper", NGMN Alliance, February 2015 566 (https://www.ngmn.org/fileadmin/ngmn/content/downloads/ 567 Technical/2015/NGMN_5G_White_Paper_V1_0.pdf). 569 [NO2015] Doppler, K., "5G the next major wireless standard", DREAMS 570 Seminar, January 2015 571 (https://chess.eecs.berkeley.edu/pubs/1084/doppler- 572 DREAMS_5G_jan15.pdf). 574 [OF2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., 575 Peterson, L., Rexford, J., Shenker, S., and J. Turner, 576 "OpenFlow: Enabling Innovation in Campus Networks", ACM 577 SIGCOMM Computer Communication Review, Volume 38, Issue 2, 578 pp. 69-74 2008. 580 [QU2016] "Leading the world to 5G", Qualcomm, February 2016 581 (https://www.qualcomm.com/media/documents/files/qualcomm- 582 5g-vision-presentation.pdf). 584 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 585 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 586 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 587 RFC 3819, DOI 10.17487/RFC3819, July 2004, 588 . 590 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 591 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 592 2012, . 594 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 595 "TCP Extensions for Multipath Operation with Multiple 596 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 597 . 599 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 600 Scheffenegger, Ed., "TCP Extensions for High Performance", 601 RFC 7323, DOI 10.17487/RFC7323, September 2014, 602 . 604 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 605 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 606 . 608 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 609 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 610 DOI 10.17487/RFC7540, May 2015, 611 . 613 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 614 Chaining (SFC) Architecture", RFC 7665, 615 DOI 10.17487/RFC7665, October 2015, 616 . 618 [TS38913] "3rd Generation Partnership Project; Technical 619 Specification Group Radio Access Network; Study on 620 Scenarios and Requirements for Next Generation Access 621 Technologies; (Release 14)", 3GPP Technical Report TR 622 38.913 V14.2.0, March 2017 623 (https://portal.3gpp.org/desktopmodules/Specifications/ 624 SpecificationDetails.aspx?specificationId=2996). 626 [TSN8021] "Time-Sensitive Networking Task Group", IEEE 627 (http://www.ieee802.org/1/pages/tsn.html). 629 Authors' Addresses 631 Jari Arkko 632 Ericsson 633 Kauniainen 02700 634 Finland 636 Email: jari.arkko@piuha.net 638 Jeff Tantsura 639 Futurewei, Future Networks 641 Email: jefftant.ietf@gmail.com