Internet DRAFT - draft-geng-rtgwg-cfn-req
draft-geng-rtgwg-cfn-req
RTGWG Working Group L. Geng
INTERNET-DRAFT China Mobile
Intended Status: Informational P. Willis
Expires: May 7, 2020 BT
November 4, 2019
Compute First Networking (CFN) Scenarios and Requirements
draft-geng-rtgwg-cfn-req-00
Abstract
Service providers are exploring the edge computing to achieve better
response times and transfer rate by moving the computing towards the
edge of the network in scenarios like 5G MEC, virtualized central
office, etc. Providing services by sharing computing resources from
multiple edges is emerging. The service nodes from multiple edges
normally have two key features, service equivalency and service
dynamics. When the computing resources attached to a single edge site
is overloaded, static service dispatch can possibly keep allocating
the service request to it and cause inefficient utilization. The
service request to edge computing needs to be dispatched to and
served by the most suitable edge to improve user experience and
system utilization by taking both the available computing resources
and network conditions into account.
This draft describes scenarios and requirements of Compute First
Networking (CFN) to make the computing and network resource to be
considered in a collaborative way to achieve a more balanced network-
based distributed service dispatching.
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."
Geng & Willis [Page 1]
INTERNET DRAFT CFN Scenarios and Requirements Nov 2019
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2019 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Usage Scenarios of CFN . . . . . . . . . . . . . . . . . . . . 4
2.1 Cloud Based Recognition in Augmented Reality (AR) . . . . . 4
2.2 Connected Car . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Cloud Virtual Reality (VR) . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . . 7
Geng & Willis [Page 2]
INTERNET DRAFT CFN Scenarios and Requirements Nov 2019
1. Introduction
Edge computing aims to provide better response times and transfer
rate by moving the computing towards the edge of the network. Edge
computing can be built on industrial PCs, embedded systems, gateways
and others. They are put close to the end user. There is an emerging
requirement that multiple edge sites (called edges too in this
document) are deployed at different locations to provide the service.
There are millions of home gateways, thousands of base stations and
hundreds of central offices in a city that can serve as candidate
edges for hosting service nodes. Depending on the location of the
edge and its capacity, each edge site may have different computing
resources to be used for a particular service. The computing
resources hosted on an edge is limited. At peak hour, computing
resources attached to the closest edge site may not be sufficient to
handle all the incoming requests. Longer response time or even
request dropping can be experienced by the user. Increasing the
computing resources hosted on each edge site to the potential maximum
capacity is neither feasible nor economical.
At the same time, with the new technologies such as serverless
computing and container based virtual functions, service node on an
edge can be easily created and terminated in a sub-second scale. It
makes the available computing resources for a service change
dramatically over time at an edge.
The traditional method of static pre-configuration of which service
request is dispatched to which edge causes the workload distribution
to be unbalanced in terms of network load and computational load. The
reason is there is no interaction on scheduling capability between
edges about the hosted computing nodes. When computing resources on
one edge are overloaded or even unavailable, the requests may still
keep coming and cause the service experience deteriorates. Most
current solutions use the application layer functions to solve this
issue. It requires L4-L7 handling of the packet processing, such as
reverse proxy, which takes longer connection time. It is not an
efficient approach for huge number of short connections.
Multi-site edge computing has the distributed nature. Service
providers are starting to build the edge platform to allow a large
number of requests to be served by sharing the computing resources
from service nodes at multiple edges in a collaborative way. That is
to say, a service request potentially can be handled by different
service nodes located in different edges and it has to be decided
which one is the most appropriate to serve this request in real time.
Such an approach can improve the system utilization to serve more end
users by balancing the workload distributed to multiple edges
intelligently. Intelligence here means considering both the network
Geng & Willis [Page 3]
INTERNET DRAFT CFN Scenarios and Requirements Nov 2019
conditions and available computing resources.
Both computing load and network status are treated as network visible
resources, edge site can interact with each other to provide network-
based service dispatching to achieve better load balancing. This is
called Compute First Networking (CFN) in this document. It requires
both network, edge and computing nodes to work coordinately for
service selection dispatching between user to edge and edge to edge.
Among them, edge to edge or inter-edge interaction is the focus of
CFN in IETF related work. This draft describes usage scenarios and
requirements of CFN.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Usage Scenarios of CFN
This section presents several typical scenarios which require
multiple edge sites to interconnect and to co-ordinate with networks
to meet the service requirements and ensure user experience.
2.1 Cloud Based Recognition in Augmented Reality (AR)
In AR environment, the end device captures the images via cameras and
sends out the computing intensive service request. Normally service
nodes at the edge are responsible for tasks with medium computational
complexity or low latency requirement like object detection, feature
extraction and template matching, and service nodes at cloud are
responsible for the most intensive computational tasks like object
recognition or latency non-sensitive tasks like AI based model
training. The end device hence only handles the tasks like target
tracking and image display, thereby reducing the computing load of
the client.
The computing resource for a specific service at the edge can be
instantiated on-demand. Once the task is completed, this resource can
be released. The lifetime of such "function as a service" can be on a
millisecond scale. Therefore computing resources on the edges have
distributed and dynamic natures. A service request has to be sent to
and served by an edge with sufficient computing resource and a good
Geng & Willis [Page 4]
INTERNET DRAFT CFN Scenarios and Requirements Nov 2019
network path.
2.2 Connected Car
In auxiliary driving scenarios, to help overcome the non-line-of-
sight problem due to blind spot or obstacles, the edge node can
collect the comprehensive road and traffic information around the
vehicle location and perform data processing, and then the vehicles
in high security risk can be signaled. It improves the driving safety
in complicated road conditions, like at the intersections. The video
image information captured by the surveillance camera is transmitted
to the nearest edge node for processing. Warnings can be sent to the
cars driving too fast or under other invisible dangers.
When the local edge node is overloaded, the service request sent to
it will be queued and the response from the auxiliary driving will be
delayed, and it may lead to traffic accidents. Hence, in such cases,
delay-insensitive services such as in-vehicle entertainment should be
dispatched to other light loaded nodes instead of local edge nodes,
so that the delay-sensitive service is preferentially processed
locally to ensure the service availability and user experience.
2.3 Cloud Virtual Reality (VR)
Cloud VR introduces the concept and technology of cloud computing and
cloud rendering into VR applications. The end device usually only
uploads the posture or control information to the cloud and then VR
contents are rendered in the cloud. The video and audio outputs
generated from the cloud are encoded, compressed, and transmitted
back to the end device via high bandwidth network.
Cloud VR services have high requirements on both network and
computing. For example, for an entry-level Cloud VR (panoramic 8K 2D
video) with 110-degree Field of View (FOV) transmission, the typical
network requirements are bandwidth 40Mbps, RTT 20ms, packet loss rate
is 2.4E-5; the typical computing requirements are 8K H.265 real-time
decoding, 2K H.264 real-time encoding.
Cloud VR service brings challenging requirements on both network and
computing so that the edge node to serve the request has to be
carefully selected to avoid the overloading.
3. Requirements
CFN in this document mainly targets at the typical edge computing
Geng & Willis [Page 5]
INTERNET DRAFT CFN Scenarios and Requirements Nov 2019
scenarios with two key features, service equivalency and service
dynamics.
- Service equivalency: Equivalent service is provided by multiple
edges to ensure better scalability and availability.
- Service dynamics: A single edge has very dynamic resources over
time to serve a request. Its dynamics are affected by computing
resource of service node, network path congestion, failover and
others.
A service request should be routed to the most suitable edge for
processing. The local edge is normally the first choice. At the same
time, it is important to have the capability to route the request to
the other edges when the local edge has insufficient computing
resource or non-promising network path, depending on the service type
and/or priority.
The following requirements need to be met for CFN,
- The service provided, or function called, should be identified in a
format amenable to processing in the network
- Service request is sent in real time to the most appropriate one
among all the service equivalent edges for processing. Such a request
assignment should not be static. It should be based on the metrics
for the service dynamics, including both network status and available
computing resources.
- For applications that require flow affinity it must be possible to
have a method to signal flow affinity requirements and handle flows
on the same edge.
- Edge nodes may have limited compute resources therefore control and
storage overhead must be minimised
4. Summary
CFN in this document tries to leverage the network distributed nature
to help serve the edge computing requests in a more balanced way by
considering both network status and computing resources among
multiple edges. Inter-edge interaction is required in the dynamic
service dispatching and network and computing resource information
distribution.
This document illustrate some usage scenarios and requirements for
CFN. CFN architecture should addresses how to distribute the
computing resource information at the network layer, how the data
Geng & Willis [Page 6]
INTERNET DRAFT CFN Scenarios and Requirements Nov 2019
plane adapts when the edge to handle the first service request is not
known in advance, and how to assure flow affinity.
5. Security Considerations
TBD
6. IANA Considerations
No IANA action is required.
7. Acknowledgements
The author would like to thank all participants who participated in
the discussion of CFN at the earlier IETF/IRTF meetings.
8. References
8.1 Normative References
Authors' Addresses
Liang Geng
China Mobile
Email: gengliang@chinamobile.com
Peter Willis
BT
Email: peter.j.willis@bt.com
Geng & Willis [Page 7]
