idnits 2.17.1 draft-sarathchandra-coin-appcentres-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 : ---------------------------------------------------------------------------- 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 date (October 30, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COIN C. Sarathchandra 3 INTERNET-DRAFT D. Trossen 4 Intended Status: Informational InterDigital Europe, Ltd. 5 Expires: May 2, 2020 M. Boniface 6 University of Southampton 7 October 30, 2019 9 In-Network Computing for App-Centric Micro-Services 10 draft-sarathchandra-coin-appcentres-01 12 Abstract 14 The application-centric deployment of 'Internet' services has 15 increased over the past ten years with many million applications 16 providing user-centric services, executed on increasingly more 17 powerful smartphones that are supported by Internet-based cloud 18 services in distributed data centres, the latter mainly provided by 19 large scale players such as Google, Amazon and alike. This draft 20 outlines a vision of evolving those data centres towards executing 21 app-centric micro-services; we dub this evolved data centre as an 22 AppCentre. Complemented with the proliferation of such AppCentres at 23 the edge of the network, they will allow for such micro-services to 24 be distributed across many places of execution, including mobile 25 terminals themselves, while specific micro-service chains equal 26 today's applications in existing smartphones. We outline the key 27 enabling technologies that needs to be provided for such evolution to 28 be realized, including references to ongoing IETF work in some 29 areas. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as 39 Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 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 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.1 Mobile Application Function Offloading . . . . . . . . . . . 4 73 3.2 Collaborative Gaming . . . . . . . . . . . . . . . . . . . 6 74 4 Enabling Technologies . . . . . . . . . . . . . . . . . . . . . 6 75 4.1 Application Packaging . . . . . . . . . . . . . . . . . . . 6 76 4.2 Service Deployment . . . . . . . . . . . . . . . . . . . . 7 77 4.3 Service Routing . . . . . . . . . . . . . . . . . . . . . . 8 78 4.4 Service Pinning . . . . . . . . . . . . . . . . . . . . . . 9 79 4.5 State Synchronisation . . . . . . . . . . . . . . . . . . . 9 80 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 81 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 82 7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 85 8.2 Informative References . . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1 Introduction 90 With the increasing dominance of smartphones and application markets, 91 the end-user experiences today have been increasingly centered around 92 the applications and the ecosystems that smartphone platforms create. 93 The experience of the 'Internet' has changed from 'accessing a web 94 site through a web browser' to 'installing and running an application 95 on a smartphone'. This app-centric model has changed the way services 96 are being delivered not only for end-users, but also for business-to- 97 consumer (B2C) and business-to-business (B2B) relationships. 99 Designing and engineering applications is largely done statically at 100 design time, such that achieving significant performance improvements 101 thereafter has become a challenge (especially, at runtime in response 102 to changing demands and resources). Applications today come 103 prepackaged putting them at disadvantage for improving efficiency due 104 to the monolithic nature of the application packaging. Decomposing 105 application functions into micro-services [MSERVICE1] [MSERVICE2] 106 allows applications to be packaged dynamically at run-time taking 107 varying application requirements and constraints into consideration. 108 Interpreting an application as a chain of micro-services, allows the 109 application structure, functionality, and performance to be adapted 110 dynamically at runtime in consideration of tradeoffs between quality 111 of experience, quality of service and cost. 113 Interpreting any resource rich networked computing (and storage) 114 capability not just as a pico or micro-data centre, but as an 115 application-centric execution data centre (AppCentre), allows 116 distributed execution of micro-services. These micro-services may 117 then be deployed on the most appropriate AppCentre (edge/fog/cloud 118 resources) to satisfy requirements under varying constraints. In 119 addition, the high degree of distribution of application and data 120 partitions, and compute resources offered by the execution 121 environment decentralizes control between multiple cooperating 122 parties (multi-technology, multi-domain, multi-ownership 123 environments). 125 The emergence of AppCentreS will democratise infrastructure and 126 service provision to anyone with compute resources, while app-centric 127 computing provides a truly pervasive user experience. Moreover, this 128 will lead to new forms of application interactions and experiences 129 based on cooperative AppCentreS (pico-micro and large cloud data 130 centres), in which applications are being designed, (micro-services) 131 dynamically composed and executed. 133 2 Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 3. Use Cases 140 3.1 Mobile Application Function Offloading 142 The App-centric model increases the ubiquity of computing elements 143 available for execution of application functions. Most functions can 144 be categorised into any of three, "receiving", "processing" and 145 "displaying" function groups. Partitioning an application into micro- 146 services allows for denoting the application as a sequence of 147 receiving->processing->displaying, for a flexible composition and 148 distributed execution. Any device may realize one or more of the 149 micro-services of an application and expose them to the execution 150 environment. When the micro-service sequence is executed on a single 151 device, the outcome is what you see today as applications running on 152 mobile devices. However, if any of the three functions are terminated 153 on the device (e.g., for optimising the experience), the execution of 154 the rest of the functions may be moved to other suitable devices 155 which have exposed the corresponding micro-services to the 156 environment. The result of the latter is flexible mobile function 157 offloading, for possible reduction of power consumption (e.g., 158 offloading CPU intensive process functions to a remote server) or for 159 improved device capabilities (e.g., moving display functions to a 160 nearby smart TV). 162 The above scenario can be exemplified in an immersive gaming 163 application, where a single user plays a game using a VR headset. The 164 headset hosts functions that "display" frames to the user, as well as 165 the functions for VR content processing and frame rendering combining 166 with input data received from sensors in the VR headset. Once this 167 application is partitioned into micro-services and deployed in an 168 app-centric execution environment, only the "display" micro-service 169 is left in the headset, while the compute intensive real-time VR 170 content processing micro-services can be offloaded to a nearby 171 resource rich home PC, for a better execution (faster and possibly 172 higher resolution generation). 174 Figure 1 shows one realisation of the above scenario, where a 'DPR 175 app' running on a mobile device (containing the partitioned 176 Display(D), Process(P) and Receive(R) micro services) over an SDN 177 network. The packaged applications are made available through a 178 localised 'playstore server'. The application installation is 179 realized as a 'service deployment' process (Section 4.2.), combining 180 the local app installation with a distributed micro-service 181 deployment (and orchestration) on most suitable AppCentreS 182 ('processing server'). 184 +----------+ 185 Mobile |Processing| 186 +---------+ | Server | 187 | App | +----------+ 188 | +-----+ | | 189 | |D|P|R| | +--+ 190 | +-----+ | |SR| Internet 191 | +-----+ | +--+ / 192 | | SR | | | / 193 | +-----+ | +----------+ +------+ 194 +---------+ /|SDN Switch|_____|Border| 195 \ +-------+ / +----------+ | SR | 196 \| 5GAN |/ | +------+ 197 +-------+ | 198 | 199 +----------+ 200 +---------+ /|SDN Switch| 201 | +-----+ | +-------+ / +----------+ 202 | | SR | | /|WIFI AP|/ \ 203 | +-----+ | / +-------+ +--+ 204 |+-------+|/ |SR| 205 ||Display|| /+--+ 206 || || +---------+ 207 |+-------+| |Playstore| 208 +---------+ | Server | 209 TV +---------+ 211 Figure 1: Application Function Offloading Example 213 Such localized deployment could, for instance, be provided by a 214 visiting site, such as a hotel or a theme park. Once the 'processing' 215 micro-service is terminated on the mobile device, the 'service 216 routing' (SR) elements in the network (Section 4.3.) route requests 217 to the previously deployed 'processing' micro-service running on the 218 'processing server' AppCentre over an existing SDN network. 220 Any app-centric execution environment MUST provide means for 221 dynamically choosing the best possible micro-service sequence (i.e., 222 chaining of micro-services) for a given application experience. Any 223 solution SHOULD also provide methods for choosing and/or deploying 224 the best possible instances of micro-services in the app-centric 225 execution environment, for service routing, and for pinning the 226 resources to the corresponding micro-services. 228 3.2 Collaborative Gaming 230 There has been a recent shift from applications that provide single- 231 user experiences, such as the ones described in the previous section 232 to collaborative/cooperative experiences such as multi-user gaming 233 and mixed/virtual reality. The latter leads to increasing amounts of 234 interaction where input (e.g., gesture, gaze, touch, movement) and 235 output (e.g., visual display, sound, and actuation) needs to be 236 processed within strict timing constraints and synchronized to ensure 237 temporal and spatial consistency with local and distant users. App- 238 centric design allows functions with high data and process coupling 239 to be modularised, deployed and executed, such that the subset of 240 micro-services is cooperatively executed towards optimising multi- 241 user experiences. 243 The same example in previous section can be envisaged from a multi- 244 player gaming scenario. Here the micro-services that need to be 245 executed cooperatively are executed in a localised and synchronised 246 manner for player coordination and synchronizing interaction and 247 state between collaborating players. 249 Any app-centric execution environment MUST provide means for real- 250 time synchronization and consistency of distributed application 251 states. 253 4 Enabling Technologies 255 4.1 Application Packaging 257 Applications often consist of one or more sub-elements (e.g., audio, 258 visual, hepatic elements) which are 'packaged' together, resulting in 259 the final installable software artifact. Conventionally, application 260 developers perform the packaging process at design time, by packaging 261 a set of software components as a (often single) monolithic software 262 package, for satisfying a set of predefined application 263 requirements. 265 Decomposing micro-services of an application, and then executing them 266 on peer execution points in AppCentreS (e.g., on an app-centric 267 serverless runtime [SRVLESS]) can be done with design-time planning. 268 Micro-service decomposition process involves, defining clear 269 boundaries of the micro-service (e.g., using wrapper classes for 270 handling input/output requests), which could be done by the 271 application developer at design-time (e.g., through Android app 272 packaging by including, as part of the asset directory, a service 273 orchestration template [TOSCA] that describes the decomposed micro- 274 services). Likewise, the peer execution points could be 'known' to 275 the application (e.g., using well-known and fixed peer execution 276 points on AppCentreS) and incorporated with the micro-services by the 277 developer at design-time. 279 Existing programming frameworks address decomposition and execution 280 of applications centering around other aspects such as concurrency 281 [ERLANG]. For decomposing at runtime, application elements can be 282 profiled using various techniques such as dynamic program analysis or 283 dwarf application benchmarks. The local profiler information can be 284 combined with the profiler information of other devices in the 285 network for improved accuracy. The output of such a profiler process 286 can then be used to identify smaller constituting sub-components of 287 the application in forms of pico-services, their interdependencies 288 and data flow (e.g., using caller/callee information, instruction 289 usage). Due to the complex nature of resulting application structure 290 and therefore its increased overhead, in most cases, it may not be 291 optimal to decompose applications at the pico level. Therefore, one 292 may cluster pico-services into micro-services with common 293 characteristics, enabling a meaningful (e.g., clustering pico- 294 services with same resource dependency) and a performant 295 decomposition of applications. Characteristics of micro-services can 296 be defined as a set of concepts using an ontology language, which can 297 then be used for clustering similar pico-services into micro- 298 services. Micro-services may then be partitioned along their 299 identified borders. Moreover, mechanisms for governance, discovery 300 and offloading can be employed for 'unknown' peer execution points on 301 AppCentreS with distributed loci of control. 303 Therefore, with this app-centric model, application packaging can be 304 done at runtime by constructing micro-service chains for satisfying 305 requirements of experiences (e.g., interaction requirements), under 306 varying constraints (e.g., temporal consistency between multiple 307 players within a shared AR/VR world)[SCOMPOSE]. Such packaging 308 includes mechanisms for selecting the best possible micro-services 309 for a given experience at runtime in the multi-X environment. These 310 run-time packaging operations may continuously discover the 'unknown' 311 and adapt towards an optimal experience. Such decision mechanisms 312 handle the variability, volatility and scarcity within this multi-X 313 framework. 315 4.2 Service Deployment 317 The service function chains, constituting each individual 318 application, will need deployment mechanisms in a true multi-X 319 (multi-user, multi-infrastructure, multi-domain) environment 320 [SDEPLOY1][SDEPLOY2]. Most importantly, application installation and 321 orchestration processes are married into one, as a set of procedures 322 governed by device owners directly or with delegated authority. 323 However, apart from extending towards multi-X environments, the 324 process also needs to cater for changes in the environment, caused, 325 e.g., by movement of users, new pervasive sensors/actuators, and 326 changes to available infrastructure resources. Methods to deploy 327 service functions as executable code into chosen service execution 328 points, supporting the various endpoint realizations (e.g., device 329 stacks, COTS stacks, etc.), and service function endpoint realization 330 through utilizing existing and emerging virtualisation techniques. 332 A combination of application installation procedure and orchestrated 333 service deployment can be achieved by utilizing the application 334 packaging with integrated service deployment templates described in 335 Section 4.1 such that the application installation procedure on the 336 installing device is being extended to not only install the local 337 application package but also extract the service deployment template 338 for orchestrating with the localized infrastructure, using, for 339 instance, REST APIs for submitting the template to the orchestrator. 341 4.3 Service Routing 343 Service routing within a combined compute and network infrastructure 344 that will enable true end-to-end experiences across distributed 345 application execution points provisioned on distant cloud, edge and 346 device-centric resources (e.g., using ICN/name-based routing 347 methods), is a key aspect of app-centric micro-service execution. 348 Once the micro-services are packaged and deployed in such highly 349 distributed micro-data centres, the routing mechanisms will ensure 350 efficient information exchange (e.g., for satisfying application 351 requirements) between corresponding micro-services within the multi-X 352 execution environment. 354 Routing becomes a problem of routing the micro-service requests, not 355 just packets, as done through IP. Traditionally, the combination of 356 the Domain Naming Service (DNS) and IP routing has been used for this 357 purpose. However, the advent of virtualisation with use cases such as 358 those outlined above have made it challenging to further rely on the 359 DNS. This is mainly down to the long delay in updating DNS entries to 360 'point' to the right micro-service instances. If one was to use the 361 DNS, would be updating the DNS entries at a high rate, caused by the 362 diversity of trigger, e.g., through movement. DNS has not been 363 designed for such frequent update, rendering it useless for such 364 highly dynamic applications. With many edge scenarios in the VR/AR 365 space demanding interactivity and being latency-sensitive, efficient 366 routing will be key to any solution. 368 Various ongoing work on service request forwarding [nSFF] with the 369 service function chaining [RFC7665] framework as well as name-based 370 routing [ICN5G][ICN4G] address some aspects described above. However, 371 further extensions to those need to be considered supporting an app- 372 centric model. 374 4.4 Service Pinning 376 Allocating the right resources to the right micro-services is a 377 fundamental task when executing micro-services on such highly 378 distributed app-centric micro-data centres (e.g., resource management 379 in cloud [CLOUDFED]), particularly in the light of volatile resource 380 availability as well as concurrent and highly dynamic resource 381 access. Once the specific set of micro-services of an application has 382 been identified, during the lifetime of the application, requirements 383 (e.g., QoS) must be ensured by the execution environment. Therefore, 384 all micro-data centres and the execution environment will realize 385 mechanisms for ensuring the utilization of specific resources within 386 a pool of resources (i.e., resources in all app-centric micro-data 387 centres), for a specific set of micro-services belonging to one 388 application, while also ensuring integrity in the wider system. 390 4.5 State Synchronisation 392 Given the highly distributed nature of app-centric micro-services, 393 their state exchange and synchronisation is a very crucial aspect for 394 ensuring in-application and system wide consistency. Mechanisms that 395 ensure consistency will ensure that data is synchronised with 396 different spatial, temporal and relational data within a given time 397 period. 399 5 Security Considerations 401 N/A 403 6 IANA Considerations 405 N/A 407 7 Conclusion 409 This draft positions the evolution of data centres as one of becoming 410 execution centres for the app-centric experiences provided today by 411 smartphones. With the proliferation of data centres closer to the end 412 user in the form of edge-based micro data centres, we believe that 413 app-centric experiences will ultimately be executed across those 414 many, highly distributed execution points that this increasingly rich 415 edge environment will provide. Although a number of activities are 416 currently underway to address some of the challenges for realizing 417 such AppCentre evolution, we believe that the COIN research group 418 will provide a suitable forum to drive forward the remaining research 419 and its dissemination into working systems and the necessary 420 standardization of key aspects and protocols. Future work on this 421 draft will focus on contributing its main points to an evolving 422 research roadmap that we would see as a possible outcome of the COIN 423 RG. 425 8 References 427 8.1 Normative References 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, DOI 431 10.17487/RFC2119, March 1997, . 434 [RFC7665] Halpern, J., Ed., and C. Pignataro, Ed., "Service Function 435 Chaining (SFC) Architecture", RFC 7665, DOI 436 10.17487/RFC7665, October 2015, . 439 8.2 Informative References 441 [MSERVICE1] Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, 442 M., Montesi, F., Mustafin, R., & Safina, L. (2017). 443 Microservices: yesterday,today, and tomorrow. In Present 444 and Ulterior Software Engineering (pp. 195-216). Springer, 445 Cham. 447 [MSERVICE2] Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2016). 448 Microservices architecture enables devops: Migration to a 449 cloud-native architecture. IEEE Software, 33(3), 42-52. 451 [SRVLESS] C. Cicconetti, M. Conti and A. Passarella, "An 452 Architectural Framework for Serverless Edge Computing: 453 Design and Emulation Tools," 2018 IEEE International 454 Conference on Cloud Computing Technology and Science 455 (CloudCom), Nicosia, 2018, pp. 48-55. doi: 456 10.1109/CloudCom2018.2018.00024 458 [TOSCA] Topology and Orchestration Specification for Cloud 459 Applications Version 1.0. 25 November 2013. OASIS 460 Standard. . 463 [ERLANG] Armstrong, Joe, et al. "Concurrent programming in ERLANG." 464 (1993). 466 [SCOMPOSE] M. Hirzel, R. Soule, S. Schneider, B. Gedik, and R. Grimm, 467 "A Catalog of Stream Processing Optimizations", ACM 468 Computing Surveys,46(4):1-34, Mar. 2014 470 [SDEPLOY1] Lu, H., Shtern, M., Simmons, B., Smit, M., & Litoiu, M. 471 (2013, June). Pattern-based deployment service for next 472 generation clouds. In 2013 IEEE Ninth World Congress on 473 Services (pp. 464-471). IEEE. 475 [SDEPLOY2] Eilam, T., Elder, M., Konstantinou, A. V., & Snible, E. 476 (2011, May). Pattern-based composite application 477 deployment. In 12th IFIP/IEEE International Symposium on 478 Integrated Network Management (IM 2011) and Workshops (pp. 479 217-224). IEEE. 481 [nSFF] Trossen, D., Purkayastha, D., Rahman, A., "Name-Based 482 Service Function Forwarder (nSFF) component within SFC 483 framework", (work in progress), April 485 2019. 487 [ICN5G] Ravindran, R., Suthar, P., Trossen, D., Wang, C., White, 488 G., "Enabling ICN in 3GPP's 5G NextGen Core Architecture", 489 490 (work in progress), March 2019. 492 [ICN4G] Suthar, P., Jangam, Ed., Trossen, D., Ravindran, R., 493 "Native Deployment of ICN in LTE, 4G Mobile Networks", 494 (work in progress), March 2019. 497 [CLOUDFED] M. Liaqat, V. Chang, A. Gani, S. Hafizah Ab Hamid, M. 498 Toseef, U. Shoaib, R. Liaqat Ali, "Federated cloud 499 resource management: Review and discussion", Elsevier 500 Journal of Network and Computer Applications, 2017. 502 Authors' Addresses 504 Chathura Sarathchandra 505 InterDigital Europe, Ltd. 506 64 Great Eastern Street, 1st Floor 507 London EC2A 3QR 508 United Kingdom 510 Email: Chathura.Sarathchandra@InterDigital.com 511 Dirk Trossen 512 InterDigital Europe, Ltd. 513 64 Great Eastern Street, 1st Floor 514 London EC2A 3QR 515 United Kingdom 517 Email: Dirk.Trossen@InterDigital.com 519 Michael Boniface 520 University of Southampton 521 University Road 522 Southampton SO17 1BJ 523 United Kingdom 525 Email: mjb@it-innovation.soton.ac.uk