idnits 2.17.1 draft-arkko-arch-low-latency-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 : ---------------------------------------------------------------------------- ** 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 (May 15, 2017) is 2538 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-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 == Outdated reference: A later version (-03) exists of draft-nrooney-marnew-report-02 -- 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 (~~), 6 warnings (==), 3 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 May 15, 2017 5 Expires: November 16, 2017 7 Low Latency Applications and the Internet Architecture 8 draft-arkko-arch-low-latency-00 10 Abstract 12 Some recent Internet technology developments relate to improvements 13 in communications latency. For instance, improvements in radio 14 communications or the recent work in IETF transport, security, and 15 web protocols. There are also potential applications where latency 16 is potentially in a more significant role than it has traditionally 17 been in Internet communications. Modern networking systems offer 18 many tools for building low-latency networks, from highly optimised 19 individual protocol components to software controlled, virtualised 20 and tailored network functions. This memo views the developments 21 from a system viewpoint, and considers the potential future stresses 22 that the strive for low-latency support for applications may bring. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 16, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Applications with Special Focus on Low Latency . . . . . . . 3 60 3. Role of Low-Latency vs. Other Communications . . . . . . . . 4 61 4. Selected Improvements to Communications Latency . . . . . . . 4 62 5. Architectural Considerations . . . . . . . . . . . . . . . . 5 63 5.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.2. Implications . . . . . . . . . . . . . . . . . . . . . . 6 65 5.3. Recommendations for Further Work . . . . . . . . . . . . 8 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Informative References . . . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 Some recent Internet technology developments relate to improvements 73 in communications latency. For instance, improvements in radio 74 communications or the recent work in IETF transport, security, and 75 web protocols. 77 There are also potential applications where latency is potentially in 78 a more significant role than it has traditionally been in Internet 79 communications. 81 New applications or technologies does not necessarily imply that 82 latency should be the main driving concern, or that any further 83 efforts beyond those already ongoing are needed. Indeed, modern 84 networking systems offer many tools for building low-latency 85 networks, across the stack. At the IETF, for instance, there has 86 been a recent increase in work related to transport, security, and 87 web application protocols, in part to make significant improvements 88 in latency and connection set-up times. Similar efforts in other 89 parts of the stack exist in 3GPP, IEEE, and other standards 90 organisations. 92 Despite a large number of specific developments, it may be 93 interesting to view the developments from a system viewpoint, and to 94 consider the potential future stresses that the strive for low- 95 latency support for applications may bring. 97 The rest of this memo is organised as follows. Section 2 discusses 98 potential applications for low-latency communications. Section 4 99 reviews some of the recent work across the stack, relating to latency 100 improvements. Finally, Section 5 discusses some of the implications 101 (and non-implications) from an architectural perspective. 103 2. Applications with Special Focus on Low Latency 105 Most Internet applications enjoy significant benefits from low- 106 latency communications. 108 There are also potential applications where latency is potentially in 109 an even more significant role. For instance, embedding 110 communications technology in automation or traffic systems, or 111 consumer applications such as augmented or virtual reality where 112 advance buffering may not be feasible. 114 Many of the Internet-of-Things and critical services use cases in 5G, 115 for instance, have been listed as requiring low latency and high 116 reliability for communications [ER2015] [HU2015] [NGMN2015] [NO2015] 117 [QU2016] [IMT2020]. 119 Some example use cases include optimisation of utility services such 120 as electricity networks, connected automation systems in factories, 121 remote control of machinery such as mining equipment, or embedded 122 technology in road or railway traffic. 124 The different applications vary in terms of their needs. Some may be 125 very focused on high-speed local area communication, others need to 126 connect at optimal speed over a wide-area network, and yet others 127 need to find the right ways to provide global services without 128 incurring unreasonable delays. 130 Note that when we say "low-latency capabilities", there is no intent 131 to imply any specific implementation of those capabilities. In 132 particular, we look at the low-latency requirements from a broader 133 perspective than Quality-of-Service guarantees or separating traffic 134 onto different classes. Indeed, while today's virtualisation and 135 software-driven technologies give us more tools to deal with those 136 kinds of arrangements as well, past experience on deploying Quality- 137 of-Service mechanisms in the Internet should give us pause [CC2015]. 139 It is not the purpose of this memo to analyse the application 140 requirements for low-latency applications much further; for our 141 purposes it suffices to note that there are applications that are 142 enabled by low-latency capabilities of the underlying network 143 infrastructure. 145 3. Role of Low-Latency vs. Other Communications 147 There are some limited applications that rely solely on local 148 communication. One example of such an application is vehicles 149 communicating braking status to nearby ones. However, many 150 applications will include also wide-area communication. If the 151 factory automation machines are not talking other than with 152 themselves, at least their control systems are doing so in order to 153 ensure parts orders, monitoring and maintenance by equipment 154 manufacturers, and so on. This does not imply that these perhaps 155 critical applications are openly accessible from the Internet, but 156 many of them are likely to communicate outside their immediate 157 surroundings. 159 Many applications also rely on wide-area connectivity for software 160 updates. 162 As a result, this document recommends that when building 163 architectures for low-latency applications it is important to take 164 into account that these applications can also benefit from 165 communications elsewhere. 167 4. Selected Improvements to Communications Latency 169 It should be noted that latency is a very broad topic in 170 communications protocol design, almost as broad as "security", or 171 even "correctness". 173 Implementation techniques to satisfy these requirements vary, some 174 applications can be built with sufficient fast local networking 175 capabilities, others may require, for instance, building world-wide, 176 distributed content delivery mechanisms. 178 Modern networking systems offer many tools for building low-latency 179 networks, across the stack. from highly optimised individual protocol 180 components [I-D.ietf-tls-tls13] [I-D.ietf-quic-transport] [RFC7540] 181 to software controlled, virtualised and tailored network functions 182 [NFV2012] [I-D.ietf-sfc-nsh] [OF2008]. Data- and software-driven 183 network managment and orchestration tools enable networks to be built 184 to serve particular needs. 186 Across the stack there are also many other tools, as well as tools 187 being in development, e.g., a new transport design [L4S] at the IETF. 189 On the lower layers, improvements in radio communications are being 190 made. For instance, the IEEE 802.1 Time-Sensitive Networking Task 191 Group [TSN8021] has worked to define precise time synchronization 192 mechanisms for a local area network, and scheduling mechanisms to 193 enable different classes of traffic to use the same network while 194 minimising jitter and latency. At the IETF, the DETNET working group 195 is taking these capabilities and applying them for layer 3 networking 196 [DETNET]. 198 The 3GPP 5G requirements for next-generation access technology are 199 stringent, and are leading to the optimization of the radio 200 interfaces. The requirements specify a one-way latency limit of 201 0.5ms for ultra-reliable low-latency communications [TS38913]. 203 5. Architectural Considerations 205 Despite a large number of specific developments, it may be 206 interesting to view the developments from a system viewpoint, and to 207 consider the potential future stresses that the strive for low- 208 latency support for applications may bring. 210 5.1. Background 212 To begin with, it may be useful to observe that the requirements and 213 developments outlined above do not necessarily imply that any 214 specific new technology is needed or that the nature of 215 communications in the Internet would somehow fundamentally change. 216 And certainly not that latency should be the only or primary concern 217 in technology development. 219 With the drive for a new class of applications, there is often an 220 expectation that this means significant changes. However, all 221 changes need to stand on their own, be justifiable and deployable on 222 a global network. For instance, the discussion around the 223 introduction of the newest 4K or 8K high-definition video streaming 224 applications is reminiscent of the discussions about the introduction 225 of VoIP applications in the Internet. At the time, there was some 226 expectation that special arrangements and Quality-of-Service 227 mechanisms might be needed to support this new traffic class. This 228 turned out to be not true, at least not in general networks. 230 Experience tells us, for instance, that deploying Quality-of-Service 231 mechanisms in the Internet is hard, not so much because of the 232 technology itself, but due to lack of forces that would be able to 233 drive the necessary business changes in the ecosystem for the 234 technology to be feasibly deployable [CC2015]. As claffy and Clark 235 note: 237 "Although the Internet has a standards body (the IETF) to resolve 238 technical issues, it lacks any similar forum to discuss business 239 issues such as how to allocate revenues among competing ISPs 240 offering enhanced services. In the U.S., ISPs feared such 241 discussions would risk anti-trust scrutiny. Thus, lacking a way 242 to negotiate the business implications of QoS, it was considered a 243 cost rather than a potential source of revenue. Yet, the 244 relentless growth of a diversity of applications with widely 245 varying performance requirements continued on the public Internet, 246 with ISPs using relatively primitive, and not always completely 247 benign, mechanisms for handling them." 249 These difficulties should not be read as prohibiting all changes. Of 250 course, change can also seem unlikely even in cases where it becomes 251 absolutely necessary or the forces necessary to make a change have 252 actually built up. As a result, statements regarding change in the 253 Internet should be carefully evaluated on their merits from both 254 technical and ecosystem perspective. 256 Secondly, we often consider characteristics from a too narrow 257 viewpoint. In the case of latency, it is easy to focus on a 258 particular protocol or link, whereas from the user perspective 259 latency is a property of the system, not a property of an individual 260 component. 262 For instance, improvements on the performance of one link on a 263 communications path can be insignificant, if the other parts make up 264 a significant fraction of the system-level latency. That may seem 265 obvious, but many applications are highly dependent on communications 266 between a number of different parties which may reside in different 267 places. For instance, a third party may perform authentication for a 268 cloud-based service that also interacts with user's devices and a 269 number of different sensors and actuators. 271 We cannot change the speed of light, and a single exchange with 272 another part of the world may result in a 100ms delay, or about 200 273 times longer than the expected 5G radio link delay for critical 274 applications. It is clear that designing applications from a system 275 perspective is very important. 277 5.2. Implications 279 As noted above, low-latency applications need to pay particular 280 attention to the placement of services in the global network. 281 Operations that are on the critical path for the low-latency aspects 282 of an application are unlikely to work well if those communications 283 need to traverse half of the Internet. 285 Many widely used services are already distributed and replicated 286 throughout the world, to minimise communications latency. But many 287 other services are not distributed in this manner. For low-latency 288 applications such distribution becomes necessary. Hosting a global 289 service in one location is not feasible due to latency, even when 290 from a scale perspective a single server might otherwise suffice for 291 the service. 293 Content-Delivery Networks (CDNs) and similar arrangements are likely 294 to flourish because of this. In the most extreme cases, edge 295 computing services are needed. 297 How the communications are routed also matters. For instance, 298 architectures based on tunneling to a central point may incur extra 299 delay. One way to address this pressure is to use SDN- and 300 virtualisation-based networks that can be provisioned in the desired 301 manner, so that, for instance, instances of tunnel servers can be 302 placed in the topologically optimal place for a particular 303 application. 305 Recent developments in multipath transport protocols [RFC6824] also 306 provide application- and service-level control of some of the 307 networking behaviour. There is tension between application control 308 (often by content providers) and network control (often by network 309 operators). 311 One special case where that tension has appeared in the past is 312 whether there should be ways to provide information from applications 313 to networks on how packets should be treated. This was extensively 314 discussed during the discussion stemming from implications of 315 increased use of encryption in the Internet, and how that affects 316 operators [I-D.nrooney-marnew-report]. 318 Another case where there is tension is between mechanisms designed 319 for a single link or network vs. end-to-end mechanisms. Many of the 320 stated requirements for low-latency applications are explicitly about 321 end-to-end characteristics and capabilities. Yet, the two mechanisms 322 are very different, and most of the deployment difficulties reported 323 in [CC2015] relate to end-to-end mechanisms. 325 Finally, in the search for even faster connection setup times one 326 obvious technique is cross-layer optimisation. We have seen some of 327 this in the IETF in the rethinking of the layers for transport, 328 transport layer security, and application framework protocols. 330 But while cross-layer optimisation can bring benefits, it also has 331 downsides. In particular, it connects different parts of the stack 332 in additional ways. This can lead to difficulties in further 333 evolution of the technology, if done wrong. 335 In the case of the IETF transport protocol evolution, significant 336 improvements were made to ensure better evolvability of the 337 protocols than what we've experienced with TCP, starting from an 338 ability to implement the new protocols in applications rather than 339 in the kernel. 341 The effects of badly designed cross-layer optimisation are a 342 particular form of Internet ossification. The general networking 343 trend, however, is for greater flexibility and programmability. 344 Arguably, the ease at which networks can evolve is probably even more 345 important than their specific characteristics. 347 5.3. Recommendations for Further Work 349 Low-latency applications continue to be a hot topic in networking. 350 The following topics in particular deserve further work from an 351 architectural point of view: 353 o Application architectures for globally connected but low-latency 354 services. 356 o What are the issues with inter-domain Quality-of-Service 357 mechanisms? Are there approaches that would offer progress on 358 this field? 360 o Network architectures that employ tunneling, and mitigations 361 against the delay impacts of tunnels (such as tunnel server 362 placement or "local breakout" techniques). 364 o The emergence of cross-layer optimisations and how that affects 365 the Internet architecture and its future evolution. 367 o Inter-organisatorial matters, e.g., to what extent different 368 standards organisations need to talk about low latency effects and 369 ongoing work, to promote system-level understanding? 371 Overall, this memo stresses the importance of the system-level 372 understanding of Internet applications and their latency issues. 373 Efforts to address specific sub-issues are unlikely to be fruitful 374 without a holistic plan. 376 6. Acknowledgements 378 The author would like to thank Brian Trammell, Mirja Kuehlewind, 379 Linda Dunbar, Goran Rune, Ari Keranen, Jeff Tantsura, Stephen 380 Farrell, and many others for interesting discussions in this problem 381 space. 383 The author would also like to acknowledge the important contribution 384 that [I-D.dunbar-e2e-latency-arch-view-and-gaps] made in this topic. 386 7. Informative References 388 [CC2015] claffy, kc. and D. Clark, "Adding Enhanced Services to the 389 Internet: Lessons from History", September 2015 390 (https://www.caida.org/publications/papers/2015/ 391 adding_enhanced_services_internet/ 392 adding_enhanced_services_internet.pdf). 394 [DETNET] "Deterministic Networking (DETNET) Working Group", March 395 2016 (https://tools.ietf.org/wg/detnet/charters). 397 [ER2015] Yilmaz, O., "5G Radio Access for Ultra-Reliable and Low- 398 Latency Communications", Ericsson Research Blog, May 2015 399 (https://www.ericsson.com/research-blog/5g/5g-radio- 400 access-for-ultra-reliable-and-low-latency- 401 communications/). 403 [HU2015] "5G Vision: 100 Billion connections, 1 ms Latency, and 10 404 Gbps Throughput", Huawei 2015 405 (http://www.huawei.com/minisite/5g/en/defining-5g.html). 407 [I-D.dunbar-e2e-latency-arch-view-and-gaps] 408 Dunbar, L., "Architectural View of E2E Latency and Gaps", 409 draft-dunbar-e2e-latency-arch-view-and-gaps-01 (work in 410 progress), March 2017. 412 [I-D.ietf-quic-transport] 413 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 414 and Secure Transport", draft-ietf-quic-transport-02 (work 415 in progress), March 2017. 417 [I-D.ietf-sfc-nsh] 418 Quinn, P. and U. Elzur, "Network Service Header", draft- 419 ietf-sfc-nsh-12 (work in progress), February 2017. 421 [I-D.ietf-tls-tls13] 422 Rescorla, E., "The Transport Layer Security (TLS) Protocol 423 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 424 April 2017. 426 [I-D.nrooney-marnew-report] 427 Rooney, N., "IAB Workshop on Managing Radio Networks in an 428 Encrypted World (MaRNEW) Report", draft-nrooney-marnew- 429 report-02 (work in progress), August 2016. 431 [IMT2020] "Framework and overall objectives of the future 432 development of IMT for 2020 and beyond", ITU 433 Recommendation M.2083-0, September 2015 434 (http://www.itu.int/rec/R-REC-M.2083-0-201509-I/en). 436 [L4S] "Low Latency Low Loss Scalable throughput (L4S) Birds-of- 437 Feather Session", July 2016 438 (https://datatracker.ietf.org/wg/l4s/charter/). 440 [NFV2012] "Network Functions Virtualisation - Introductory White 441 Paper", ETSI, 442 http://portal.etsi.org/NFV/NFV_White_Paper.pdf, October 443 2012. 445 [NGMN2015] 446 "5G White Paper", NGMN Alliance, February 2015 447 (https://www.ngmn.org/fileadmin/ngmn/content/downloads/ 448 Technical/2015/NGMN_5G_White_Paper_V1_0.pdf). 450 [NO2015] Doppler, K., "5G the next major wireless standard", DREAMS 451 Seminar, January 2015 452 (https://chess.eecs.berkeley.edu/pubs/1084/doppler- 453 DREAMS_5G_jan15.pdf). 455 [OF2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., 456 Peterson, L., Rexford, J., Shenker, S., and J. Turner, 457 "OpenFlow: Enabling Innovation in Campus Networks", ACM 458 SIGCOMM Computer Communication Review, Volume 38, Issue 2, 459 pp. 69-74 2008. 461 [QU2016] "Leading the world to 5G", Qualcomm, February 2016 462 (https://www.qualcomm.com/media/documents/files/qualcomm- 463 5g-vision-presentation.pdf). 465 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 466 "TCP Extensions for Multipath Operation with Multiple 467 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 468 . 470 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 471 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 472 DOI 10.17487/RFC7540, May 2015, 473 . 475 [TS38913] "3rd Generation Partnership Project; Technical 476 Specification Group Radio Access Network; Study on 477 Scenarios and Requirements for Next Generation Access 478 Technologies; (Release 14)", 3GPP Technical Report TR 479 38.913 V14.2.0, March 2017 480 (https://portal.3gpp.org/desktopmodules/Specifications/ 481 SpecificationDetails.aspx?specificationId=2996). 483 [TSN8021] "Time-Sensitive Networking Task Group", IEEE 484 (http://www.ieee802.org/1/pages/tsn.html). 486 Author's Address 488 Jari Arkko 489 Ericsson 490 Kauniainen 02700 491 Finland 493 Email: jari.arkko@piuha.net