idnits 2.17.1 draft-geng-rtgwg-cfn-req-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 : ---------------------------------------------------------------------------- No issues found here. 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 (November 4, 2019) is 1635 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 150 looks like a reference -- Missing reference section? 'RFC8174' on line 150 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Working Group L. Geng 3 INTERNET-DRAFT China Mobile 4 Intended Status: Informational P. Willis 5 Expires: May 7, 2020 BT 6 November 4, 2019 8 Compute First Networking (CFN) Scenarios and Requirements 9 draft-geng-rtgwg-cfn-req-00 11 Abstract 13 Service providers are exploring the edge computing to achieve better 14 response times and transfer rate by moving the computing towards the 15 edge of the network in scenarios like 5G MEC, virtualized central 16 office, etc. Providing services by sharing computing resources from 17 multiple edges is emerging. The service nodes from multiple edges 18 normally have two key features, service equivalency and service 19 dynamics. When the computing resources attached to a single edge site 20 is overloaded, static service dispatch can possibly keep allocating 21 the service request to it and cause inefficient utilization. The 22 service request to edge computing needs to be dispatched to and 23 served by the most suitable edge to improve user experience and 24 system utilization by taking both the available computing resources 25 and network conditions into account. 27 This draft describes scenarios and requirements of Compute First 28 Networking (CFN) to make the computing and network resource to be 29 considered in a collaborative way to achieve a more balanced network- 30 based distributed service dispatching. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as 40 Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright and License Notice 54 Copyright (c) 2019 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Usage Scenarios of CFN . . . . . . . . . . . . . . . . . . . . 4 72 2.1 Cloud Based Recognition in Augmented Reality (AR) . . . . . 4 73 2.2 Connected Car . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.3 Cloud Virtual Reality (VR) . . . . . . . . . . . . . . . . . 5 75 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 Edge computing aims to provide better response times and transfer 86 rate by moving the computing towards the edge of the network. Edge 87 computing can be built on industrial PCs, embedded systems, gateways 88 and others. They are put close to the end user. There is an emerging 89 requirement that multiple edge sites (called edges too in this 90 document) are deployed at different locations to provide the service. 91 There are millions of home gateways, thousands of base stations and 92 hundreds of central offices in a city that can serve as candidate 93 edges for hosting service nodes. Depending on the location of the 94 edge and its capacity, each edge site may have different computing 95 resources to be used for a particular service. The computing 96 resources hosted on an edge is limited. At peak hour, computing 97 resources attached to the closest edge site may not be sufficient to 98 handle all the incoming requests. Longer response time or even 99 request dropping can be experienced by the user. Increasing the 100 computing resources hosted on each edge site to the potential maximum 101 capacity is neither feasible nor economical. 103 At the same time, with the new technologies such as serverless 104 computing and container based virtual functions, service node on an 105 edge can be easily created and terminated in a sub-second scale. It 106 makes the available computing resources for a service change 107 dramatically over time at an edge. 109 The traditional method of static pre-configuration of which service 110 request is dispatched to which edge causes the workload distribution 111 to be unbalanced in terms of network load and computational load. The 112 reason is there is no interaction on scheduling capability between 113 edges about the hosted computing nodes. When computing resources on 114 one edge are overloaded or even unavailable, the requests may still 115 keep coming and cause the service experience deteriorates. Most 116 current solutions use the application layer functions to solve this 117 issue. It requires L4-L7 handling of the packet processing, such as 118 reverse proxy, which takes longer connection time. It is not an 119 efficient approach for huge number of short connections. 121 Multi-site edge computing has the distributed nature. Service 122 providers are starting to build the edge platform to allow a large 123 number of requests to be served by sharing the computing resources 124 from service nodes at multiple edges in a collaborative way. That is 125 to say, a service request potentially can be handled by different 126 service nodes located in different edges and it has to be decided 127 which one is the most appropriate to serve this request in real time. 128 Such an approach can improve the system utilization to serve more end 129 users by balancing the workload distributed to multiple edges 130 intelligently. Intelligence here means considering both the network 131 conditions and available computing resources. 133 Both computing load and network status are treated as network visible 134 resources, edge site can interact with each other to provide network- 135 based service dispatching to achieve better load balancing. This is 136 called Compute First Networking (CFN) in this document. It requires 137 both network, edge and computing nodes to work coordinately for 138 service selection dispatching between user to edge and edge to edge. 139 Among them, edge to edge or inter-edge interaction is the focus of 140 CFN in IETF related work. This draft describes usage scenarios and 141 requirements of CFN. 143 1.1 Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 2. Usage Scenarios of CFN 153 This section presents several typical scenarios which require 154 multiple edge sites to interconnect and to co-ordinate with networks 155 to meet the service requirements and ensure user experience. 157 2.1 Cloud Based Recognition in Augmented Reality (AR) 159 In AR environment, the end device captures the images via cameras and 160 sends out the computing intensive service request. Normally service 161 nodes at the edge are responsible for tasks with medium computational 162 complexity or low latency requirement like object detection, feature 163 extraction and template matching, and service nodes at cloud are 164 responsible for the most intensive computational tasks like object 165 recognition or latency non-sensitive tasks like AI based model 166 training. The end device hence only handles the tasks like target 167 tracking and image display, thereby reducing the computing load of 168 the client. 170 The computing resource for a specific service at the edge can be 171 instantiated on-demand. Once the task is completed, this resource can 172 be released. The lifetime of such "function as a service" can be on a 173 millisecond scale. Therefore computing resources on the edges have 174 distributed and dynamic natures. A service request has to be sent to 175 and served by an edge with sufficient computing resource and a good 176 network path. 178 2.2 Connected Car 180 In auxiliary driving scenarios, to help overcome the non-line-of- 181 sight problem due to blind spot or obstacles, the edge node can 182 collect the comprehensive road and traffic information around the 183 vehicle location and perform data processing, and then the vehicles 184 in high security risk can be signaled. It improves the driving safety 185 in complicated road conditions, like at the intersections. The video 186 image information captured by the surveillance camera is transmitted 187 to the nearest edge node for processing. Warnings can be sent to the 188 cars driving too fast or under other invisible dangers. 190 When the local edge node is overloaded, the service request sent to 191 it will be queued and the response from the auxiliary driving will be 192 delayed, and it may lead to traffic accidents. Hence, in such cases, 193 delay-insensitive services such as in-vehicle entertainment should be 194 dispatched to other light loaded nodes instead of local edge nodes, 195 so that the delay-sensitive service is preferentially processed 196 locally to ensure the service availability and user experience. 198 2.3 Cloud Virtual Reality (VR) 200 Cloud VR introduces the concept and technology of cloud computing and 201 cloud rendering into VR applications. The end device usually only 202 uploads the posture or control information to the cloud and then VR 203 contents are rendered in the cloud. The video and audio outputs 204 generated from the cloud are encoded, compressed, and transmitted 205 back to the end device via high bandwidth network. 207 Cloud VR services have high requirements on both network and 208 computing. For example, for an entry-level Cloud VR (panoramic 8K 2D 209 video) with 110-degree Field of View (FOV) transmission, the typical 210 network requirements are bandwidth 40Mbps, RTT 20ms, packet loss rate 211 is 2.4E-5; the typical computing requirements are 8K H.265 real-time 212 decoding, 2K H.264 real-time encoding. 214 Cloud VR service brings challenging requirements on both network and 215 computing so that the edge node to serve the request has to be 216 carefully selected to avoid the overloading. 218 3. Requirements 220 CFN in this document mainly targets at the typical edge computing 221 scenarios with two key features, service equivalency and service 222 dynamics. 224 - Service equivalency: Equivalent service is provided by multiple 225 edges to ensure better scalability and availability. 227 - Service dynamics: A single edge has very dynamic resources over 228 time to serve a request. Its dynamics are affected by computing 229 resource of service node, network path congestion, failover and 230 others. 232 A service request should be routed to the most suitable edge for 233 processing. The local edge is normally the first choice. At the same 234 time, it is important to have the capability to route the request to 235 the other edges when the local edge has insufficient computing 236 resource or non-promising network path, depending on the service type 237 and/or priority. 239 The following requirements need to be met for CFN, 241 - The service provided, or function called, should be identified in a 242 format amenable to processing in the network 244 - Service request is sent in real time to the most appropriate one 245 among all the service equivalent edges for processing. Such a request 246 assignment should not be static. It should be based on the metrics 247 for the service dynamics, including both network status and available 248 computing resources. 250 - For applications that require flow affinity it must be possible to 251 have a method to signal flow affinity requirements and handle flows 252 on the same edge. 254 - Edge nodes may have limited compute resources therefore control and 255 storage overhead must be minimised 257 4. Summary 259 CFN in this document tries to leverage the network distributed nature 260 to help serve the edge computing requests in a more balanced way by 261 considering both network status and computing resources among 262 multiple edges. Inter-edge interaction is required in the dynamic 263 service dispatching and network and computing resource information 264 distribution. 266 This document illustrate some usage scenarios and requirements for 267 CFN. CFN architecture should addresses how to distribute the 268 computing resource information at the network layer, how the data 269 plane adapts when the edge to handle the first service request is not 270 known in advance, and how to assure flow affinity. 272 5. Security Considerations 274 TBD 276 6. IANA Considerations 278 No IANA action is required. 280 7. Acknowledgements 282 The author would like to thank all participants who participated in 283 the discussion of CFN at the earlier IETF/IRTF meetings. 285 8. References 287 8.1 Normative References 289 Authors' Addresses 291 Liang Geng 292 China Mobile 293 Email: gengliang@chinamobile.com 295 Peter Willis 296 BT 297 Email: peter.j.willis@bt.com