COIN D. Trossen INTERNET-DRAFT Huawei Intended Status: Informational C. Sarathchandra Expires: April 25, 2021 InterDigital Inc. M. Boniface University of Southampton October 23, 2020 In-Network Computing for App-Centric Micro-Services draft-sarathchandra-coin-appcentres-03 Abstract The application-centric deployment of 'Internet' services has increased over the past ten years with many millions of applications providing user-centric services, executed on increasingly more powerful smartphones that are supported by Internet-based cloud services in distributed data centres, the latter mainly provided by large scale players such as Google, Amazon and alike. This draft outlines a vision for evolving those data centres towards executing app-centric micro-services; we dub this evolved data centre as an AppCentre. Complemented with the proliferation of such AppCentres at the edge of the network, they will allow for such micro-services to be distributed across many places of execution, including mobile terminals themselves, while specific micro-service chains equal today's applications in existing smartphones. We outline the key enabling technologies that needs to be provided for such evolution to be realized, including references to ongoing IETF work in some areas. 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." Trossen, et al. Expires April 25, 2021 [Page 1] INTERNET DRAFT App-Centric Micro-Services 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Mobile Application Function Offloading . . . . . . . . . . 5 3.2 Interactive Real-time Applications . . . . . . . . . . . . 7 3.3 Distributed AI . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Content Delivery Networks . . . . . . . . . . . . . . . . . 8 3.5 Compute-Fabric-as-a-Service (CFaaS) . . . . . . . . . . . . 8 4 Requirements Derived from Use Cases . . . . . . . . . . . . . . 9 5 Enabling Technologies . . . . . . . . . . . . . . . . . . . . . 10 5.1 Application Packaging . . . . . . . . . . . . . . . . . . . 10 5.2 Service Deployment . . . . . . . . . . . . . . . . . . . . 11 5.3 Compute Inter-Connection at Layer 2 . . . . . . . . . . . . 12 5.4 Service Routing . . . . . . . . . . . . . . . . . . . . . . 13 5.5 Constraint-based Forwarding Decisions . . . . . . . . . . . 14 5.6 Collective Communication . . . . . . . . . . . . . . . . . 14 5.7 State Synchronization . . . . . . . . . . . . . . . . . . . 15 5.8 Dynamic Contracts . . . . . . . . . . . . . . . . . . . . . 15 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 15 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 Trossen, et al. Expires April 25, 2021 [Page 2] INTERNET DRAFT App-Centric Micro-Services 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Trossen, et al. Expires April 25, 2021 [Page 3] INTERNET DRAFT App-Centric Micro-Services 1 Introduction With the increasing dominance of smartphones and application markets, the end-user experiences today have been increasingly centered around the applications and the ecosystems that smartphone platforms create. The experience of the 'Internet' has changed from 'accessing a web site through a web browser' to 'installing and running an application on a smartphone'. This app-centric model has changed the way services are being delivered not only for end-users, but also for business-to- consumer (B2C) and business-to-business (B2B) relationships. Designing and engineering applications is largely done statically at design time, such that achieving significant performance improvements thereafter has become a challenge (especially, at runtime in response to changing demands and resources). Applications today come prepackaged putting them at disadvantage for improving efficiency due to the monolithic nature of the application packaging. Decomposing application functions into micro-services [MSERVICE1] [MSERVICE2] allows applications to be packaged dynamically at run-time taking varying application requirements and constraints into consideration. Interpreting an application as a chain of micro-services, allows the application structure, functionality, and performance to be adapted dynamically at runtime in consideration of tradeoffs between quality of experience, quality of service and cost. Interpreting any resource rich networked computing (and storage) capability not just as a pico or micro-data centre, but as an application-centric execution data centre (AppCentre), allows distributed execution of micro-services. Here, the notion of an 'application' constitutes a set of objectives being realized in a combined packaging of micro-services under the governance of the 'application provider'. These micro-services may then be deployed on the most appropriate AppCentre (edge/fog/cloud resources) to satisfy requirements under varying constraints. In addition, the high degree of distribution of application and data partitions, and compute resources offered by the execution environment decentralizes control between multiple cooperating parties (multi-technology, multi-domain, multi-ownership environments). Furthermore, compute resource availability may be volatile, particularly when moving along the spectrum from well-connected cloud resources over edge data centres to user-provided compute resources, such as (mobile) terminals or home-based resources such as NAS and IoT devices. We believe that the emergence of AppCentreS will democratize infrastructure and service provision to anyone with compute resources with the notion of applications providing an element of governing the execution of micro-services. This increased distribution will lead to new forms of application interactions and user experiences based on Trossen, et al. Expires April 25, 2021 [Page 4] INTERNET DRAFT App-Centric Micro-Services cooperative AppCentreS (pico-micro and large cloud data centres), in which applications are being designed, dynamically composed and executed. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3 Use Cases Although our motivation for the 'AppCentre' term stems from the (mobile) application ecosystem, the use cases in this section are not limited to mobile applications only. Instead, we interpret 'applications' as a governing concept of executing a set of micro- services where the 'application provider' can reach from those realizing mobile applications over novel network applications to emerging infrastructure offerings serving a wide range of applications in a purpose- (and therefore application-)agnostic manner. The following use cases provide examples for said spectrum of applications. 3.1 Mobile Application Function Offloading Partitioning an application into micro-services allows for denoting the application as a collection of functions for a flexible composition and a distributed execution, e.g., most functions of a mobile application can be categorized into any of three, "receiving", "processing" and "displaying" function groups. Any device may realize one or more of the micro-services of an application and expose them to the execution environment. When the micro-service sequence is executed on a single device, the outcome is what you see today as applications running on mobile devices. However, the execution of functions may be moved to other (e.g., more suitable) devices which have exposed the corresponding micro-services to the environment. The result of the latter is flexible mobile function offloading, for possible reduction of power consumption (e.g., offloading CPU intensive process functions to a remote server) or for improved end user experience (e.g., moving display functions to a nearby smart TV). The above scenario can be exemplified in an immersive gaming application, where a single user plays a game using a VR headset. The headset hosts functions that "display" frames to the user, as well as the functions for VR content processing and frame rendering combining with input data received from sensors in the VR headset. Once this Trossen, et al. Expires April 25, 2021 [Page 5] INTERNET DRAFT App-Centric Micro-Services application is partitioned into micro-services and deployed in an app-centric execution environment, only the "display" micro-service is left in the headset, while the compute intensive real-time VR content processing micro-services can be offloaded to a nearby resource rich home PC, for a better execution (faster and possibly higher resolution generation). Figure 1 shows one realization of the above scenario, where a 'DPR app' is running on a mobile device (containing the partitioned Display(D), Process(P) and Receive(R) micro services) over an SDN network. The packaged applications are made available through a localized 'playstore server'. The application installation is realized as a 'service deployment' process (Section 5.2.), combining the local app installation with a distributed micro-service deployment (and orchestration) on most suitable AppCentreS ('processing server'). +----------+ Processing Server Mobile | +------+ | +---------+ | | P | | | App | | +------+ | | +-----+ | | +------+ | | |D|P|R| | | | SR | | | +-----+ | | +------+ | Internet | +-----+ | +----------+ / | | SR | | | / | +-----+ | +----------+ +------+ +---------+ /|SDN Switch|_____|Border| \ +-------+ / +----------+ | SR | \| 5GAN |/ | +------+ +-------+ | +---------+ | |+-------+| +----------+ ||Display|| /|SDN Switch| |+-------+| +-------+ / +----------+ |+-------+| /|WIFI AP|/ \ || D || / +-------+ +--+ |+-------+|/ |SR| |+-------+| /+--+ || SR || +---------+ |+-------+| |Playstore| +---------+ | Server | TV +---------+ Figure 1: Application Function Offloading Example Such localized deployment could, for instance, be provided by a visiting site, such as a hotel or a theme park. Once the 'processing' Trossen, et al. Expires April 25, 2021 [Page 6] INTERNET DRAFT App-Centric Micro-Services micro-service is terminated on the mobile device, the 'service routing' (SR) elements in the network (Section 5.4.) routes requests to the previously deployed 'processing' micro-service running on the 'processing server' AppCentre over an existing SDN network. As an extension to the above scenarios, we can also envision that content from one processing micro-service may be distributed to more than one display micro-service, e.g., for multi/many-viewing scenarios. 3.2 Interactive Real-time Applications There has been a recent shift from applications that provide single- user experiences, such as the ones described in the previous section to collaborative/cooperative experiences that are highly interactive with strict real-time requirements, such as collaborative working, education, multi-user gaming, and mixed/virtual reality. This leads to increasing interaction where input (e.g., gesture, gaze, touch, movement) and output (e.g., visual display, sound, and actuation) needs to be processed within strict timing constraints and synchronized to ensure temporal and spatial consistency with local and distant users. App-centric design allows functions with high data and process coupling to be modularized, deployed and executed, such that the subset of micro-services is cooperatively executed towards optimizing the interactive experiences. The same example of the previous section can be envisaged in a multi- player gaming scenario. Here the micro-services that need to be executed cooperatively are executed in a localized and synchronized manner to ensure player coordination and synchronized state between collaborating players. 3.3 Distributed AI There is a growing range of use cases demanding for the realization of AI capabilities among distributed endpoints. Such demand may be driven by the need to increase overall computational power for large- scale problems. Other solutions may desire the localization of reasoning logic, e.g., for deriving attributes that better preserve privacy of the utilized raw input data. Examples for large-scale AI problems include biotechnology and astronomy related reasoning over massive amounts of observational input data. Examples for localizing input data for privacy reasons include radar-like application for the development of topological mapping data based on (distributed) radio measurements at base stations (and possibly end devices), while the processing within radio access networks (RAN) already constitute a distributed AI problem to a certain extent albeit with little flexibility in distributing the execution of the AI logic. Reasoning frameworks, such as TensorFlow, may be utilized for the Trossen, et al. Expires April 25, 2021 [Page 7] INTERNET DRAFT App-Centric Micro-Services realization of the (distributed) AI logic, building on remote service invocation through protocols such as gRPC [GRPC] or MPI [MPI] with the intention of providing an on-chip NPU (neural processor unit) like abstraction to the AI framework. 3.4 Content Delivery Networks Delivery of content to end users often relies on Content Delivery Networks (CDNs) storing said content closer to end users for latency reduced delivery with DNS-based indirection being utilized to serve the request on behalf of the origin server. From the perspective of this draft, a CDN can be interpreted as a (network service level) application with distributed logic for distributing content from the origin server to the CDN ingress and further to the CDN replication points which ultimately serve the user-facing content requests. Studies such as those in [FCDN] have shown that content distribution at the level of named content, utilizing efficient (e.g., Layer 2) multicast for replication towards edge CDN nodes, can significantly increase the overall network and server efficiency. It also reduces indirection latency for content retrieval as well as reduces required edge storage capacity by benefiting from the increased network efficiency to renew edge content more quickly against changing demand. 3.5 Compute-Fabric-as-a-Service (CFaaS) App-centric execution environments, consisting of Layer 2 connected AppcentreS, provide the opportunity for infrastructure providers to offer CFaaS type of offerings to application providers. Those app providers utilize the compute fabric exposed by this CFaaS offering for the purposes defined through their applications. In other words, the compute resources can be utilized to execute the desired micro- services of which the application is composed, while utilizing the inter-connection between those compute resources to do so in a distributed manner. We foresee those CFaaS offerings to be tenant-specific, a tenant here defined as the provider of at least one application. For this, we foresee an interaction between CFaaS provider and tenant to dynamically select the appropriate resources to define the demand side of the fabric. Conversely, we also foresee the supply side of the fabric to be highly dynamic with resources being offered to the fabric through, e.g., user-provided resources (whose supply might depend on highly context-specific supply policies) or infrastructure resources of intermittent availability such as those provided through road-side infrastructure in vehicular scenarios. The resulting dynamic demand-supply matching establishes a dynamic nature of the Trossen, et al. Expires April 25, 2021 [Page 8] INTERNET DRAFT App-Centric Micro-Services compute fabric that in turn requires trust relationships to be built dynamically between the resource provider(s) and the CFaaS provider. This also requires the communication resources to be dynamically adjusted to interconnect all resources suitably into the (tenant- specific) fabric exposed as CFaaS. 4 Requirements Derived from Use Cases The following requirements are derived from the presented use cases in Section 3.1. to 3.5., numbered according to the use case numbers (as main item numbers) although those requirements apply in some cases across more than one of the presented use cases. Req 1.1: Any app-centric execution environment MUST provide means for routing of service requests between resources in the distributed environment. Req 1.2: Any app-centric execution environment MUST provide means for dynamically choosing the best possible micro-service sequence (i.e., chaining of micro-services) for a given application experience. Means for discovering suitable micro-service SHOULD be provided. Req 1.3: Any app-centric execution environment MUST provide means for pinning the excution of a specific micro-service to a specific resource instance in the distributed environment. Req 1.4: Any app-centric execution environment SHOULD provide means for packaging micro-services for deployments in distributed networked computing environments. The packaging MAY include any constraints regarding the deployment of service instances in specific network locations or compute resources. Such packaging SHOULD conform to existing application deployment models, such as mobile application packaging, TOSCA orchestration templates or tar balls or combinations thereof. Req 2.1: Any app-centric execution environment MUST provide means for real-time synchronization and consistency of distributed application states. Req 3.1: Any app-centric execution environment MUST provide means to specify the constraints for placing (AI) execution logic in certain logical execution points (and their associated physical locations). Req 3.2: Any app-centric execution environment MUST provide support for app/micro-service specific invocation protocols. Trossen, et al. Expires April 25, 2021 [Page 9] INTERNET DRAFT App-Centric Micro-Services Req 4.1: Any app-centric execution environment SHOULD utilize Layer 2 multicast transmission capabilities for responses to concurrent service requests. Req 5.1: Any app-specific execution environment SHOULD expose means to specify the requirements for the tenant-specific compute fabric being utilized for the app execution. Req 5.2: Any app-specific execution environment SHOULD allow for dynamic integration of compute resources into the compute fabric being utilized for the app execution; those resources include, but are not limited to, end user provided resources. Req 5.3: Any app-specific execution environment MUST provide means to optimize the inter-connection of compute resources, including those dynamically added and removed during the provisioning of the tenant-specific compute fabric. Req 5.4: Any app-specific execution environment MUST provide means for ensuring availability and usage of resources is accounted for. 5 Enabling Technologies This section discusses a number of enabling technologies relevant for the realization of the app-centric micro-service vision laid out in this draft. EDITOR NOTE: Section 5 will be updated to include the addressing of specific requirements listed in Section 4. 5.1 Application Packaging Applications often consist of one or more sub-elements (e.g., audio, visual, hepatic elements) which are 'packaged' together, resulting in the final installable software artifact. Conventionally, application developers perform the packaging process at design time, by packaging a set of software components as a (often single) monolithic software package, for satisfying a set of predefined application requirements. Decomposing micro-services of an application, and then executing them on peer execution points in AppCentreS (e.g., on an app-centric serverless runtime [SRVLESS]) can be done with design-time planning. Micro-service decomposition process involves, defining clear boundaries of the micro-service (e.g., using wrapper classes for Trossen, et al. Expires April 25, 2021 [Page 10] INTERNET DRAFT App-Centric Micro-Services handling input/output requests), which could be done by the application developer at design-time (e.g., through Android app packaging by including, as part of the asset directory, a service orchestration template [TOSCA] that describes the decomposed micro- services). Likewise, the peer execution points could be 'known' to the application (e.g., using well-known and fixed peer execution points on AppCentreS) and incorporated with the micro-services by the developer at design-time. Existing programming frameworks address decomposition and execution of applications centering around other aspects such as concurrency [ERLANG]. For decomposing at runtime, application elements can be profiled using various techniques such as dynamic program analysis or dwarf application benchmarks. The local profiler information can be combined with the profiler information of other devices in the network for improved accuracy. The output of such a profiler process can then be used to identify smaller constituting sub-components of the application in forms of pico-services, their interdependencies and data flow (e.g., using caller/callee information, instruction usage). Due to the complex nature of resulting application structure and therefore its increased overhead, in most cases, it may not be optimal to decompose applications at the pico level. Therefore, one may cluster pico-services into micro-services with common characteristics, enabling a meaningful (e.g., clustering pico- services with same resource dependency) and a performant decomposition of applications. Characteristics of micro-services can be defined as a set of concepts using an ontology language, which can then be used for clustering similar pico-services into micro- services. Micro-services may then be partitioned along their identified borders. Moreover, mechanisms for governance, discovery and offloading can be employed for 'unknown' peer execution points on AppCentreS with distributed loci of control. Therefore, with this app-centric model, application packaging can be done at runtime by constructing micro-service chains for satisfying requirements of experiences (e.g., interaction requirements), under varying constraints (e.g., temporal consistency between multiple players within a shared AR/VR world)[SCOMPOSE]. Such packaging includes mechanisms for selecting the best possible micro-services for a given experience at runtime in the multi-technology environment. These run-time packaging operations may continuously discover the 'unknown' and adapt towards an optimal experience. Such decision mechanisms handle the variability, volatility and scarcity within this multi-X framework. 5.2 Service Deployment The service function chains, constituting each individual Trossen, et al. Expires April 25, 2021 [Page 11] INTERNET DRAFT App-Centric Micro-Services application, will need deployment mechanisms in a true multi-X (multi-user, multi-infrastructure, multi-domain) environment [SDEPLOY1][SDEPLOY2]. Most importantly, application installation and orchestration processes are married into one, as a set of procedures governed by device owners directly or with delegated authority. However, apart from extending towards multi-X environments, the process also needs to cater for changes in the environment, caused, e.g., by movement of users, new pervasive sensors/actuators, and changes to available infrastructure resources. Methods are needed to deploy service functions as executable code into chosen service execution points. Those methods need to support the various endpoint (e.g., device stacks, COTS stacks, etc.) and service function realizations, e.g., through utilizing existing and emerging virtualization techniques. A combination of application installation procedure and orchestrated service deployment can be achieved by utilizing the application packaging with integrated service deployment templates described in Section 5.1 such that the application installation procedure on the installing device is being extended to not only install the local application package but also extract the service deployment template for orchestrating with the localized infrastructure, using, for instance, REST APIs for submitting the template to the orchestrator. 5.3 Compute Inter-Connection at Layer 2 While Layer2 switching technologies have long proliferated in data centre deployments, recent developments have advanced the capabilities for interconnecting distributed computing resources over Layer2 technologies. For instance, the efforts in 3GPP on so-called '5G LAN' (or Vertical LAN) [SA2-5GLAN] allow for establishing a Layer2 bearer between participating compute entities, using a vertical-specific LAN identifier for packet forwarding between the distributed Layer2 entities. Combined with Layer2 technology in data centres as well as office and home networks alike, this enables the deployment of services in vertical (Layer2) networks, interconnecting with other Internet-based services through dedicated service gateways. Real deployments and realizations will have to show the scalability of this approach but it points into a direction where application or service-specific deployments could potentially 'live' entirely in their own vertical network, interconnecting only based on need (which for many services may not exist). From the application's or service's perspective, the available compute resource pool will look no different from that being realized in a single data centre albeit with the possibility to being highly distributed now among many (e.g., edge) data centres as well as mobile devices. Trossen, et al. Expires April 25, 2021 [Page 12] INTERNET DRAFT App-Centric Micro-Services In such a deployment, it is interesting to study the realization of suitable service routing capabilities, leading us to the next technology area of interest. 5.4 Service Routing Routing service requests is a key aspect within a combined compute and network infrastructure in order to enable true end-to-end experiences across distributed application execution points provisioned on distant cloud, edge and device-centric resources. Once the micro-services are packaged and deployed in such highly distributed micro-data centres, the routing mechanisms must ensure efficient information exchange between corresponding micro-services, e.g., at the level of service requests, within the multi-technology execution environment. Routing here becomes a problem of routing micro-service requests, not just packets, as done through IP. This calls for some form of 'flow affinity' that allows for treating several packets as part of a request semantic. This is important, e.g., for mobility (avoiding to send some packets of a larger request to one entity, while other packets are sent to another one, therefore creating incomplete information at both entities as a result). Also, when applying constraints to the forwarding of packets (discussed in more detail in Section 5.6), it is important to apply the actions across the packets of the request rather than individually. Another key aspect is that of addressing services. Traditionally, the combination of the Domain Naming Service (DNS) and IP routing has been used for this purpose. However, the advent of virtualization with use cases such as those outlined in Section 3 (such as those on app-specific micro-services on mobile devices) have made it challenging to further rely on the DNS. Apart from the initial delay observed when resolving a service name into a locator for the first time, the long delay in updating DNS entries to 'point' to the right micro-service instances prohibits offloading to dynamically created service instances. If one was to use the DNS, one would be updating the DNS entries at a high rate, caused by the diversity of trigger, e.g., through movement. DNS has not been designed for such frequent update, rendering it useless for such highly dynamic applications. With many edge scenarios in the VR/AR space demanding interactivity and being latency-sensitive, efficient routing will be key to any solution. Various ongoing work on service request forwarding [RFC8677] with the service function chaining [RFC7665] framework as well as name-based routing [ICN5G][ICN4G] addresses some aspects described above albeit with a focus on HTTP as the main invocation protocol. Extensions will Trossen, et al. Expires April 25, 2021 [Page 13] INTERNET DRAFT App-Centric Micro-Services be required to support other invocation protocols, such as GRPC or MPI (for distributed AI use cases, as outlined in Section 3.3.). Proposals such as those in [DYN-CAST] suggest extensions to the IP anycast scheme to enable the flexible routing of service requests to one or more service instances. Common to those proposals is the use of a semantic identifier, often a service identifier akin to a URL, in the routing decision within the network. 5.5 Constraint-based Forwarding Decisions Allocating the right resources to the right micro-services is a fundamental task when executing micro-services across highly distributed micro-data centres (e.g., resource management in cloud [CLOUDFED]). This is particularly important in the light of volatile resource availability as well as concurrent and highly dynamic resource access. Once the specific set of micro-services for an application has been identified, requirements (e.g., QoS) must be ensured by the execution environment. Therefore, all micro-data centres and the execution environment will need to realize mechanisms for ensuring the utilization of specific resources within a pool of resources for a specific set of micro-services belonging to one application, while also ensuring integrity of the wider system. In relation to the service routing capability discussed in the previous sub-section, constraints may need to be introduced into the forwarding decisions for service requests. Such constraints will likely go beyond network load and latency, as often applied in scenarios such as load balancing in CDNs. Instead, those constraints are generally app/service-specific and will need a suitable representation for the use within network nodes, i.e., the routers that are forwarding service requests. Moreover, individual router decisions (e.g., realized through matching operations such as min/max/equal over a constraint representation) may be coordinated to achieve a distribution of service requests among many service instances, effectively realizing a service scheduling capability in the network, optimized around service-specific constraints, not unlike many existing data centre service switching schemes. 5.6 Collective Communication Many micro-service scenarios may exhibit some form of collective communication beyond 'just' unicast communication, therefore requiring support for 1:M, M:1, and M:N communication. It is important to consider here that such collective communication is often extremely short-lived and can even take place at the level of a single request, i.e., a following request may exhibit a different communication pattern, even at least a different receiver group for the same pattern, such as in the case of an interactive game. It is Trossen, et al. Expires April 25, 2021 [Page 14] INTERNET DRAFT App-Centric Micro-Services therefore required that solutions for supporting such collective communication must support the spontaneous formation of multicast relations, as observed in those scenarios. 5.7 State Synchronization Given the highly distributed nature of app-centric micro-services, their state exchange and synchronization is a very crucial aspect for ensuring in-application and system wide consistency. Mechanisms that ensure consistency will ensure that data is synchronized with different spatial, temporal and relational data within a given time period. From the perspective of support through in-network compute capabilities, such as provided through technologies like P4, it is important to consider what system and protocol support is required to utilize such in-network capabilities. 5.8 Dynamic Contracts NOTE: left for future revision 6 Security Considerations The use of semantic (or service) identifiers for routing decisions, as mentioned in Section 5.4October 1, 2018April 4, 2019, requires methods to ensure the privacy and security of the communication through avoiding the exposure of service semantic (which is realized at the application layer) to the network layer, therefore opening up the opportunity for traffic inspection, among other things. The use of cryptographic information, e.g., through self-certifying identifiers, should be investigated to mitigate potential security and privacy risks. 7 IANA Considerations N/A 8 Conclusion This draft positions the evolution of data centres as one of becoming execution centres for the app-centric experiences provided today mainly by smart phones directly. With the proliferation of data centres closer to the end user in the form of edge-based micro data centres, we believe that app-centric experiences will ultimately be executed across those many, highly distributed execution points that this increasingly rich edge environment will provide, such as smart glasses and IoT devices. Although a number of activities are currently underway to address some of the challenges for realizing such AppCentre evolution, we believe that the proposed COIN research Trossen, et al. Expires April 25, 2021 [Page 15] INTERNET DRAFT App-Centric Micro-Services group will provide a suitable forum to drive forward the remaining research and its dissemination into working systems and the necessary standardization of key aspects and protocols. 9 References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7665] Halpern, J., Ed., and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . 9.2 Informative References [MSERVICE1] Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, M., Montesi, F., Mustafin, R., & Safina, L. (2017). Microservices: yesterday,today, and tomorrow. In Present and Ulterior Software Engineering (pp. 195-216). Springer, Cham. [MSERVICE2] Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2016). Microservices architecture enables devops: Migration to a cloud-native architecture. IEEE Software, 33(3), 42-52. [SRVLESS] C. Cicconetti, M. Conti and A. Passarella, "An Architectural Framework for Serverless Edge Computing: Design and Emulation Tools," 2018 IEEE International Conference on Cloud Computing Technology and Science (CloudCom), Nicosia, 2018, pp. 48-55. doi: 10.1109/CloudCom2018.2018.00024 [TOSCA] Topology and Orchestration Specification for Cloud Applications Version 1.0. 25 November 2013. OASIS Standard. . [ERLANG] Armstrong, Joe, et al. "Concurrent programming in ERLANG." (1993). [SCOMPOSE] M. Hirzel, R. Soule, S. Schneider, B. Gedik, and R. Grimm, "A Catalog of Stream Processing Optimizations", ACM Computing Surveys,46(4):1-34, Mar. 2014 Trossen, et al. Expires April 25, 2021 [Page 16] INTERNET DRAFT App-Centric Micro-Services [SDEPLOY1] Lu, H., Shtern, M., Simmons, B., Smit, M., & Litoiu, M. (2013, June). Pattern-based deployment service for next generation clouds. In 2013 IEEE Ninth World Congress on Services (pp. 464-471). IEEE. [SDEPLOY2] Eilam, T., Elder, M., Konstantinou, A. V., & Snible, E. (2011, May). Pattern-based composite application deployment. In 12th IFIP/IEEE International Symposium on Integrated Network Management (IM 2011) and Workshops (pp. 217-224). IEEE. [RFC8677] Trossen, D., Purkayastha, D., Rahman, A., "Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework", RFC 8677, November 2019. [ICN5G] Ravindran, R., Suthar, P., Trossen, D., Wang, C., White, G., "Enabling ICN in 3GPP's 5G NextGen Core Architecture", (work in progress), March 2019. [ICN4G] Suthar, P., Jangam, Ed., Trossen, D., Ravindran, R., "Native Deployment of ICN in LTE, 4G Mobile Networks", (work in progress), March 2019. [CLOUDFED] M. Liaqat, V. Chang, A. Gani, S. Hafizah Ab Hamid, M. Toseef, U. Shoaib, R. Liaqat Ali, "Federated cloud resource management: Review and discussion", Elsevier Journal of Network and Computer Applications, 2017. [GRPC] High performance open source universal RPC framework, https://grpc.io/ [MPI] A. Vishnu, C. Siegel, J. Daily, "Distributed TensorFlow with MPI", https://arxiv.org/pdf/1603.02339.pdf [FCDN] M. Al-Naday, M. J. Reed, J. Riihijarvi, D. Trossen, N. Thomos, M. Al-Khalidi, "fCDN: A Flexible and Efficient CDN Infrastructure without DNS Redirection of Content Reflection", https://arxiv.org/pdf/1803.00876.pdf [DYN-CAST] Y. Li, J. He, L. Geng, P. Liu, Y. Cui, "Framework of Compute First Networking (CFN)", (work in progress), November 2019 [SA2-5GLAN] 3gpp-5glan, "SP-181129, Work Item Description, Trossen, et al. Expires April 25, 2021 [Page 17] INTERNET DRAFT App-Centric Micro-Services Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and LAN Services", 3GPP, Authors' Addresses Dirk Trossen Huawei Technologies Duesseldorf GmbH Riesstr. 25C 80992 Munich Germany Email: Dirk.Trossen@Huawei.com Chathura Sarathchandra InterDigital Europe, Ltd. 64 Great Eastern Street, 1st Floor London EC2A 3QR United Kingdom Email: Chathura.Sarathchandra@InterDigital.com Michael Boniface University of Southampton University Road Southampton SO17 1BJ United Kingdom Email: mjb@it-innovation.soton.ac.uk Trossen, et al. Expires April 25, 2021 [Page 18]