idnits 2.17.1 draft-petlund-latency-transport-services-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport-Services A. Petlund 3 Internet-Draft Simula Research Laboratory 4 Intended status: Informational February 14, 2014 5 Expires: August 18, 2014 7 Transport Services and low latency 8 draft-petlund-latency-transport-services-00 10 Abstract 12 This document categorises different classes of network latency, 13 discusses possible metrics for determining the characteristics of 14 latency-sensitive flows and addresses the use of transport services 15 as a means for achieving transport latency reduction. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 18, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Time-dependent applications . . . . . . . . . . . . . . . . . 2 54 2.1. On the characteristics of latency-sensitive traffic . . . 3 55 3. Challenges in identifying traffic characteristics . . . . . . 4 56 4. Examples of choices of protocols and options that influence 57 latency . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Protocols . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.2. Options and mechanisms . . . . . . . . . . . . . . . . . 6 60 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 8.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Modern operating systems provide a myriad of different protocols and 71 options to tweak the network performance. Even for veterans within 72 the field of transport protocols it is hard to stay fully up to date 73 on all possibilities and combinations of options that may help reduce 74 latency for a networked application. Also, care needs to be taken so 75 that the transport protocols and options chosen will not be 76 disruptive to other services or to an application if it changes 77 network behaviour. For application developers in general to be able 78 to select the best possible subset of mechanisms and protocols to 79 support their time-dependent networked application, a measure of 80 abstraction is required. This document discusses different classes 81 of network latency with examples of how to reduce the delay for each 82 class. It also makes suggestions for how an application can specify 83 its intended behaviour to the transport services as a foundation for 84 optimising the underlying services with regard to latency. 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Time-dependent applications 94 While completion time for bulk data transfer is deemed important, the 95 focus of industry and research has lately shifted towards 96 understanding the diversity of Internet traffic today. Many flows 97 are in some way application limited, that is, their sending pattern 98 is not exclusively determined by congestion control, but also by the 99 timing of data received from the application. Such applications are 100 in many cases time-dependent, since the events driving the data 101 production is triggered by real-life interaction or events [AP09]. 103 While downloading applications dominated the Internet for a long 104 time, overprovisioning in backbone networks has allowed interactive 105 applications to succeed. Audio and video conferences that previously 106 required leased lines are conducted over the Internet. Multiplayer 107 games that are played over the Internet are also prevalent. Even Web 108 applications generate increasingly interactive Internet traffic as 109 more web pages are generated dynamically and contain interactively 110 updated elements. The flows of such time-dependent applications now 111 represent a large proportion of the total number of flows in the 112 Internet. These flows have to tackle a large variety of access 113 network technologies, all with different characteristics. Depending 114 on the type of application, "low latency" may carry several meanings 115 from a transport viewpoint. The next section elaborates on different 116 classes of latency. 118 2.1. On the characteristics of latency-sensitive traffic 120 The scenarios described in this section are derived from a set of 121 known latency-creating factors from which networked applications 122 suffer. These categories are not exclusive, an application may 123 suffer from more than one of them. They are, however, 124 distinguishable at the transport layer and may require different 125 avoidance techniques. The main categories of application latency 126 that have been identified so far are: 128 (1) Real-time interaction for applications with a lasting duration: 130 (a) Per-packet latency: applications that have signalling-like 131 communication driven by actions or events. Each small 132 message is equally important and congestion-control is not 133 applied as there is never a queue building on the sender 134 side. Examples include sensors triggered by events or 135 online gaming traffic. 137 (b) Per-burst latency: interactive elements are sent in bursts 138 over a persistent connection. Collapsing the congestion 139 window (cwnd) between bursts will reduce the per-burst 140 completion time and increase the delivery latency for a 141 burst while keeping the cwnd open may cause overestimation 142 of the available bandwidth. Examples include video 143 streaming over persistent connections and financial 144 applications synchronised by trading synchronisation 145 barriers. 147 (c) Per-burst latency with multiple reconnects: is the above 148 scenario, but where the streams makes new connections with 149 regular intervals. This behaviour aggravates the bursty 150 scenario by adding connection initialisation latency and 151 start-up latency to each newly initialised connection. 152 Examples include several methods of adaptive TCP-based 153 video streaming and Web-based Content Management Systems. 155 (2) Start-up latency: the time it takes for a connection to find its 156 correct send-rate. The faster the correct bandwidth can be 157 determined and the flow assume the correct send rate, the lower 158 the latency. Examples include non-adaptive high-quality video- 159 on-demand delivery and Cloud-based office applications. 161 (3) Flow completion time: when a browser opens a range of different 162 connections when loading a specific webpage, the latency 163 experienced by the user is determined by the completion time of 164 the subflows. Very often, such flows are very small, often not 165 more then one packet, thus motivating measures like increasing 166 the initial window. Examples include heavily styled web pages, 167 messaging systems and news tickers, but this problem affects 168 also interactive web browsing. 170 There is also the latency induced by extra RTTs needed to set up a 171 connection, for instance to initiate a security protocol or to 172 negotiate options. 174 There are flows that fluctuate between the behaviours described 175 above. In such cases, care must be taken to not blindly apply 176 mechanisms that will reduce the latency for one of the cases, but 177 increase latency for others. In addition, some particular 178 applications suffer more when there is a large variation in latency 179 (jitter) than from a somewhat higher mean latency. This includes 180 applications with real-time interaction, such as on-line games. In 181 general, latency is characterised by a number of features including 182 its higher order moments and distribution. The most important set of 183 features varies between different latency-sensitive applications. 184 There is a need to consider all of these traffic behaviours to 185 properly address the topic of latency for transport services. 187 3. Challenges in identifying traffic characteristics 189 It can be hard to reliably identify the flow characteristics from the 190 viewpoint of the transport layer. At the time when a flow starts, 191 the transport can make no assumptions about what its traffic patterns 192 can be [MF14] (AP: unless guessing from 5-tuple). In order for the 193 transport to make qualified decision on which protocols and options 194 to apply for a given flow to reduce latency, more information must be 195 provided to the transport: 197 (1) The transport service tries to identify the traffic 198 characteristics of the flow. This is a possibility for long- 199 lasting flows that can be instrumented by the transport service. 200 Such monitoring is, however, challenging since the experienced 201 behaviour is dependent network characteristics like RTT and 202 bottleneck capacity. 204 (2) The application informs the transport layer about its intended 205 behaviour. For short flows and reducing startup latency, this 206 is the only option as no information are yet available about the 207 flow's characteristics. 209 For the transport layer to be able to identify relevant traffic 210 characteristics, it is useful to review the metrics that are 211 available to the transport layer. Examples of metrics are: 213 (1) Packets in flight: "FLIGHT SIZE", according to the TCP 214 congestion control specification [RFC5681], is the number of 215 packets that have been transmitted, but not yet acknowledged. 216 For efficient retransmissions, in reliable protocols, this is an 217 important metric as a flow with less than 4 packets in flight 218 cannot trigger a fast retransmission. This leads to high 219 recovery delays for many application-limited flows. Packets in 220 flight is, however, not a static indicator of traffic behaviour 221 as it is dependent on the RTT of the connection. 223 (2) Packet intertransmission time: the rate by which the application 224 delivers data to the transport layer over time gives an 225 indication of the traffic characteristics of the application. A 226 constantly application-limited flow will not need a tuned 227 congestion control, but will be sensitive to recovery delays as 228 discussed in the bullet about "Packets in flight". 230 (3) Payload size: the payload size is application-specific and does 231 not relate to any network phenomena. Time-dependent, event 232 driven traffic often send packets with payload sizes less than 233 the maximum transmission unit (MTU)[AP09]. For greedy streams, 234 the packets will all fill an MTU. 236 (4) Stream duration: Analysis of Internet traffic shows that a 237 majority of the flows are very short in duration[MF14]. When a 238 browser loads a webpage, dozens of connections are usually 239 opened, each transferring a small part of the webpage content. 241 Streams carrying event-based or interactive communication, on 242 the contrary, are usually persistent and longer-lasting. Thus, 243 measuring whether a stream terminates within a short time 244 interval (less than one second) can provide information that may 245 help predict the continued behaviour of the flow. 247 (5) Burstiness: if a flow has a traffic pattern with bursts of 248 activity followed by periods of inactivity, getting up to speed 249 quickly in the active periods will be important to the 250 application. The size of each burst is also relevant to the 251 choices made by the transport layer. 253 (6) Send queue backlog: a flow that is network limited will build a 254 send queue while waiting for data to be transferred. By 255 monitoring the send queue size, the transport layer can get 256 relevant information about the flow. 258 The combination of information provided by the above listed metrics 259 may help the transport services to make qualified decisions on the 260 flow characteristics and choose the right services for reducing 261 latency. 263 4. Examples of choices of protocols and options that influence latency 265 List examples of protocols and options that influence latency. 267 4.1. Protocols 269 Examples of protocols with a short discussion on latency 270 implications. 272 o TCP: 274 o UDP: 276 o SCTP: 278 o Other: DCCP ++? 280 4.2. Options and mechanisms 282 Examples of protocol options and mechanisms with a short discussion 283 on their influence on latency. 285 o Nagle's algorithm (delays small packets) 287 o Delayed ACKs (delays feedback) 288 o Limited transmit 290 o Early retransmit 292 o RTO restart 294 o New CWV 296 o TFO 298 o PRSCTP 300 5. Discussion 302 Whether properties should be submitted by the applications in 303 addition to services is an item for discussion and should be treated 304 in future revisions of the document. 306 6. IANA Considerations 308 This memo includes no request to IANA. 310 7. Security Considerations 312 This document does not raise any new security issues. 314 8. References 316 8.1. Normative References 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997. 321 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 322 Control", RFC 5681, September 2009. 324 8.2. Informative References 326 [AP09] Petlund, A., "Improving Latency for interactive, thin- 327 stream applications over reliable transport", Thesis 328 Unipub, Kristian Ottosens hus, Pb. 33 Blindern, 0313 329 Oslo, December 2009. 331 [MF14] Fuchs, M., "Time-Dependent Thin Transport Layer Streams: 332 Characterization, Empirical Observation and Protocol 333 Support", Master Thesis University of Kaiserslautern, 334 Germany, January 2014. 336 Author's Address 338 Andreas Petlund 339 Simula Research Laboratory 340 Rolfsbukta 4 B, 341 Fornebu 1364 342 Norway 344 Phone: +47 99 27 36 22 345 Email: apetlund@simula.no