Network Working Group X. Liu
Huawei Technologies
Internet-Draft
Intended status: Informational
Expires: April 2017 October 31, 2016
Deterministic Latency Network Use Cases
draft-liu-dln-use-cases-00
Abstract
This draft documents low latency requirements in several diverse
industries including virtual reality, electrical utilities protection
and cloud-based service. For each case, this document will identify
the application, representative solutions used today and its
requirements on deterministic latency mechanism.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 30, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Liu Expires April 30 2017 [Page 1]
Internet-Draft Use cases of DLN October 2016
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction .............................................. 2
1.1. Conventions used in this document ...................... 3
2. Cloud VR/Gaming Service ................................... 3
2.1. Use Case Description ................................... 3
2.2. Delay in a VR system ................................... 4
2.3. Cloud VR/Gaming Asks ................................... 7
3. Electrical Utility Relay Protection ....................... 7
3.1. Use Case Description ................................... 7
3.2. Delay Requirements on Protection Scheme ................ 8
3.3. Precision Delay Compensate Technology .................. 9
3.4. Relay Protection Asks .................................. 9
4. Cloud-based Service ....................................... 9
4.1. Use Case Description ................................... 9
4.2. Cloud-based Service Asks .............................. 10
5. Security Considerations .................................. 10
6. IANA Considerations ...................................... 10
7. References ............................................... 10
7.1. Informative References ................................ 10
8. Acknowledgments .......................................... 11
1. Introduction
Deterministic latency network (DLN) is defined to provide guaranteed
deterministic latency for specific traffic, especially for latency-
critical traffic. However, there are no current off-the-shelf
solutions for DLN. Distinguished from DetNet [I-D.finn-detnet-
architecture] that focuses on the solution of Layer 2-3 packet
forwarding, a feasible DLN solution is supposed to provide a latency
information obtaining mechanism including delay-aware modeling and
measurement, latency management mechanism with interfaces and
protocols to maintain the performance of latency sensitive
applications. Latency slicing and latency modeling are alternatives
in discussion currently. More specifically, DLN is:
-Face to upper layer, define delay-aware PHB and related OAM
interfaces;
Liu Expires April 30 2017 [Page 2]
Internet-Draft Use cases of DLN October 2016
-Targeting at WAN, support multiple data techniques including TSN;
-Working together with DetNet, and also have constraints on traffic
flow, device capability, and etc.
This draft elaborates use cases from diverse industries along with
their stringent requirements for deterministic low latency. Together,
they provide broad industry context for DLN and a yardstick against
which proposed DLN solutions can be measured.
For each use case, we identify the application with its latency
requirement, and specify its representative solutions used today as
well as problems to be settled on deterministic latency mechanisms.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Cloud VR/Gaming Service
2.1. Use Case Description
Virtual reality (VR) systems track one or more objects to generate
the depiction of a virtual environment from the user's vantage point.
Free viewpoint television (FTV) as a typical application of VR allows
the user to interactively control the viewpoint and generate new
views of a dynamic scene from any 3D position by transmitting all
views of 3D space to user and rendering new images according user's
turn locally, which requires large bandwidths, 1Gbps for 4K FTV and
4Gbps for 16K FTV, unavailable in subscriber network. VR gaming
allows the user to experience being in a three-dimensional
environment and interact with the environment during a game through
dedicated equipments. Large bandwidth requirement and high cost of
the customized hardware with immense computational power make VR
inaccessible to the average consumer.
To address these challenges, cloud-based virtual reality is proposed
by carriers to alleviate complex processing and high bandwidth on
user side by outsourcing the computational power necessary to encode
videos or render games to distant server farms and delivering only
video content to user. Then carriers can serve as media providers in
broadcast and streaming for sports and live events, or as
Liu Expires April 30 2017 [Page 3]
Internet-Draft Use cases of DLN October 2016
infrastructure provider for third-part VR applications. By reducing
initial cost of virtual reality and removing the need d for consumers
to constantly upgrade their equipments every few years, cloud based
virtual reality is much more attainable.
2.2. Delay in a VR system
In this use case we consider the latency between the time user start
to turn and the time the image is redrawn to account for the new pose
in a cloud based VR system. A high latency may induce simulator
sickness due to the virtual image drifting, reduce the subjective
sense of "presence", and change the pattern of behavior such that
users make more errors during speeded reaching, grasping, or object
tracking. To deliver good experiences, 20 ms of latency or much less
is recommended for a VR system to prevent simulator sickness.
The latency of a VR system mainly comes from the following steps:
1) Tracking has to capturing the exact pose of the HMD (Head Mount
Display), that is, the exact position and orientation in the real
world. Tracking latency is highly dependent on the system used. An
IMU (3-DOF gyro and 3-DOF accelerometer) has low latency on the order
of 1 ms, but drifts. Camera-based tracking doesn't drift, but has
high latency of 10-15 ms. Right now one of the lowest-latency non-
drifting accurate systems out there is a high-end system from NDI,
which has about 4 ms of latency. To reduce the tracking latency, the
obvious solution is using both optical tracking and an IMU, via
sensor fusion. The IMU can be used to provide very low-latency state,
and optical tracking can be used to correct the IMU's drift. Properly
implemented, sensor fusion can reduce the tracking latency to about
1.5 ms.
2) The graphic system has to render the scene as viewed from that
pose. Rendering latency depends on CPU and GPU capabilities and on
the graphics complexity of the scene being drawn. A VR system
requires at least 60 Hz for a good experience, and the corresponding
rendering latency is 16ms. When this step is moved to the cloud, the
rendering latency can be reduced to about 7.4 ms by distributed
parallel processing.
3) Transmission of the rendered output from the cloud to the user's
device over IP induces a transmit latency which is unpredicted
currently.
4) The graphics hardware has to transfer the rendered scene to the
HMD's display. This is called scan-out, and involves reading
sequentially through the frame buffer from top to bottom, moving
Liu Expires April 30 2017 [Page 4]
Internet-Draft Use cases of DLN October 2016
right to left within each scan line, and streaming the pixel data for
the scene over a link such as HDMI to the display. At 200Hz, the
displaying latency is on the order of 6ms.
The total latency of tracking, rendering and displaying is
1.5+7.4+6=14.9ms. So the suggested budget for transmit delay is 5ms
to keep the total latency down to 20 ms.
+----------------------+
+------------------------------+ | Rendering Latency |
| +-------+ +--------+ | |+-------+ +---------+|
| |Sensors|-----| A/D | | ||cloud |--|rendering||
| +-------+ +---/----+ | +----||process| +---------+|
| | | | |+-------+ | |
| +----------+ +---/--------+| | |+---------+ +--------+|
| |terminal |---|signal || | ||video |-|video ||
| |processing| |transmission|| | ||streaming| |encoding||
| +----/-----+ +------------+| | |+---------+ +--------+|
| Tracking Latency | | +----------------------+
+------|-----------------------+ +------------+
| |network |
| |transmission|
+--------------------------/ |
| |
+------------+
Transmit Latency
+------------+
|network |
|transmission|
| |
+------------+
+----------------------------+ |
| Displaying Latency | |
| +----------+ +---/------+| |
| | |---|Video ||----------+
| |displaying| |decoding ||
| +----/-----+ +----------+|
+----------------------------+
Figure 1 End-to-End Cloud VR System
Liu Expires April 30 2017 [Page 5]
Internet-Draft Use cases of DLN October 2016
Two deployments of cloud-based virtual reality are proposed in this
use case to keep the transmit latency down to 5ms. One is deploying
the central cloud access to the BRAS, and the other one is deploying
the central cloud access to the CO. There is a tradeoff between
latency and OPEX. Both of them require the network to guarantee a
deterministic low latency for VR traffic.
/''''
| \
/'''' \
/ \
| VR Cloud |
+-------+ ,,,,,,,,,,,,,,,
| VR |-----| |
|Devices| | +-----+ +-----+ +------+ +------------+
+-------+ |-----| ONT |----| OLT |------| BRAS |-----| Core Router|
| +-----+ +-----+ +------+ +------------+
+-------+ |
| VR |-----|
|Devices|
+-------+
Figure 2. VR Cloud on CO Position
/''''
| \
/'''' \
/ \
| VR Cloud |
+-------+ ,,,,,,,,,,,,,,,
| VR |-----| |
|Devices| | +-----+ +-----+ +------+ +-------------+
+-------+ |-----| ONT |----| OLT |------| BRAS |-----| Core Router |
| +-----+ +-----+ +------+ +-------------+
+-------+ |
| VR |-----|
|Devices|
+-------+
Figure 3. VR Cloud on Bras Position
Liu Expires April 30 2017 [Page 6]
Internet-Draft Use cases of DLN October 2016
In this case, assured transmission latency for VR traffic is the key
to cloud-based virtual reality. New latency-aware packet forwarding
mechanism is required for the network to guarantee the deterministic
latency for this latency-critical traffic. Along with this forwarding
mechanism, the latency is required to be measurable and manageable to
maintain the performance of VR.
2.3. Cloud VR/Gaming Asks
o Deterministic Delay behavior
o IP packet service
o Ultra low delay less than 5ms
o Delay management over network
3. Electrical Utility Relay Protection
3.1. Use Case Description
The effective operation of an electrical utility depends on high
validity and deterministic behavior of the fundamental networks.
Protection means not only to protect the operator but also to protect
the stability of the electrical equipment. If a transmission or
distribution power failure happens, it will cause damage to the
operator and large blackouts. The role of the protection system of
the electrical utility is to selectively trip out a faulty part by
delivering command signals as soon as possible.
The basic principal of protection scheme is that, by monitoring the
abnormal voltage or current changes in power primary equipment or
transmission lines, the logic program can identify a device or a
transmission line fault point and control circuit breaker to trip in
time. The current value is the same at both ends of the transmission
line during normal operation, and when this transmission line fails,
the current at both ends will not match. When the differential
current is greater than the setting value, the circuit breaker will
be tripped on each side of the protected device, so that faulty
equipment disconnects the power.AS is shown in Figure 1, A and B on
behaves of the line protection equipment, T1 and T2 refers to the
time delay of two opposite directions, Im and In refers to the current
of two opposite directions, Ik is the result of Im plus In, if Ik
equals to 0, there is no trouble between A and B, otherwise, some
faults are here.
Liu Expires April 30 2017 [Page 7]
Internet-Draft Use cases of DLN October 2016
Im------- Ik -------In
+---+ | | | +---+
| A |--|-----------|-------------|--| B |
+---+ | | | +---+
| | | |
| | | |
| +-------------T1----------------+ |
+------------------T2-------------------+
/-------------------------------------\
|Normal or external trouble, Ik=Im+In=0|
|internal trouble, Ik=Im+In 0 |
\-------------------------------------/
/----------------------------\
| T1 is the delay from A to B|
| T2 is the delay from B to A|
| Asymmetric=|T1-T2| |
\----------------------------/
Figure 4 Electrical Utility Relay Protection
3.2. Delay Requirements on Protection Scheme
Right now everything is moving to IP network. In order to realize the
effective differential protection, time delay need to be taken into
consideration. As shown in Figure 1, T1 and T2 must be less than 5ms.
The most important thing is that the difference between T1 and T2
must be less than 20us. More detailed requirements are shown in the
following table:
+------------------------------+---------------------------------+
|Power relay requirements |Attributes |
+------------------------------+---------------------------------+
|Interface type |E1 interface |
+------------------------------+---------------------------------+
|Full nodes |Less than or equal 15 |
+------------------------------+---------------------------------+
|Total transmission distance |About 500KM |
+------------------------------+---------------------------------+
|One way delay |Less than 5ms |
|Maximum jitter |10us |
+------------------------------+---------------------------------+
|Asymmetric delay |Less than 20us |
+------------------------------+---------------------------------+
Liu Expires April 30 2017 [Page 8]
Internet-Draft Use cases of DLN October 2016
Table 1: Power Relay Requirements
3.3. Precision Delay Compensate Technology
The effective differential protection relies on synchronous sampling.
It means that the protective device on both sides of the transmission
line requires synchronous sampling. When both sides of relay
protection exists sampling time difference, it will produce a
corresponding differential current value. If the differential current
value exceeds the threshold value, the protection may miss operate.
Synchronous sampling is based on the consistency of the two-way
channel delay, which implies that the smaller the asymmetric is, the
better differential protection behaves. So the relay protection has
strict requirements on asymmetric delay, it must be less than 20us.
SDH technology has become the mainstream of the electric power
communication network technology. In recent years, with the process
of smart grid construction accelerated, more variety, a greater flow
of business types gradually add in electric power communication
network. It becomes more and more difficult for SDH network to
satisfy time delay in the differential protection. So the main
electric power communication network service is from the traditional
TDM business gradually transformed into IP packet service. The highly
precise time delay compensate technology plays an important role in
IP packet service, which can solve the problem of time delay in the
differential protection.
3.4. Relay Protection Asks
o Deterministic behavior
o Synchronous sampling
o IP packet service
o 20us Asymmetric delay
o Delay information for compensation technology
4. Cloud-based Service
4.1. Use Case Description
Cloud-based services those are any resources provided over the
network. Commonly, the cloud providers provide computing, storage as
well infrastructures as a service which is accessible from network.
More and more companies are switching to the cloud since it is more
efficient, secure and reliable. The performance is the key matter of
cloud-based services, as fast and predictable response from remote
location at any volume is the determinant of user experience.
Liu Expires April 30 2017 [Page 9]
Internet-Draft Use cases of DLN October 2016
Latency and loss is the killer of cloud-based services with a direct
negative impact on performance. There are many factors can affect
latency, distance, routing, bandwidth and so on. CDN and deployment
of edge caches can help to mitigate some of the delays but only for
downloads and do little for upstream traffic. Delay and jitter on
video conferences or poor application performance still remains on
where traffic goes.
In this case, all cloud providers guarantee a minimum service level
to users. Users will be refunded in certain level if there is a
violation on SLA. The SLA is usually based on availability
requirements on a monthly or yearly basis from 99% to 100%. From [],
some operators guarantee uptime, but current no SLA is based on
performance indicators such as response time. The reason below this
is lack of such delay control and management mechanisms.
Visible and aware of delay performance is also necessary to maintain
a global view of state of art of the network.
4.2. Cloud-based Service Asks
o Deterministic Delay behavior
o IP packet service
o Delay visibility
o Delay management over network
5. Security Considerations
This document analyzes the standardization work on synchronization in
different SDOs. As no solution is proposed in this document, no
security concerns are raised.
6. IANA Considerations
There are no IANA actions required by this document.
7. References
7.1. Informative References
[I-D.finn-detnet-architecture]
Finn, N., Thubert, P., and M. Teener, "Deterministic Networking
Architecture", draft-ietf-detnet-architecture-00 (work in progress),
September 2016.
Liu Expires April 30 2017 [Page 10]
Internet-Draft Use cases of DLN October 2016
8. Acknowledgments
TBD
Authors' Addresses
Xian Liu
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129, China
Email: lene.liuxian@huawei.com
Liu Expires April 30 2017 [Page 11]