Internet DRAFT - draft-xia-latency-critical-communication
draft-xia-latency-critical-communication
Internet Draft J. Xia
Intended status: Informational Huawei
Expires: April 2018 October 30, 2017
Architectural Considerations for
Delivering Latency Critical Communication over the Internet
draft-xia-latency-critical-communication-00.txt
Abstract
There is clear demand for Internet applications requiring critical
low-latency and reliable communication - Latency Critical
Communication (LCC).
This document is intended to stimulate LCC discussion and is not
expected to be published as an RFC.
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, 2018.
Copyright Notice
Copyright (c) 2017 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
publication of this document. Please review these documents
Xia, et al. Expires April 30, 2018 [Page 1]
Internet-Draft Delivering Low Latency Services October 2017
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
2. The Need for Low Latency Communications ...................... 3
3. Quantifying Latency .......................................... 4
3.1. Determinism ............................................. 4
3.2. Network KPIs ............................................ 4
3.3. Service KQIs ............................................ 6
3.4. Correlating KQI and KPI ................................. 6
3.5. Application Use Cases ................................... 7
3.5.1. Cloud-based Virtual Reality ........................ 8
3.5.1.1. Quality of Experience Requirements ............ 8
3.5.2. Remote Surgery ..................................... 8
3.5.2.1. Quality of Experience Requirements ............ 8
3.5.3. Live-TV Distribution in Virtualized CDN environments 9
3.5.3.1. Quality of Experience Requirements .............9
4. Measurement of Latency ...................................... 10
4.1. End-to-end Latency ..................................... 11
4.2. Per Link Latency ....................................... 12
4.3. Per Node Latency ....................................... 12
4.4. Reporting Per Link and Per Node Latency ................ 12
4.5. Isolating Latency Disruption ........................... 13
5. Mechanisms to achieve low latency flows ..................... 13
5.1. Path Computation ....................................... 13
5.2. Traffic Engineering .................................... 13
5.3. Coloring ............................................... 14
5.4. Queue Management ....................................... 14
5.5. Latency Management ..................................... 15
6. Functional Architecture for LCC ............................. 15
6.1. LCC Functional Components .............................. 16
7. Alternatives to Low Latency Networking ...................... 16
7.1. Mitigation ............................................. 16
7.2. Resource Placement ..................................... 16
7.3. Application and Resource Pipelining .................... 17
7.4. Prediction ............................................. 17
7.5. Buffering .............................................. 17
8. Security Considerations ..................................... 17
8.1 Privacy and Regulatory Issues ........................... 17
9. IANA Considerations ......................................... 17
10. References ................................................. 18
10.1. Normative References .................................. 18
10.2. Informative References ................................ 18
11. Acknowledgments ............................................ 18
Xia, et al. Expires April 30, 2018 [Page 2]
Internet-Draft Delivering Low Latency Services October 2017
1. Introduction
Latency Critical Communication (LCC) applications are increasingly
important, requiring guaranteed low-latency communication high-
reliability and ensuring quality of user experience.
Several on-going mechanisms exist for delivering LCC services within
multiple Standards Development Organizations, including: Time-
Sensitive Networking Task Group [TSN8021] in IEEE 802.1, 5G
requirements for next-generation access technology [TS38913] in 3GPP
and Broadband Assured IP Service [BAS-Architecture] in the BBF.
This draft identifies common service requirements in heterogeneous
networks for delivering LCC services, and outlines specific uses
across a spectrum of applications, specifically: cloud-based virtual
reality, remote surgery, and live-TV distribution in virtualized CDN
environments.
We may scope LCC application requirements by explicitly focusing on
end-to-end (E2E) service characteristics and capability requirements
for delivering each specific use case. Furthermore, as the E2E
service usually traverses multiple domains and involves multiple
layers. Yet, existing standards and current discussion typically
focuses on a specific layer, protocol, or link layer technology.
This focused view lacks an integrated approach or system view on
solving the LCC problem space.
This document is intended to stimulate discussion and outlines
specific LCC application requirements, and proposes an architecture
and enabling functional components to address the common
requirements discussed in each use case.
2. The Need for Low Latency Communications
Fundamentally, latency is a time interval between the stimulation
and response, or, from a more general point of view, a time delay
between the cause and the effect of change in the system being
observed.
Network latency in packet networks is measured either one-way (the
time from the source sending a packet to the destination receiving
it), or round-trip delay time (the one-way latency from source to
destination plus the one-way latency from the destination back to
the source). Some packets will be dropped, i.e., never delivered,
due to buffer overflows, synchronization failures, etc. Moreover, we
assume that packets that are decoded in error are also dropped
either by the protocol itself or by higher layers. Using the
convention that dropped packets have infinite latency, we can define
Xia, et al. Expires April 30, 2018 [Page 3]
Internet-Draft Delivering Low Latency Services October 2017
the reliability as the probability that the latency does not exceed
a pre-described value.
Our community has recognized low latency networking as an important
research problem, and devoted much attention to tackle the issue
from various perspectives, these include:
o Processing delays
o Buffer delays
o Transmission delays
o Packet loss
o Propagation delays
There are a number of common requirements across low latency use
cases (including 3GPP on Cloud RAN, front haul, back haul and by
various application layers use cases. Additional useful documents
exist that provide background and motivation for low latency
networks, including [I-D.arkko-arch-low-latency] and [I-D.dunbar-
e2e-latency-arch-view-and-gaps].
3. Quantifying Latency
LCC Applications exist for a variety of deployments, use cases are
assigned into the following categories:
o Extreme Mobile Broadband (xMBB): high speed and low latency mobile
broadband;
o Ultra-reliable Machine-type Communication (uMTC): reliability is
the key service requirement of these services;
o Massive Machine-Type Communication (mMTC) and Massive IoT (mIoT):
massive M2M and IoT connectivity;
o Critical Connections/ Ultra Reliable Low Latency Connections
(CriC/URLLC): low latency and ultra-reliable communications.
The focus of this document is to outline requirements for CriC/URLLC
use cases, specifically:
o Cloud-based virtual reality;
o Remote surgery;
o Live-TV distribution in virtualized CDN environments.
Xia, et al. Expires April 30, 2018 [Page 4]
Internet-Draft Delivering Low Latency Services October 2017
3.1. Determinism
o Difference between predictable and reliable bounds.
o Behavior of packet flow, and loss, and/or packets allowed outside
of the bounds.
3.2. Network KPIs
For each category of use case, specific KPIs are identified for
clustering requirements:
Device density:
o High: 10000 devices per km2
o Medium: 1000 - 10000 devices per km2
o Low: < 1000 devices per km2
Mobility:
o No: static users
o Low: pedestrians (0-3 km/h)
o Medium: slow moving vehicles (3 - 50 km/h)
o High: fast moving vehicles, e.g. cars and trains (> 50 km/h)
Infrastructure:
o Limited: no infrastructure available or only macro cell coverage
o Medium density: Small number of small cells
o Highly available infrastructure: Big number of small cells
available
Traffic type:
o Continuous
o Bursty
o Event driven
o Periodic
o All types
User data rate:
o Very high data rate: 1 Gbps
o High: 100 Mbps - 1 Gbps
o Medium: 50 - 100 Mbps
o Low: < 50 Mbps
Latency
o High: > 50 ms
o Medium: 10 - 50 ms
o Low: 1 - 10 ms
Reliability
o Low: < 95%
Xia, et al. Expires April 30, 2018 [Page 5]
Internet-Draft Delivering Low Latency Services October 2017
o Medium: 95 - 99%
o High: > 99%
Availability (related to coverage)
o Low: < 95%
o Medium: 95 - 99%
o High: > 99%
3.3. Service KQIs
Application requirements, can be modelled by user experience (QoE),
and qualified by service KQI. From users' point of view, QoE is the
overall performance of a system. It is a measure of E2E performance
at the services level from the user perspective and an indication of
how well the system meets the user's needs. There are many factors
affecting QoE, such as user expectations, end-to-end system effects,
etc. It is essential to establish a relation between user
expectations and QoS, considered as the ability of the network to
provide a service at a guaranteed performance level.
Network's performance can be evaluated with network KPIs such as
delay, jitter, packet loss, etc. For URLLC services, existing KPIs
are insufficient to forecast the service quality and reflect end-
users' QoE. Hence, it is important to identify useful KPIs to
quantify end-users' experiences and build the connections between
network KPI and service KQI, as shown in Figure 1. The KQI for a
given service can be expressed as a function/combination of the
KPIs, and can be expressed as follow: KQI=f(KPI1, KPI2,...,KPIn).
3.4. Correlating KQI and KPI
+-------------+
|Requirements |
+--------------+------+---------+
| | |
| | |
+-----+-----+ +----+---+ +------+----+
Service KQI | KQI1 | | KQI2 | | KQI3 |
+-----+-----+ +--------+ +-----------+
|
+-------------------------+---------------+
| | | |
Network+---v-+ +---v--+ +--------v--------+ +-v---+
KPI |KPI1 | | KPI2 | | KPI3 | | ... |
+-----+ +------+ +-----------------+ +-----+
Figure 1: KQI-KPI Correlation
Xia, et al. Expires April 30, 2018 [Page 6]
Internet-Draft Delivering Low Latency Services October 2017
The emerging LCC application services have led to composite KQIs
use, providing network measurement of specific application service
aspects (i.e., the performance of the application or service). As
there is limited experience to guide how to deliver the new LCC
services, the mapping between the KPI and KQI will require specific
3.5. Application Use Cases
3.5.1. Cloud-based Virtual Reality
Virtual Reality (VR), also known as immersive multimedia or
computer-simulated reality, is a computer technology that replicates
an environment, real or imagined, and simulates a user's physical
presence and environment to allow for user interaction.
Although some aspects of VR are becoming promising, there is still
bottleneck that prevents it from being popular. High cost,
especially for higher-end systems that try to reproduce a high-
quality experience, is one barrier to success for VR. One way to
reduce the cost of local VR computing, to make it more affordable
and increase its popularity and general usage, is to offload the
computations to a cloud-based server. This especially fits the
cloud-based VR gaming environment when connecting with multiple
parties.
+----------+
| | |
| VR | |
| +------|
| Device | |
| | |
+----------+ | ------
| /// \\\
| | VR |
+--------+ |
| | Cloud |
+----------+ | | |
| | | \\\\ ////
| VR | | ----
| +------|
| Device | |
| | |
+----------+
Figure 2: Cloud-based VR Scenario
But then, additional stringent requirements for the underlying
network are being introduced into the system, including high
bandwidth, low latency and low packet loss ratio.
Xia, et al. Expires April 30, 2018 [Page 7]
Internet-Draft Delivering Low Latency Services October 2017
3.5.1.1. Quality of Experience Requirements
To make the VR world realistic, the VR motion-to-photon latency is
recommended to be less than 20ms. However, the network transmission
latency is limited within 5ms because other VR processing (i.e.,
tracking, rendering, and displaying) latency almost consumes 15ms.
To achieve this, the VR cloud is proposed to be deployed at the
edge of operator network.
Regarding bandwidth requirements, high-end VR systems typically use
a display frame rate of 75-90 frames per second on dual HD or 4K
displays, which can result in traffic rates four to eight times that
for regular HD or 4K video respectively. Of course, low packet loss
is required to prevent video freezes or dropouts.
+-------------------+------------------+
| Name | Elements |
+-------------------+------------------+
|Service type | CriC/URLLC |
+-------------------+------------------+
|Bandwidth [Mb/s] | 4K 25Mb/s |
| | 8K 100 Mb/s |
| | 12K 418 Mb/s |
+-------------------+------------------+
| | 4K 16 Mbps |
|Bitrate(Mbps) | 8K 64 Mbps |
| | 12K 279 Mbps |
+-------------------+------------------+
|Latency | 5 ms |
+-------------------+------------------+
|Reliability | High (five 9) |
+-------------------+------------------+
Figure 3: Cloud VR Service Type
3.5.2. Remote Surgery
Remote surgery (also known as telesurgery) is the ability for a
doctor to perform surgery on a patient even though they are not
physically in the same location. It further includes the high-speed
communication networks, connecting the surgical robot in one
location to the surgeon console at another location manipulating the
robot through an operation.
Remote telesurgery allows the specialized surgeons to be available
to the patients worldwide, without the need for patients to travel
beyond their local hospital. Imagine a doctor in an urban city,
performing an urgent procedure on a patient in an inaccessible rural
area.
3.5.2.1. Quality of Experience Requirements
Xia, et al. Expires April 30, 2018 [Page 8]
Internet-Draft Delivering Low Latency Services October 2017
In order to ensure a telesurgery procedure to be highly safe, a
particularly unique demand is required on the network, at least
including very reliable connection (99.999% availability),
sufficient bandwidth to ensure adequate video resolution as required
by the remote surgeon controlling the robot, as little as possible
latency allowing the feel of instantaneous reaction to the actions
of the surgeons and of course as little as possible latency
variation (i.e., jitter) allowing system or human correction of the
latency.
+-------------------+------------------+
| Name | Elements |
+-------------------+------------------+
|Service type | CriC/URLLC |
+-------------------+------------------+
|Bandwidth [Mb/s] | Up to 1Mb/s for |
| | control commands |
+-------------------+------------------+
|Bitrate(Mbps) | 8K 64 Mbps |
+-------------------+------------------+
|Latency | 30 ms |
+-------------------+------------------+
|Reliability | High (five 9) |
+-------------------+------------------+
Figure 4: Remote Surgery Service Type
3.5.3. Live-TV Distribution in Virtualized CDN environments
Live-TV signal distribution is a growing service that a network
operator needs to support. The bandwidth needed to convey a video
stream is determined by its quality. Evolution from standard
definition (SD) and high definition (HD) quality formats towards
Ultra-High Definition (UHD) formats, including 2K and 4K UHD will
have to be carried across an IP network, thus requiring the
migration from traditional Serial Digital Interfaces (SDI)
transmission to all-IP environments.
Various paradigms exist to provide cost-effective scalable live-TV
distribution. Specifically, in live-TV distribution, uncompressed
video stream formats are used before the video is produced. Once the
video has been produced, distribution to end-users is based on
compressed video streams, which quality is adapted to the one that
fits better the user's device (i.e., compressed SD, HD or UHD
formats).
Content Delivery Networks (CDN) can be considered as a suitable
option for live-TV content delivery by means of the standardized
MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH) technique.
3.5.3.1. Quality of Experience Requirements
Xia, et al. Expires April 30, 2018 [Page 9]
Internet-Draft Delivering Low Latency Services October 2017
Transport quality (packet loss, jitter) highly impacts on users'
quality of experience (QoE). Undesired effects such as pixelization,
tiling, frame freezing, or blue screen can appear if transport
quality is slightly degraded.
Monitoring at different levels (network, computing, service) and
applying local/global KDD procedures enable dynamic adaptive CDN
reconfiguration, i.e. scaling up/down HTTP servers, reassigning
users, increasing CDN links capacity, etc.
+-------------------+------------------+
| Name | Elements |
+-------------------+------------------+
|Service type | CriC/URLLC |
+-------------------+------------------+
|Bandwidth [Mb/s] | Low 1-4 Mb/s SD |
| | Med 10 Mb/s HD |
| | High 25 Mb/s UHD |
+-------------------+------------------+
|Latency | High 50-100s ms |
+-------------------+------------------+
|Jitter | Stringent <1 ms |
+-------------------+------------------+
|Reliability | High (five 9) |
+-------------------+------------------+
|Availability | Moderate (99%) |
+-------------------+------------------+
|Mobility - UE Speed| Up to 50km/h |
+-------------------+------------------+
|Area Traffic | Normal 1s Gb/s |
| | Hotspot 10s Gb/s |
+-------------------+------------------+
|Sensor Network | No |
+-------------------+------------------+
|Massive Type | No |
+-------------------+------------------+
|Device Direct | No |
+-------------------+------------------+
|Coverage Required | Standard |
+-------------------+------------------+
|Energy Consumption | No |
| Critical | |
+-------------------+------------------+
|Type of Use Equip. | Conventional |
+-------------------+------------------+
4. Measurement of Latency
Various Internet measurement methods have been proposed to identify
latency between end hosts. Active network measurements, which
involve sending a stream of measurement data traversed along
arbitrary paths over a network, including the Internet, are amongst
the more popular methods to provision end-to-end quality-of-service.
Xia, et al. Expires April 30, 2018 [Page 10]
Internet-Draft Delivering Low Latency Services October 2017
Accurate network measurement would require mesh measurement of all
network links to collect sufficient network latency information for
network path construction based on active measurement methods. It
takes a longer time; thus, it may be possible for a small group of
nodes but not for larger number of nodes. Inaccurate measurement
over lossy network with long inter-packet delays would become an
issue, and not support real-time applications that require time
sensitive information for network path decisions.
In the [I-D.dunbar-e2e-latency-arch-view-and-gaps], several key
latency factors are listed as below:
o Generation: delay between physical event and availability of data
o Transmission: signal propagation, initial signal encoding
o Processing: Forwarding, encoding/decoding, NAT, encryption,
authentication, compress, error coding, signal translation
o Multiplexing: Delays needed to support sharing; Shared channel
acquisition, output queuing, connection establishment
o Grouping: Reduces frequency of control information and processing;
Packetization, message aggregation
From the network point of view, only the last four latency factors
are highly relevant to the network characteristic and need to be
measured.
The E2E performance has been focused on connection-less
technologies, the requirements of measuring and maintaining "flow"
state for end-user have gaps.
Measurement of network delay, performance guarantees, dynamic path
adaption, and throughput optimization, all exist but are generally
technology specific.
4.1. End-to-end Latency
A One-way Delay Metric for IPPM is defined for packets across
Internet paths based on notions introduced in the IPPM framework
with detailed introduction on the measurement methodology, error
analysis and relevant statistics. The result can be used to
indicate the performance of specific application and the
congestion state on the path traversed.
IP Flow Information Export (IPFIX) Protocol serves as a
means for transmitting Traffic Flow information over the network
from an IPFIX Exporting Process to an IPFIX Collecting Process.
Xia, et al. Expires April 30, 2018 [Page 11]
Internet-Draft Delivering Low Latency Services October 2017
IPPM or IPFIX should be sufficient for the controller of distributed
control plane to make the necessary optimization or bandwidth
control, assuming IPFIX and IPPM can measure segment, interface, and
chassis/fabric time. But if not, the extension of existing IPPM
(metrics) may be needed.
In addition, other existing technologies, such as One-Way Active
Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol
(TWAMP), are focused on providing one way and two way IP performance
metrics. Latency is one of metrics that can be used for End-to-End
deterministic latency provisioning.
Using OWAMP/TWAMP protocols or extension on that to support
measurement of flow latency performance is also feasible.
4.2. Per Link Latency
Latency related to link can be computed as the ratio between the
link length and the propagation speed over the specific medium of
the link.
The link capacities along the path as well as the way in which the
available capacity is used can have impact on the latency. Whenever
the link capacity is low, the time of getting data out of network
card to onto the medium will be high. Furthermore, capacity is often
shared and only a small proportion of the capacity may be available
to a specific flow, this is the case when links are congested.
4.3. Per Node Latency
The links along a network path are connected by network nodes, such
as core switches and routers. Transit through each node adds to the
path latency, this type of latency is referred to as
switching/forwarding latency.
To achieve optimized end-to-end low latency services, each network
node along the path needs to measure the latency metric on it. Using
OWAMP /TWAMP and/or extension on that, each network node needs to
record accurate measurements and thus requires accurate time
synchronization, which also contributes latency on the network node.
4.4. Reporting Per Link and Per Node Latency
Basically, the latency information needs to be reported from the
network node to the controller or OAM handler [RFC7491] to keep the
end-to-end latency under bound. A template that defines the LCC
connection attributes, latency, loss and etc, must be used.
Xia, et al. Expires April 30, 2018 [Page 12]
Internet-Draft Delivering Low Latency Services October 2017
In addition, an interface or mechanism to report such latency
performance information is necessary. A simple approach can be an
interface from network device to controller, which collects all the
latency performance information of each network node, and then make
a decision how to serve the flow at each network node.
4.5. Isolating Latency Disruption
When congestion occurs, it is often not being detected until it has
already induced latency. Early detection of the onset of congestion
allows the controllers to reduce their transmission rate quickly.
This could use delay based inference of congestion or early explicit
notification of congestion by the network.
However, the congestion occurred link should be separated with other
links and thus will not disrupt the other links. One feasible way is
to reserve dedicated network resources to the specific link (for a
specific application) and thus isolate the usage of the dedicated
network resources from other links.
5. Mechanisms to achieve low latency flows
The network infrastructure will need advanced interaction with LLC
applications. The network will need insight into which types of
applications are being transported, and traffic classification and
path control to ensure SLAs expected by the applications are met.
Several techniques exist to achieve this, and are discussed in the
following sub-sections.
5.1. Path Computation
The Path Computation Element (PCE) was developed to provide path
computation services for path controlled networks. The may be used
to provide path computation and policy enforcement for LCC
applications and services.
The PCE operates on a view of the network topology stored in the
Traffic Engineering Database (TED). The TED is a data store of
topology information about network nodes and links, and capacity and
metrics such as link performance (latency, latency-variation, and
packet loss). The TED may be further augmented with status
information about existing services as well.
The PCE would facilitate the setting up of LCC application paths by
computing a path based on the end-to-end network performance
criteria.
5.2. Traffic Engineering
Xia, et al. Expires April 30, 2018 [Page 13]
Internet-Draft Delivering Low Latency Services October 2017
Traffic engineering techniques, including Multiprotocol Label
Switching (MPLS) Traffic Engineering (MPLS-TE), are commonly
deployed by operators.
MPLS-TE allows for a TE scheme where the ingress node of a label
switched path (LSP) can calculate the most efficient route
(including latency minimization) through the network toward the
egress router of the LSP.
The operator typically has a pre-planning task to monitor the
physical layout of the network for capacity planning and network
visualization followed by estimation of possible TE settings of the
links, knowing how much an IGP setting affects the traffic flow and
path. Modification of TE settings to reduce latency based on network
conditions is possible, but introduces potential network instability
if changes are frequent.
Overall, TE technologies come with limitations such as scalability,
operational complexity, protocol overhead, and supervised network
optimization. Although, recent enhancements to MPLS-TE exist, the
interaction between applications and network infrastructure is still
not sufficient for the LLC challenges.
5.3. Coloring
It is possible to build colored paths through the network with the
colors representing low bandwidth, low delay, high cost, affinities.
Application traffic can then be assigned to those paths based on
traffic placement profile.
Link coloring could be used to classify specific low latency links
for LLC applications, and assigned to a logical topology for the
delay-sensitive application traffic.
MPLS-TE also supports this function, often described as
administrative groups "colors" or "link colors". Furthermore, link
coloring is supported in IP networks with the use of MT-aware IGPs.
5.4. Queue Management
Deploying queue management techniques, such as Active Queue
Management (AQM), in the network may facilitate latency reduction,
reduce network latency. It may be useful to distinguish between two
related classes of algorithms: "queue management" versus
"scheduling" algorithms.
o Queue management algorithms manage the length of packet queues by
marking or dropping packets when necessary or appropriate
Xia, et al. Expires April 30, 2018 [Page 14]
Internet-Draft Delivering Low Latency Services October 2017
o Scheduling algorithms determine which packet to send next and are
used primarily to manage the allocation of bandwidth among flows.
The two mechanisms are loosely related, they address different
performance issues and operate on different timescales.
As interactive applications (e.g. voice over IP, real time video
streaming and financial transactions) run in the Internet, high
latency and latency variation degrade application performance.
Deploying intelligent queue management and scheduling schemes to
control latency and latency variation, would provide desirable and
predictable behavior to end-to-end connections for applications
5.5. Latency Management
Latency management techniques include:
o XoDel (Controlled Delay) and FQ-CoDel (FlowQueue-CoDel) Controlled
Delay (CoDel) are queue management technologies to set limits per
packet for delay
o FlowQueue-CoDel (FQ-CoDel) is a hybrid packet scheduler/AQM
algorithm for fighting application latency across the Internet. It
is based on a two-tier Deficit Round Robin (DRR) queue scheduler,
with the CoDel AQM algorithm operating on each sub-queue.
6. Functional Architecture for LCC
A basic architecture for LCC operation will be required. These will
include the necessary components to manage the latency service,
underlay packet and transport communications infrastructure.
Xia, et al. Expires April 30, 2018 [Page 15]
Internet-Draft Delivering Low Latency Services October 2017
+-------------------------------------------------------------------+
| OSS/NMS/Application Service Coordinator |
+--+--------+-------------------------+-------------------------+---+
| | | |
| | | |
| | | |
| +--+---+ +----------------+----------------+ +--+----+
| |Policy+----+ DLN Service Orchestrator +-----+ OAM |
| |Agent | +---+------------+-------------+--+ |Handler|
| ++-----+ | | | +-----+-+
| | | | | |
| | | | | |
+---------++ +------+---+ +----+-----+ +---+------+ |
|Databases | | Service | | Packet | |Transport | |
|Latency DB+------+Controller| |Controller| |Controller| |
+--+------++ | +-----+----+ +----+-----+ +---+------+ |
| | | | | | |
| +--+--+--+ | | | |
| | | | | | |
| | DLNPC | | | | |
| +---+----+ | | | |
| | | | | |
| | | | | |
+---+-------+------------+-------------+-------------+-----------+
| Network elements |
+----------------------------------------------------------------+
6.1. LCC Functional Components
7. Alternatives to Low Latency Networking
7.1. Mitigation
Several strategies and techniques exist for reducing or negating
network latency for some time sensitive applications.
7.2. Resource Placement
There is a trend of placing resources in locations that would reduce
or negate service and application latency.
One approach to support more dynamic placement of functions,
enabling the LLC application, close to the user is to introduce
Virtualized Network Functions (NFV) at the edge of the network, near
the LCC application users to reduce end-to-end latency, time-to-
response, and unnecessary utilization of the core network
infrastructure.
Xia, et al. Expires April 30, 2018 [Page 16]
Internet-Draft Delivering Low Latency Services October 2017
Specific technology threads developing edge resource placement, via
virtual functions, include Mobile Edge Computing (MEC) and Fog
Computing.
7.3. Application and Resource Pipelining
To be discussed.
7.4. Prediction
To be discussed.
7.5. Buffering
Reducing switch queue length, or buffer occupancy, is the most
direct way to tackle the latency problem. Packet forwarders could
use deep buffers to handle bursty traffic. However, they must ensure
that this does not become detrimental to latency performance. As TCP
relies on packet drops for congestion control, it introduces
overhead for the application.
8. Security Considerations
The following list provides some security challenges and
considerations in designing and building network infrastructure for
LLC applications:
o Identification and authentication of the entities involved in the
LLC service
o Access control to the different entities that need to be connected
and capable of creating LLC services
o Processes and mechanisms to guarantee availability of LLC network
resources and protect them against attack
8.1 Privacy and Regulatory Issues
o Identification of endpoints
o Data protection to guarantee the security (confidentiality,
integrity, availability, authenticity) and privacy of the
information carried by the network for the LCC service
9. IANA Considerations
10. References
Xia, et al. Expires April 30, 2018 [Page 17]
Internet-Draft Delivering Low Latency Services October 2017
10.1. Normative References
10.2. Informative References
[TSN8021] "Time-Sensitive Networking Task Group", IEEE
(http://www.ieee802.org/1/pages/tsn.html).
[BAS-Architecture] Y.L. Jiang, "Broadband Assured IP Services
Architecture", draft WT-387-00, broadband forum (BBF), July, 2016.
[TS38913] "3rd Generation Partnership Project; Technical
Specification Group Radio Access Network; Study on Scenarios and
Requirements for Next Generation Access Technologies; (Release 14)"
[I-D.arkko-arch-low-latency] J. Arkko, "Low Latency Applications and
the Internet Architecture", draft-arkko-arch-low-latency (work in
progress), 2017.
[I-D.dunbar-e2e-latency-arch-view-and-gaps] Dunbar, L.,
"Architectural View of E2E Latency and Gaps", draft-dunbar-e2e-
latency-arch-view-and-gaps (work in progress), 2017.
[MEC_White_Paper] ETSI, "Mobile-Edge Computing - Introductory
Technical White Paper", 2014.
[RFC7491] D. King and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations ", RFC 7491, March 2015,
<http://www.rfc-editor.org/info/rfc7491>.
11. Acknowledgments
Authors' Addresses
Jinwei Xia
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: xiajinwei@huawei.com
Contributors
Ning Zong
Huawei Technologies
Email: zongning@huawei.com
Daniel King
Lancaster University
Email: d.king@lancaster.ac.uk
Xia, et al. Expires April 30, 2018 [Page 18]
