idnits 2.17.1 draft-zha-dln-framework-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 (October 31, 2016) is 2734 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7297' is mentioned on line 363, but not defined == Unused Reference: 'RFC3393' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC7279' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'I-D.finn-detnet-problem-statement' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'I-D.finn-detnet-architecture' is defined on line 424, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Zha 2 Internet Draft Huawei Technologies 3 Intended status: Informational 4 Expires: April 2017 6 October 31, 2016 8 Deterministic Latency Network Framework 9 draft-zha-dln-framework-00 11 Abstract 13 More and more real time applications, such as VR gaming, high 14 frequency trading, Internet of vehicle, require accurate latency 15 guarantee or bound, during service provisioning. Providing End-to- 16 End latency guarantee across Internet is increasingly attractive 17 while challenging. The main problem with latency guarantee on 18 Internet is that packet scheduling is still best-effort, and 19 congestion that further introduces latency uncertainty cannot be 20 avoided. This document presents a way of describing latency 21 information that mostly rely on the congestion management such as 22 queue scheduling, and a framework to use such information to 23 guarantee End-to-End latency. 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), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other 37 documents at any time. It is inappropriate to use Internet-Drafts 38 as reference material or to cite them other than as "work in 39 progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on April 30, 2017. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction .................................................2 66 2. Conventions used in this document ............................3 67 3. End-to-End Latency Guarantee Problem .........................3 68 3.1. Current QoS framework ...................................4 69 3.2. Need of Modeling of Latency .............................5 70 3.3. Need of Measurement of Flow Latency .....................6 71 4. Latency Information Modeling and Interface Framework .........7 72 4.1. Latency Aware PHB .......................................7 73 4.2. Latency Aware Interface .................................9 74 5. Security Considerations ......................................9 75 6. IANA Considerations ..........................................9 76 7. Acknowledgments ..............................................9 77 8. References ...................................................9 78 8.1. Normative References ....................................9 79 8.2. Informative References .................................10 81 1. Introduction 83 Latency sensitive applications, such as VR gaming, high frequency 84 trading, Internet of vehicle, have become more and more popular. 85 These applications often require a guaranteed or bounded End-to- 86 End packet transmission latency. For example, the End-to-End 87 latency bounds of and VR gaming are 1 millisecond and 5 88 millisecond corresponding. Hence, mechanism achieving End-to-End 89 latency guarantee or bound for latency sensitive applications is 90 highly desirable [I-D.liu-dln-use-cases]. 92 The well-known End-to-End QoS (Quality of Service) model is 93 DiffServ (Differentiated Service) [RFC2474] that defines PHB (Per 94 Hop Behavior) to provide different, relative service levels (or 95 priority) for different packets. However, one key factor for 96 latency during packet transmission is congestion, and congestion 97 management such as packet queue scheduling further introduces 98 latency uncertainty. DiffServ which only cares about providing 99 differentiated service based on packet priority is not sufficient 100 for the application that requires guaranteed End-to-End latency. 102 Therefore, mechanism is desirable that can model the packet queue 103 scheduling latency, then give the latency guarantee or bound of 104 certain packet flow in each network node. It is also useful to 105 define interface to expose such latency information to the upper 106 level of the network to facilitate End-to-End latency guaranteed 107 or bounded service. 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 112 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 113 in this document are to be interpreted as described in [RFC2119]. 114 In this document, these words will appear with that interpretation 115 only when in ALL CAPS. Lower case uses of these words are not to 116 be interpreted as carrying [RFC2119] significance. 118 3. End-to-End Latency Guarantee Problem 120 End-to-End latency is one of the most important metrics of network 121 service provisioning. Latency sensitive service has become the 122 main driving force of deterministic low latency network, which 123 requires End-to-End latency guarantee or bound. Unlike relative 124 low latency transport, End-to-End guaranteed or bounded latency 125 requires the knowledge of the worst latency performance across the 126 network, and the capability of latency guarantee in each network 127 node. Current packet network is mainly best-effort, so End-to-End 128 latency guarantee or bound is still difficult to achieve. 130 The key issue is that latency guarantee requires latency 131 description, or the capability of the network device, in order to 132 further provide latency guarantee for certain traffic flow. In 133 this section, the challenge of End-to-End latency guarantee, as 134 well as the need of latency description for the network device is 135 presented. 137 3.1. Current QoS framework 139 End-to-End QoS provisioning is the typical approach today to 140 provide better performance including latency, for the latency 141 sensitive services. DiffServ [RFC2474] is a well-known QoS 142 mechanism to provide differentiated service quality to different 143 classes of traffic flow. DiffServ model is shown in Figure 1. 145 +-------+ 146 | |------------+ 147 +-->| Meter | | 148 | | |-+ | 149 | +-------+ | | 150 | V V 151 +------------+ +--------+ +---------+ +-----------+ 152 | | | | | Shaper/ | | | 153 Packets =>| Classifier |=>| Marker |=>| Dropper |=>| Scheduler |=> 154 | | | | | | | | 155 +------------+ +--------+ +---------+ |-----------+ 156 Figure 1 - DiffServ Model 158 For classifiers, DiffServ uses code-points to describe the service 159 level and drop level of packets. The service level and drop level 160 are essentially relative performance description (or priority) for 161 different classes of traffic flows. One key factor for latency is 162 congestion, and congestion management such as packet queue 163 scheduling further introduces latency uncertainty. A deterministic 164 latency performance (e.g. guarantee or bound) description is still 165 missing while necessary for latency sensitive traffic flows. 167 For traffic conditioning policies, PHBs of DiffServ are applied, 168 including BE (Best Effort), EF (Expedited Forwarding), CS (Class 169 Selector) and AF (Assured Forwarding). These PHBs are designed for 170 only a few flow aggregates, which imply that they cannot provide 171 differentiated services for a potentially large amount of latency 172 sensitive traffic flows with different latency requirements. 174 For service provisioning (or packet scheduling) policies, they are 175 decoupled from traffic conditioning policies and haven't received 176 much attention. For example, in the case where an EF packet 177 arrives at a network device that contains other EF packets in the 178 queue, the latency of scheduling the EF packet is impacted by the 179 size of the queue. Moreover, the order of different latency aware 180 flows arriving the EF queue hasn't been considered. Hence the 181 specific packet scheduling policy in specific network device is 182 import to the latency performance of the packet. 184 In summary, the current DiffServ model is not sufficient for the 185 application that requires guaranteed End-to-End latency. The 186 problems can be listed as below. 188 a) Current QoS mechanism like DiffServ is not well defined to 189 support deterministic latency performance. For example, 190 relative service level or packet priority can not address the 191 congestion factor for latency, as well as the congestion 192 management such as packet scheduling that introduces latency 193 uncertainty. Current PHBs can only support a few flow 194 aggregates which are not sufficient for different latency 195 requirements. 196 b) There is no user-/device-specific latency performance 197 specification, or no control plane mechanism to assign user- 198 /device-specific latency requirement to the network devices 199 along the path. As a result, network device has no idea how 200 fast a packet must be forwarded, and cannot adopt a suitable 201 mechanism (e.g. queue scheduling) to guarantee latency. 202 c) There is no mechanism supporting the measurement of flow 203 latency inside of a network device, especially given certain 204 PHB type and code-points of the flow. Such measurement will 205 make End-to-End latency more visible, and thus is crucial for 206 End-to-End latency oriented OAM. 207 d) Service provisioning (or packet scheduling) policies are not 208 specified. Packet scheduling policy and queue status are also 209 key factors of latency and its uncertainty. Therefore packet 210 scheduling policy must be considered to provide deterministic 211 latency service for time sensitive flows. 212 In a nutshell, how to explain the QoS value or how to make sure 213 the QoS value can be used to guarantee latency performance is not 214 well defined yet. Some extension to the current QoS model (e.g. 215 new PHB) could be useful to solve these problems. 217 3.2. Need of Modeling of Latency 219 As mentioned in problem section, QoS value or packet priority 220 cannot guarantee deterministic low latency. In another word, the 221 same QoS value or priority doesn't guarantee same latency 222 performance. In network device, various forwarding mechanisms and 223 interfaces introduce different latency that may be linked to the 224 same priority code. There is still lack of latency performance 225 information that can be used to provide latency guarantee service. 227 The principle of Diffserv is focus on providing, describing 228 differentiated service of traffic flow but not deterministic 229 latency. Instead, queuing and scheduling, as a main part of 230 latency and latency uncertainty, is out of DiffServ's major 231 concern. 233 PHB provides standard way of modeling of device forwarding 234 behavior as well as how to handle each traffic flow. However, PHB 235 description does not include queuing or scheduling information. In 236 reality, latency is dominated by congestion control scheme, which 237 is mainly queuing and scheduling in the network device to take 238 care of multiple traffic flows arriving at the same port 239 simultaneously. 241 Therefore, extension to the current QoS model (e.g. new PHB) is 242 desirable as a standard way to describe the latency performance of 243 network device. With such standard latency model, network device 244 is enabled to better manage the forwarding mechanism (e.g. queue 245 scheduling) for the packet, in order to guarantee End-to-End 246 latency for the service. 248 3.3. Need of Measurement of Flow Latency 250 Flow latency measurement is also very crucial to make sure the 251 latency bound is not violated and useful for End-to-End latency 252 aware OAM mechanism. There is a need to support the measurement of 253 flow latency inside of a network device, especially given certain 254 PHB type and code-points of the flow. 256 Existing technologies such as OWAMP [RFC4656] and TWAMP [RFC5357] 257 is focused on providing one way and two way IP performance metrics. 258 Latency is one of metrics that can be used for End-to-End 259 deterministic latency provisioning. Use OWAMP/TWAMP protocols or 260 extension on that to support measurement of flow latency 261 performance is feasible. 263 Overlay based End-to-End latency measurement is another approach 264 commonly adopted by service providers like CDN vendor. Such 265 approach can be further enhanced by latency measurement inside 266 network device, for better service provisioning, e.g. traffic 267 steering and path selection. 269 4. Latency Information Modeling and Interface Framework 271 To provide better End-to-End latency guarantee, an extension of 272 QoS framework is proposed to provide more accurate latency 273 information of network device. Mechanisms for flow latency 274 measurement and latency information exchange are also proposed. 275 This work may introduce new interfaces or extension on existing 276 interfaces. 278 4.1. Latency Aware PHB 280 Latency aware PHB provides latency performance information on 281 network device with more accurate description on latency bound of 282 queuing and scheduling mechanisms. In addition to classical PHB 283 which focus on classifier, marker and shaper/dropper, latency 284 aware PHB includes queuing and scheduling as well. The latency 285 factor is mainly introduced by queuing and scheduling algorithm 286 that handles congestion of multiple traffic flows. Congestion 287 latency can be up to hundreds of milliseconds regarding buffer 288 size. Implementations of various queuing, scheduling algorithms, 289 and QoS policies introduce latency uncertainty. Moreover, 290 different links cause different latency, as 1GE and 10GE will 291 certainly cause different latency. 293 The queue scheduling information model is proposed to describe 294 latency based service capability and capacity of network nodes. As 295 the assigned deterministic latency bound must be guaranteed, the 296 network needs to know what kinds of latency based services can be 297 provided by a network node for a flow with specific traffic 298 profile. 300 For latency based service capability, by referring to DiffServ 301 design, a differentiated service model called latency slicing 302 model is defined as follows. A network node provides multiple 303 classes of latency-bounded services, and if a flow is allocated to 304 a service class, then all its shaped packets can be sent out from 305 the network node with waiting time no more than the predefined 306 latency class bound. Such a latency-bounded service class is 307 called a latency slice. For example, a network node may have 308 multiple latency slices with latency bounds of 50us, 100us, 250us, 309 1ms, etc. Notice that actual max flow latency may vary due to 310 acceptance of new flows or finish of existing flows, but it will 311 never exceed the corresponding latency slice bound. 313 The maximum packet length cannot exceed a predefined value called 314 MaxSDU, otherwise other flows latency requirement may be possibly 315 violated. 317 A latency aware flow with specific traffic profile can be accepted 318 by a latency slice only if the latency of any existing latency 319 aware flow does not violate the latency bound of its latency slice. 320 For example, when the traffic profile is defined by the leaky 321 token model (b, r), two parameters MaxBurst B and MaxRate R 322 representing the maximum allowable burst size and average rate are 323 introduced to formulate the latency slice service capacity. In 324 this case, a new flow can be accepted as long as b<=B and r<=R. 325 MaxBurst and MaxRate can be adjusted to accommodate more latency 326 sensitive flows in a particular latency slice, and lead to service 327 capacity reduction of other latency slice. 329 By hiding queue scheduling implementation details, the latency 330 slicing information model is shown in Figure 2. 332 +--------------+--------------+ 333 | Name | Elements | 334 +--------------+--------------+ 335 |NodeID | | 336 +--------------+--------------+ 337 |SliceID | | 338 +--------------+--------------+ 339 |LatencyBound | | 340 |--------------+--------------+ 341 |MaxSDU | | 342 |--------------+--------------+ 343 |MaxRate | | 344 |--------------+--------------+ 345 |MaxBurst | | 346 |--------------+--------------+ 347 Figure 2 - Latency Slice Information Model 349 More detail of this latency Slice information model is under 350 discussion and will be available in the next version. 352 4.2. Latency Aware Interface 354 The queuing and scheduling information is typically localized in 355 the network device. In another word, the current hop has no 356 knowledge of how the flow was scheduled on last hop. So it is hard 357 to guarantee End-to-End latency if latency information only 358 affects locally. Latency performance such as queuing and 359 scheduling information in network device needs to be exposed for 360 End-to-End latency guarantee service provisioning. 362 Basically, more information needs to be exchanged than the current 363 DiffServ code-points. Existing approach such as [RFC7297] defines 364 CPP that contains information of connection attributes, latency, 365 loss, and so on. 367 With latency performance information defined on previous section, 368 an interface or mechanism to exchange such information is proposed. 369 A simple approach can be an interface from network device to 370 controller, which collects all the latency performance information 371 of each hop, and then make a decision how to serve the flow at 372 each hop. In this case, the controller tells each hop how to serve 373 the flow with queuing, scheduling information that can be 374 understood by each hop. 376 The detail of latency aware interface is under discussion and will 377 be available in the next version. 379 5. Security Considerations 381 TBD 383 6. IANA Considerations 385 This document has no actions for IANA. 387 7. Acknowledgments 389 This document has benefited from reviews, suggestions, comments 390 and proposed text provided by the following members, listed in 391 alphabetical order: Jinchun Xu and Hengjun Zhu. 393 8. References 395 8.1. Normative References 397 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC3393] C. Demichelis, "IP Packet Delay Variation Metric for IP 401 Performance Metrics (IPPM) ", RFC 3393, November 2002. 403 [RFC2474] K. Nichols, "Definition of the Differentiated Services 404 Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, 405 December 1998. 407 [RFC4656] S. Shalunov, "A One-way Active Measurement Protocol 408 (OWAMP)", RFC 4656, September 2006. 410 [RFC5357] K. Hedayat, "A Two-Way Active Measurement Protocol 411 (TWAMP)", RFC 5357, October, 2008. 413 [RFC7279] M. Boucadair, "IP Connectivity Provisioning Profile 414 (CPP)", RFC 7297, July, 2014. 416 8.2. Informative References 418 [I-D.finn-detnet-problem-statement] 420 Finn, N. and P. Thubert, "Deterministic Networking Problem 421 Statement", draft-ietf-detnet-problem-statement-01 (work in 422 progress), September 2016. 424 [I-D.finn-detnet-architecture] 426 Finn, N., Thubert, P., and M. Teener, "Deterministic Networking 427 Architecture", draft-ietf-detnet-architecture-00 (work in 428 progress), September 2016. 430 [I-D.liu-dln-use-cases] 432 Liu, X., "Deterministic Latency Network Use Cases", draft-liu-dln- 433 use-cases-00 (work in progress), October 2016. 435 Authors' Addresses 437 Yiyong Zha 438 Huawei Technologies 439 Email: zhayiyong@huawei.com