idnits 2.17.1 draft-liu-alto-can-usecase-01.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 17 characters in excess of 72. 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 (20 January 2022) is 799 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.contreras-alto-service-edge' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'RFC7971' is defined on line 460, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-contreras-alto-service-edge-03 == Outdated reference: A later version (-08) exists of draft-li-dyncast-architecture-00 == Outdated reference: A later version (-04) exists of draft-liu-dyncast-ps-usecases-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Application-Layer Traffic Optimization P. Liu 3 Internet-Draft Y. Fu 4 Intended status: Informational China Mobile 5 Expires: 24 July 2022 20 January 2022 7 Computing-aware Networking Use case of ALTO 8 draft-liu-alto-can-usecase-01 10 Abstract 12 The ever-emerging new services are imposing more and more highly 13 demanding requirements on the network. In order to meet these 14 requirements, some new technology trends of network emerge as the 15 times require. On the one hand, for the selection of service node 16 and forwarding path, in addition to considering the network topology 17 and link state, more factors are also considered, such as the 18 computing properties of service node; On the other hand, network and 19 application present the trend of mutual perception, including 20 application to perceive the state of network path, or network to 21 perceive the demand of application. 23 This draft describes a new network scenario and architecture 24 considering computational properties, and assumes that Alto could be 25 used as an important node to realize the deployment of services, and 26 to assist in the selection of service nodes. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 24 July 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Usage Scenarios of CAN . . . . . . . . . . . . . . . . . . . 4 68 2.1. AR/VR . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. Internet of Vehicles . . . . . . . . . . . . . . . . . . 5 70 3. CAN Framework and ALTO . . . . . . . . . . . . . . . . . . . 5 71 4. Deployment of CAN with ALTO . . . . . . . . . . . . . . . . . 7 72 5. Scheduling of CAN with ALTO . . . . . . . . . . . . . . . . . 8 73 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 10. Informative References . . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 For new services with heavy computing tasks, such as AR/VR, video 83 recognition and so on, the computing time and network transmission 84 delay are almost the same order of magnitude. In this kind of 85 scenario, computing attributes become more important than traditional 86 services. 88 The generation of edge computing is to solve such problems. Edge 89 computing is to deploy service nodes close to the user side, which 90 shortens the distance of network transmission. Moreover, it can 91 deploy specific computing resources, such as CPU/GPU, to meet the 92 needs of different services. 94 It is predicted by Gartner that by 2025, more than 50% of the 95 computing data needs to be analyzed, processed, and stored at the 96 edge. Since the service providers begins to offer the edge computing 97 infrastructure to provide better response time and transfer rate. 98 There are also some challenges of edge computing itself, which are 99 pointed out in the work of dyncast [draft-liu-dyncast-ps-usecases- 100 01], [draft-li-dyncast-architecture-00] : 102 * Geographically Scattered Large Number of Edge Sites. The edge 103 sites are highly distributed and may not have proximate distances to 104 user. 106 * Resource Limitation. There are fewer servers of server per node. 108 * Heterogeneous Hardware, such as CPU, GPU, Memory, ASICs. 110 * Dynamic Load. The available resources may change quickly. 112 * Edge-cloud Coordination. Edge does not solve all requests. 114 * High Cost. On-site maintenance is expensive. 116 * Mission Critical. Users are counting on you for 100% reliability 117 of industry automation. 119 So how to collaboratively deploy and computing services based on the 120 computing resources in network to meet the diverse computing 121 requirements, and achieve the on-demand allocation and dispatch of 122 service request needs be studied. 124 Some existing works have begun to consider the computing attributes. 125 For example, coinrg initiated the consideration of computing and 126 storage resources. Dyncast 127 [I-D.liu-dyncast-ps-usecases][I-D.li-dyncast-architecture] proposed 128 how to introduce the scheme of computing metric at the routing level. 129 Semantic routing[], which also extends the semantics of routing in a 130 broad sense. However, today's routing system and technology has been 131 relatively good, the introduction of more metric in routing still 132 need more theoretical and experimental verification. In the work of 133 ITU, it is more from the perspective of architecture, such as ITU 134 Y.CAN-reqts [Y.CAN-reqts: "functional requirements of Computing-aware 135 Networking"] proposed a new network architecture-computing-aware 136 networking (CAN), CAN schedules service request to the optimal 137 computing site along optimal path to meet service requirements both 138 on network and computing. ITU.Y.CPN-arch [Y.CPN-arch: "Framework and 139 architecture of Computing power Network"]provides the framework and 140 architecture of Computing power Network, specifies its functional 141 entities and defines the functionalities of these functional 142 entities. So the convergence of network and computing brought by 143 edge computing includes the issue of service deployment and service 144 request scheduling. ALTO has done the work of collect the network 145 information for application, it may help to do some work in the two 146 important issues: 148 How to deploy service nodes based on computing resources. For this 149 point, [draft-contras-alto-service-edge-02] gives the corresponding 150 idea of using Alto to deploy edge computing nodes. Alto can better 151 interact with the upper application, fully understand the 152 requirements of the application, including computing requirements and 153 collect the information of infrastructure resources. 155 How to select the most suitable node for service request. Alto can 156 also help this kind of work to a certain extent. Centralized 157 selection of service nodes and paths is relatively easy to implement, 158 such as SDN. However, emerging service requests require high real- 159 time performance, and there may be some efficiency and complexity 160 problems, which have been analyzed in the work of dyncast. 162 2. Usage Scenarios of CAN 164 Any multi-point deployment service that requires high computing power 165 or low latency will involve the joint scheduling of network and 166 computing resources. 168 2.1. AR/VR 170 Take the AR/VR as an example. The upper bound latency for motion-to- 171 photon (MTP) is less than 20 milliseconds to avoid the motion 172 sickness. It consists of four parts, and the frame rendering 173 computing delay is 5.5 milliseconds, so the network delay demand can 174 be calculated as 5.1milliseconds. 176 +-----------------------+---------------------+ 177 | Total MTP delay | 50ms | 178 +-----------------------+---------------------+ 179 | sensor sampling delay | <1.5ms | 180 +-----------------------+---------------------+ 181 | display refresh delay | 5 ms | 182 +-----------------------+---------------------+ 183 | frame rendering delay | 5.5ms | 184 | computing with GPU | | 185 +-----------------------+---------------------+ 186 | network delay | 20-1.5-5.5-7.9=5.1ms| 187 +-----------------------+---------------------+ 189 Figure 1: Delay of MTP 191 So the budgets for computing delay and network delay are almost 192 equivalent. Considering another factor that the computing resources 193 have a big difference in different edges,it is necessary to apply 194 dynamically steer traffic to the 'best' edge. 196 2.2. Internet of Vehicles 198 Under the scenario of Internet of Vehicles, the services are divided 199 into auxiliary driving and on-board entertainment services . For the 200 auxiliary driving function, for road traffic conditions outside the 201 line of sight due to obstructions, blind areas, etc., the edge 202 computing node obtains comprehensive road traffic information around 203 the location of the vehicle, performs unified data processing, and 204 sends out warning signals for vehicles with potential safety hazards, 205 to assist the safe driving of vehicles. 207 Apparently, there are obviously differences between services 208 requirements of auxiliary driving services and entertainment 209 services, which needs to be processed by different edge nodes 211 3. CAN Framework and ALTO 213 In order to realize ubiquitous computing and service awareness, 214 interconnection and collaborative scheduling, the computing-aware 215 networking architecture can be divided into computing service layer, 216 computing resource layer, computing routing layer, network resource 217 layer, and computing and network management layer. Among them, the 218 computing routing layer contains the control plane and data plane 219 which is shown in Figure 2. Based on the ubiquitous computing 220 resources of the network, the computing resource layer abstracts and 221 models based on a unified measurement and modeling template, and 222 announces computing information to the computing routing layer. And 223 then the computing routing layer comprehensively considers user needs 224 and network resource status and computing resource status, to 225 schedule service requests to appropriate computing nodes. In 226 addition, the computing management layer completes the control and 227 management of computing resources. 229 Computing-aware Networking Framework 230 +---------------------------------------+ +------------------------+ 231 | Computing Service Layer |<->| Computing and Network | 232 +---------------------------------------+ | Management Layer | 233 | Computing Resource Layer |<->|+----------------------+| +---------+ 234 +---------------------------------------+ || Service Orchestration|<--------| | 235 | Computing-aware Routing Layer | |+----------------------+| | | 236 | +---------------+ +---------------+ |<->|| Computing OAM |<--------| | 237 | | Control Plane | | Data Plane | | |+----------------------+| | ALTO | 238 | +---------------+ +---------------+ |<->|| Routing Management |<--------| | 239 +---------------------------------------+ |+----------------------+| | | 240 | Network Resource Layer |<->|| Resource Management |<--------| | 241 +---------------------------------------+ |+----------------------+| +---------+ 243 Figure 2: CAN Framework and ALTO 245 * Computing service layer: computing service layer is computing 246 service provider, which deploys, operates and manages many kinds of 247 computing services and applications. In addition, it can realize the 248 functions of service decomposition and service scheduling through the 249 API gateway. 251 * Computing resource layer: it is based on the existing computing 252 infrastructure, and includes a combination of computing resources 253 from single-core CPU to multi-core CPU, CPU+GPU+FPGA, etc. And it 254 could supply computing modeling function, computing API function, 255 computing resource identification and other functions to meet the 256 diverse computing needs of different applications based on physical 257 computing resources. 259 * Computing-aware routing layer: It contains control plane and data 260 plane, performs computing-aware routing and generates service 261 scheduling policy in network layer. Based on the discovery of 262 abstracted computing and network resources, computing routing layer 263 generates new routing tables which include the information of 264 computing in network, considers the state of network and computing 265 comprehensively, and thus generates routing policy for different 266 service requests. Network resource layer: It utilizes the existing 267 network infrastructure, which includes access network, metropolitan 268 area network and backbone network, to provide ubiquitous network 269 connection. 271 * Computing and network management layer: It adds management 272 functions towards computing resources and computing services based on 273 the traditional network management function. Therefore, the 274 computing and network management layer performs service 275 orchestration, resource management, routing measurement and computing 276 OAM. In addition, the computing and network management layer could 277 be used to perform the pre-configuration function and management 278 function, which interacts with each functional layer. 280 * Network resource layer: using the existing network infrastructure 281 to provide network connection, network infrastructure includes access 282 network, metropolitan area network and backbone network. 284 Based on the five functional modules defined above, computing-aware 285 networking can realize the awareness, control and scheduling of 286 computing and network resources, and further perform dynamic and on- 287 demand service scheduling. The function of computing and network 288 management layer may be realized by Alto or by opening interface with 289 Alto. Considering a single ALTO Client as part of the Computing and 290 Network Management Layer aggregating all the requests towards the 291 ALTO Server, this also could decouple the solution from a specific 292 CAN architecture. 294 4. Deployment of CAN with ALTO 296 With the development of edge computing, there is multiple services 297 duplication deployed in different edge nodes. To improve the 298 effectiveness of service deployment, the problem of how to choose 299 optimal edge node to deploy services needs to be solved. More stable 300 static information should be considered in service deployment, 301 [I-D.contreras-alto-service-edge]introduces the consideration of 302 depoly applications or functions to the edge, such as the type of 303 instance, interface option associated bandwidth of the network 304 interface, compute flavor of CPU/GPU, etc, optional storage 305 extension, optional hardware acceleration characteristics. 307 Besides those, more network and service factors may to be considered 308 to meet the CAN Framework, such as 310 * Network and computing resource topology: the overall consideration 311 of network access, connectivity, path protection or redundancy. and 312 the location and overall distribution of computing resources in 313 network, and the relative position towards network topology. 315 * Location: the number of users brought, the differentiation of 316 service types and number of connections requested by users, etc. For 317 edge nodes located in popular area, which with large amount of users 318 and service requests, the service duplication can be deployed more 319 than other areas. 321 * Capacity of multiple edge nodes: not only a single node, but also 322 the total number of requests that can be processed by the resource 323 pool composed of multiple nodes 325 * Service category: For example, whether the business is multi-user 326 interaction, such as video conferencing, games, or just resource 327 acquisition, such as short video viewing Alto can help to obtain one 328 or more of the above information, so as to provide suggestions or 329 formulate principles and strategies for service deployment. 331 For the collection of those information, seconds level or minutes 332 level frequency is enough, while serious real-time processing isn't 333 necessary. For example, periodically collecting the total 334 consumption of computing resources, or the total number of sessions 335 accessed, to notify where to depoly more VMS or containers. Unlike 336 the scheduling of request, service deployment should still follow the 337 principle of proximity. The more local access, the more resources 338 should be deployed. If the resources are insufficient, the operator 339 can be informed to increase the hardware resources. Alto can be used 340 to collect and reprot thoes information. 342 5. Scheduling of CAN with ALTO 344 Compared to the deployment, scheduling needs to consider more dynamic 345 information to select and adjust the optimal (rather than the 346 shortest) path in real time, such as: 348 * Mobility: CAN schedules service request to the optimal service node 349 among several service nodes near to users. So when user mobiles, the 350 nearby service nodes changes and new scheduling are needed to chooses 351 new path and new service node. 353 * Real time delay of network: network delay is always in the process 354 of dynamic change, and more and more services propose strict time 355 requirements, which is one of the most important factors affecting 356 user experience. 358 * Real time status of computing resources: computing resources change 359 frequently and the status of computing resources heavily affect the 360 completion time of service, which is also one of the most important 361 factors affecting user experience. 363 * Comprehensive status of network status and computing status: the 364 update frequency of computing status and network status is different, 365 it is necessary to generate a comprehensive value to reflect the 366 status of them. Collecting the information from multi-protocols will 367 bring the issue of synchronization, which is not easy and cause some 368 additional expenses. (If the network is deterministic network that 369 support synchronization such as detnet, it will be better.) One 370 protocol may be the right way. 372 * Various service requirements: different services propose different 373 service requirements on computing and network, including bandwidth, 374 latency, computing resources etc, and the latency includes both 375 transmission latency in network and processing latency in service 376 node, for transmission-intensive services, the transmission latency 377 accounts a lot , so the network latency of services are more 378 important. 380 * Availability of network or computing resources: such as temporary 381 unavailability caused by network equipment or service node failure. 383 Alto can still help collect network and service node information, 385 * Providing the best choice of network and service nodes. Based on 386 the collected network information, computing information, and service 387 requirements on network and computing, Of course, there are still 388 some real-time and complexity problems. 390 * Providing data analysis and policy distribution, real-time node 391 selection still depends on distributed routing, such as dyncast. 393 [I-D.contreras-alto-service-edge]introduces how to use BGP to realize 394 it. BGP is an option where [RFC7971]shows BGP prefixes, AS numbers, 395 AS distances, or other BGP metrics could be collected. However, The 396 ALTO service may not know the instantaneous congestion status of the 397 network, all link bandwidths, all information about the actual 398 routing and whether the candidate endpoint itself is overloaded. So 399 it may not be satisfied for the application with very real time 400 requirements. "real-time" could be relative and may affect the result 401 of scheduling. If it is good, the scheduling can be more accurate 402 and better meet the application requirements; If the real-time 403 performance is not good, the network or node state may change when 404 the flows arrive, resulting in the demand can not be met. So how to 405 improve the performance of BGP or announce the corresponding 406 information through other ways need to be research. 408 6. Summary 410 The converge of network and computing, as well as the interaction 411 with applications has become one of the current technical development 412 directions. This draft analyzes the development status of the 413 current computing aware network and the functional modules in its 414 architecture that can interact with Alto. As a protocol to connect 415 networks and applications, Alto may play a more important role. 417 7. Security Considerations 419 TBD. 421 8. IANA Considerations 423 TBD. 425 9. Acknowledgements 427 Thanks to Yizhou Li, Qin Wu, Tianji Jiang for helpful suggestion. 428 Thanks go to Dirk Trossen, Luigi Iannone, and Carsten Bormann for 429 their inspiring Dyncast work. 431 10. Informative References 433 [I-D.contreras-alto-service-edge] 434 Contreras, L. M., Lachos, D. A., Rothenberg, C. E., and S. 435 Randriamasy, "Use of ALTO for Determining Service Edge", 436 Work in Progress, Internet-Draft, draft-contreras-alto- 437 service-edge-03, 12 July 2021, 438 . 441 [I-D.li-dyncast-architecture] 442 Li, Y., Iannone, L., Trossen, D., and P. Liu, "Dynamic- 443 Anycast Architecture", Work in Progress, Internet-Draft, 444 draft-li-dyncast-architecture-00, 15 February 2021, 445 . 448 [I-D.liu-dyncast-ps-usecases] 449 Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 450 (Dyncast) Use Cases & Problem Statement", Work in 451 Progress, Internet-Draft, draft-liu-dyncast-ps-usecases- 452 01, 15 February 2021, . 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, 457 DOI 10.17487/RFC2119, March 1997, 458 . 460 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 461 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 462 Deployment Considerations", RFC 7971, 463 DOI 10.17487/RFC7971, October 2016, 464 . 466 Authors' Addresses 468 Peng Liu 469 China Mobile 470 Beijing 471 100053 472 China 474 Email: liupengyjy@chinamobile.com 476 Yuexia Fu 477 China Mobile 478 Beijing 479 100053 480 China 482 Email: fuyuexia@chinamobile.com