[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/