idnits 2.17.1 draft-liu-dln-use-cases-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 2727 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 113, but not defined == Unused Reference: 'I-D.finn-detnet-architecture' is defined on line 438, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group X. Liu 2 Huawei Technologies 3 Internet-Draft 4 Intended status: Informational 6 Expires: April 2017 October 31, 2016 8 Deterministic Latency Network Use Cases 9 draft-liu-dln-use-cases-00 11 Abstract 13 This draft documents low latency requirements in several diverse 14 industries including virtual reality, electrical utilities protection 15 and cloud-based service. For each case, this document will identify 16 the application, representative solutions used today and its 17 requirements on deterministic latency mechanism. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on April 30, 2017. 41 Copyright Notice 43 Copyright (c) 2016 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 1.1. Conventions used in this document ...................... 3 60 2. Cloud VR/Gaming Service ................................... 3 61 2.1. Use Case Description ................................... 3 62 2.2. Delay in a VR system ................................... 4 63 2.3. Cloud VR/Gaming Asks ................................... 7 64 3. Electrical Utility Relay Protection ....................... 7 65 3.1. Use Case Description ................................... 7 66 3.2. Delay Requirements on Protection Scheme ................ 8 67 3.3. Precision Delay Compensate Technology .................. 9 68 3.4. Relay Protection Asks .................................. 9 69 4. Cloud-based Service ....................................... 9 70 4.1. Use Case Description ................................... 9 71 4.2. Cloud-based Service Asks .............................. 10 72 5. Security Considerations .................................. 10 73 6. IANA Considerations ...................................... 10 74 7. References ............................................... 10 75 7.1. Informative References ................................ 10 76 8. Acknowledgments .......................................... 11 78 1. Introduction 80 Deterministic latency network (DLN) is defined to provide guaranteed 81 deterministic latency for specific traffic, especially for latency- 82 critical traffic. However, there are no current off-the-shelf 83 solutions for DLN. Distinguished from DetNet [I-D.finn-detnet- 84 architecture] that focuses on the solution of Layer 2-3 packet 85 forwarding, a feasible DLN solution is supposed to provide a latency 86 information obtaining mechanism including delay-aware modeling and 87 measurement, latency management mechanism with interfaces and 88 protocols to maintain the performance of latency sensitive 89 applications. Latency slicing and latency modeling are alternatives 90 in discussion currently. More specifically, DLN is: 92 -Face to upper layer, define delay-aware PHB and related OAM 93 interfaces; 94 -Targeting at WAN, support multiple data techniques including TSN; 96 -Working together with DetNet, and also have constraints on traffic 97 flow, device capability, and etc. 99 This draft elaborates use cases from diverse industries along with 100 their stringent requirements for deterministic low latency. Together, 101 they provide broad industry context for DLN and a yardstick against 102 which proposed DLN solutions can be measured. 104 For each use case, we identify the application with its latency 105 requirement, and specify its representative solutions used today as 106 well as problems to be settled on deterministic latency mechanisms. 108 1.1. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Cloud VR/Gaming Service 116 2.1. Use Case Description 118 Virtual reality (VR) systems track one or more objects to generate 119 the depiction of a virtual environment from the user's vantage point. 120 Free viewpoint television (FTV) as a typical application of VR allows 121 the user to interactively control the viewpoint and generate new 122 views of a dynamic scene from any 3D position by transmitting all 123 views of 3D space to user and rendering new images according user's 124 turn locally, which requires large bandwidths, 1Gbps for 4K FTV and 125 4Gbps for 16K FTV, unavailable in subscriber network. VR gaming 126 allows the user to experience being in a three-dimensional 127 environment and interact with the environment during a game through 128 dedicated equipments. Large bandwidth requirement and high cost of 129 the customized hardware with immense computational power make VR 130 inaccessible to the average consumer. 132 To address these challenges, cloud-based virtual reality is proposed 133 by carriers to alleviate complex processing and high bandwidth on 134 user side by outsourcing the computational power necessary to encode 135 videos or render games to distant server farms and delivering only 136 video content to user. Then carriers can serve as media providers in 137 broadcast and streaming for sports and live events, or as 138 infrastructure provider for third-part VR applications. By reducing 139 initial cost of virtual reality and removing the need d for consumers 140 to constantly upgrade their equipments every few years, cloud based 141 virtual reality is much more attainable. 143 2.2. Delay in a VR system 145 In this use case we consider the latency between the time user start 146 to turn and the time the image is redrawn to account for the new pose 147 in a cloud based VR system. A high latency may induce simulator 148 sickness due to the virtual image drifting, reduce the subjective 149 sense of "presence", and change the pattern of behavior such that 150 users make more errors during speeded reaching, grasping, or object 151 tracking. To deliver good experiences, 20 ms of latency or much less 152 is recommended for a VR system to prevent simulator sickness. 154 The latency of a VR system mainly comes from the following steps: 156 1) Tracking has to capturing the exact pose of the HMD (Head Mount 157 Display), that is, the exact position and orientation in the real 158 world. Tracking latency is highly dependent on the system used. An 159 IMU (3-DOF gyro and 3-DOF accelerometer) has low latency on the order 160 of 1 ms, but drifts. Camera-based tracking doesn't drift, but has 161 high latency of 10-15 ms. Right now one of the lowest-latency non- 162 drifting accurate systems out there is a high-end system from NDI, 163 which has about 4 ms of latency. To reduce the tracking latency, the 164 obvious solution is using both optical tracking and an IMU, via 165 sensor fusion. The IMU can be used to provide very low-latency state, 166 and optical tracking can be used to correct the IMU's drift. Properly 167 implemented, sensor fusion can reduce the tracking latency to about 168 1.5 ms. 170 2) The graphic system has to render the scene as viewed from that 171 pose. Rendering latency depends on CPU and GPU capabilities and on 172 the graphics complexity of the scene being drawn. A VR system 173 requires at least 60 Hz for a good experience, and the corresponding 174 rendering latency is 16ms. When this step is moved to the cloud, the 175 rendering latency can be reduced to about 7.4 ms by distributed 176 parallel processing. 178 3) Transmission of the rendered output from the cloud to the user's 179 device over IP induces a transmit latency which is unpredicted 180 currently. 182 4) The graphics hardware has to transfer the rendered scene to the 183 HMD's display. This is called scan-out, and involves reading 184 sequentially through the frame buffer from top to bottom, moving 185 right to left within each scan line, and streaming the pixel data for 186 the scene over a link such as HDMI to the display. At 200Hz, the 187 displaying latency is on the order of 6ms. 189 The total latency of tracking, rendering and displaying is 190 1.5+7.4+6=14.9ms. So the suggested budget for transmit delay is 5ms 191 to keep the total latency down to 20 ms. 193 +----------------------+ 194 +------------------------------+ | Rendering Latency | 195 | +-------+ +--------+ | |+-------+ +---------+| 196 | |Sensors|-----| A/D | | ||cloud |--|rendering|| 197 | +-------+ +---/----+ | +----||process| +---------+| 198 | | | | |+-------+ | | 199 | +----------+ +---/--------+| | |+---------+ +--------+| 200 | |terminal |---|signal || | ||video |-|video || 201 | |processing| |transmission|| | ||streaming| |encoding|| 202 | +----/-----+ +------------+| | |+---------+ +--------+| 203 | Tracking Latency | | +----------------------+ 204 +------|-----------------------+ +------------+ 205 | |network | 206 | |transmission| 207 +--------------------------/ | 208 | | 209 +------------+ 211 Transmit Latency 213 +------------+ 214 |network | 215 |transmission| 216 | | 217 +------------+ 218 +----------------------------+ | 219 | Displaying Latency | | 220 | +----------+ +---/------+| | 221 | | |---|Video ||----------+ 222 | |displaying| |decoding || 223 | +----/-----+ +----------+| 224 +----------------------------+ 226 Figure 1 End-to-End Cloud VR System 228 Two deployments of cloud-based virtual reality are proposed in this 229 use case to keep the transmit latency down to 5ms. One is deploying 230 the central cloud access to the BRAS, and the other one is deploying 231 the central cloud access to the CO. There is a tradeoff between 232 latency and OPEX. Both of them require the network to guarantee a 233 deterministic low latency for VR traffic. 235 /'''' 236 | \ 237 /'''' \ 238 / \ 239 | VR Cloud | 240 +-------+ ,,,,,,,,,,,,,,, 241 | VR |-----| | 242 |Devices| | +-----+ +-----+ +------+ +------------+ 243 +-------+ |-----| ONT |----| OLT |------| BRAS |-----| Core Router| 244 | +-----+ +-----+ +------+ +------------+ 245 +-------+ | 246 | VR |-----| 247 |Devices| 248 +-------+ 249 Figure 2. VR Cloud on CO Position 251 /'''' 252 | \ 253 /'''' \ 254 / \ 255 | VR Cloud | 256 +-------+ ,,,,,,,,,,,,,,, 257 | VR |-----| | 258 |Devices| | +-----+ +-----+ +------+ +-------------+ 259 +-------+ |-----| ONT |----| OLT |------| BRAS |-----| Core Router | 260 | +-----+ +-----+ +------+ +-------------+ 261 +-------+ | 262 | VR |-----| 263 |Devices| 264 +-------+ 265 Figure 3. VR Cloud on Bras Position 267 In this case, assured transmission latency for VR traffic is the key 268 to cloud-based virtual reality. New latency-aware packet forwarding 269 mechanism is required for the network to guarantee the deterministic 270 latency for this latency-critical traffic. Along with this forwarding 271 mechanism, the latency is required to be measurable and manageable to 272 maintain the performance of VR. 274 2.3. Cloud VR/Gaming Asks 276 o Deterministic Delay behavior 277 o IP packet service 278 o Ultra low delay less than 5ms 279 o Delay management over network 281 3. Electrical Utility Relay Protection 283 3.1. Use Case Description 285 The effective operation of an electrical utility depends on high 286 validity and deterministic behavior of the fundamental networks. 287 Protection means not only to protect the operator but also to protect 288 the stability of the electrical equipment. If a transmission or 289 distribution power failure happens, it will cause damage to the 290 operator and large blackouts. The role of the protection system of 291 the electrical utility is to selectively trip out a faulty part by 292 delivering command signals as soon as possible. 294 The basic principal of protection scheme is that, by monitoring the 295 abnormal voltage or current changes in power primary equipment or 296 transmission lines, the logic program can identify a device or a 297 transmission line fault point and control circuit breaker to trip in 298 time. The current value is the same at both ends of the transmission 299 line during normal operation, and when this transmission line fails, 300 the current at both ends will not match. When the differential 301 current is greater than the setting value, the circuit breaker will 302 be tripped on each side of the protected device, so that faulty 303 equipment disconnects the power.AS is shown in Figure 1, A and B on 304 behaves of the line protection equipment, T1 and T2 refers to the 305 time delay of two opposite directions, Im and In refers to the current 306 of two opposite directions, Ik is the result of Im plus In, if Ik 307 equals to 0, there is no trouble between A and B, otherwise, some 308 faults are here. 310 Im------- Ik -------In 311 +---+ | | | +---+ 312 | A |--|-----------|-------------|--| B | 313 +---+ | | | +---+ 314 | | | | 315 | | | | 316 | +-------------T1----------------+ | 317 +------------------T2-------------------+ 318 /-------------------------------------\ 319 |Normal or external trouble, Ik=Im+In=0| 320 |internal trouble, Ik=Im+In 0 | 321 \-------------------------------------/ 322 /----------------------------\ 323 | T1 is the delay from A to B| 324 | T2 is the delay from B to A| 325 | Asymmetric=|T1-T2| | 326 \----------------------------/ 327 Figure 4 Electrical Utility Relay Protection 329 3.2. Delay Requirements on Protection Scheme 331 Right now everything is moving to IP network. In order to realize the 332 effective differential protection, time delay need to be taken into 333 consideration. As shown in Figure 1, T1 and T2 must be less than 5ms. 334 The most important thing is that the difference between T1 and T2 335 must be less than 20us. More detailed requirements are shown in the 336 following table: 338 +------------------------------+---------------------------------+ 339 |Power relay requirements |Attributes | 340 +------------------------------+---------------------------------+ 341 |Interface type |E1 interface | 342 +------------------------------+---------------------------------+ 343 |Full nodes |Less than or equal 15 | 344 +------------------------------+---------------------------------+ 345 |Total transmission distance |About 500KM | 346 +------------------------------+---------------------------------+ 347 |One way delay |Less than 5ms | 348 |Maximum jitter |10us | 349 +------------------------------+---------------------------------+ 350 |Asymmetric delay |Less than 20us | 351 +------------------------------+---------------------------------+ 352 Table 1: Power Relay Requirements 354 3.3. Precision Delay Compensate Technology 356 The effective differential protection relies on synchronous sampling. 357 It means that the protective device on both sides of the transmission 358 line requires synchronous sampling. When both sides of relay 359 protection exists sampling time difference, it will produce a 360 corresponding differential current value. If the differential current 361 value exceeds the threshold value, the protection may miss operate. 362 Synchronous sampling is based on the consistency of the two-way 363 channel delay, which implies that the smaller the asymmetric is, the 364 better differential protection behaves. So the relay protection has 365 strict requirements on asymmetric delay, it must be less than 20us. 367 SDH technology has become the mainstream of the electric power 368 communication network technology. In recent years, with the process 369 of smart grid construction accelerated, more variety, a greater flow 370 of business types gradually add in electric power communication 371 network. It becomes more and more difficult for SDH network to 372 satisfy time delay in the differential protection. So the main 373 electric power communication network service is from the traditional 374 TDM business gradually transformed into IP packet service. The highly 375 precise time delay compensate technology plays an important role in 376 IP packet service, which can solve the problem of time delay in the 377 differential protection. 379 3.4. Relay Protection Asks 381 o Deterministic behavior 382 o Synchronous sampling 383 o IP packet service 384 o 20us Asymmetric delay 385 o Delay information for compensation technology 387 4. Cloud-based Service 389 4.1. Use Case Description 391 Cloud-based services those are any resources provided over the 392 network. Commonly, the cloud providers provide computing, storage as 393 well infrastructures as a service which is accessible from network. 394 More and more companies are switching to the cloud since it is more 395 efficient, secure and reliable. The performance is the key matter of 396 cloud-based services, as fast and predictable response from remote 397 location at any volume is the determinant of user experience. 399 Latency and loss is the killer of cloud-based services with a direct 400 negative impact on performance. There are many factors can affect 401 latency, distance, routing, bandwidth and so on. CDN and deployment 402 of edge caches can help to mitigate some of the delays but only for 403 downloads and do little for upstream traffic. Delay and jitter on 404 video conferences or poor application performance still remains on 405 where traffic goes. 407 In this case, all cloud providers guarantee a minimum service level 408 to users. Users will be refunded in certain level if there is a 409 violation on SLA. The SLA is usually based on availability 410 requirements on a monthly or yearly basis from 99% to 100%. From [], 411 some operators guarantee uptime, but current no SLA is based on 412 performance indicators such as response time. The reason below this 413 is lack of such delay control and management mechanisms. 415 Visible and aware of delay performance is also necessary to maintain 416 a global view of state of art of the network. 418 4.2. Cloud-based Service Asks 420 o Deterministic Delay behavior 421 o IP packet service 422 o Delay visibility 423 o Delay management over network 424 5. Security Considerations 426 This document analyzes the standardization work on synchronization in 427 different SDOs. As no solution is proposed in this document, no 428 security concerns are raised. 430 6. IANA Considerations 432 There are no IANA actions required by this document. 434 7. References 436 7.1. Informative References 438 [I-D.finn-detnet-architecture] 440 Finn, N., Thubert, P., and M. Teener, "Deterministic Networking 441 Architecture", draft-ietf-detnet-architecture-00 (work in progress), 442 September 2016. 444 8. Acknowledgments 446 TBD 448 Authors' Addresses 450 Xian Liu 451 Huawei Technologies Co., Ltd. 452 Bantian, Longgang district 453 Shenzhen 518129, China 454 Email: lene.liuxian@huawei.com