RFC 9817: Use Cases for In-Network Computing

3.1.1. Description

This scenario can be exemplified in an immersive gaming application, where a single user plays a game using a Virtual Reality (VR) headset. The headset hosts several COIN programs. For instance, the display COIN program renders frames to the user, while other programs are realized for VR content processing and to incorporate input data received from sensors (e.g., in bodily worn devices including the VR headset).¶

Once this application is partitioned into its constituent COIN programs and deployed throughout a COIN system utilizing a COIN execution environment, only the display COIN program may be left in the headset. Meanwhile, the CPU-intensive real-time VR content processing COIN program can be offloaded to a nearby resource rich home PC or a Programmable Network Device (PND) in the operator's access network for a better execution (i.e., faster and possibly higher resolution generation).¶

3.1.2. Characterization

Partitioning a mobile application into several constituent COIN programs allows for denoting the application as a collection of COIN programs for a flexible composition and a distributed execution. In our example above, most capabilities of a mobile application can be categorized into any of three groups: receiving, processing, and displaying.¶

Any device may realize one or more of the COIN programs of a mobile application and expose them to the COIN system and its constituent COIN execution environments. When the COIN program sequence is executed on a single device, the outcome is what you commonly see with applications running on mobile devices.¶

However, the execution of a COIN program may be moved to other (e.g., more suitable) devices, including PNDs, which have exposed the corresponding COIN program as individual COIN program instances to the COIN system by means of a service identifier. The result is the equivalent to mobile function offloading, in that it offers the possible reduction of power consumption (e.g., offloading CPU- intensive process functions to a remote server) or an improved end-user experience (e.g., moving display functions to a nearby smart TV) by selecting more suitably placed COIN program instances in the overall COIN system.¶

We can already see a trend toward supporting such functionality that relies on dedicated cloud hardware (e.g., gaming platforms rendering content externally). We envision, however, that such functionality is becoming more pervasive through specific facilities, such as entertainment parks or even hotels, in order to deploy needed edge computing capabilities to enable localized gaming as well as non-gaming scenarios.¶

Figure 1 shows one realization of the above scenario, where a "DPR app" is running on a mobile device (containing the partitioned COIN programs Display (D), Process (P) and Receive (R)) over a programmable switching network, e.g., a Software-Defined Network (SDN) here. The packaged applications are made available through a localized "playstore server". The mobile application installation is realized as a service deployment process, combining the local app installation with a distributed deployment (and orchestration) of one or more COIN programs on most suitable end systems or PNDs (here, a "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                 +---------+

Such localized deployment could, for instance, be provided by a visiting site, such as a hotel or a theme park. Once the processing COIN program is terminated on the mobile device, the "service routing (SR)" elements in the network route (service) requests instead to the (previously deployed) processing COIN program running on the processing server over an existing SDN network. Here, capabilities and other constraints for selecting the appropriate COIN program, in case of having deployed more than one, may be provided both in the advertisement of the COIN program and the service request itself.¶

As an extension to the above scenarios, we can also envision that content from one processing COIN program may be distributed to more than one display COIN program (e.g., for multi- and many-viewing scenarios). Here, an offloaded processing program may collate input from several users in the (virtual) environment to generate a possibly three-dimensional render that is then distributed via a service-level multicast capability towards more than one display COIN program.¶

3.1.3. Existing Solutions

The ETSI Multi-access Edge Computing (MEC) [ETSI] suite of technologies provides solutions for mobile function offloading by allowing mobile applications to select resources in edge devices to execute functions instead of the mobile device directly. For this, ETSI MEC utilizes a set of interfaces for the selection of suitable edge resources, connecting to so-called MEC application servers, while also allowing for sending data for function execution to the application server.¶

However, the technologies do not utilize microservices [Microservices]; they mainly rely on virtualization approaches such as containers or virtual machines, thus requiring a heavier processing and memory footprint in a COIN execution environment and the executing intermediaries. Also, the ETSI work does not allow for the dynamic selection and redirection of COIN program calls to varying edge resources; it does allow for them to a single MEC application server.¶

Also, the selection of the edge resource (the app server) is relatively static, relying on DNS-based endpoint selection, which does not cater to the requirements of the example provided above, where the latency for redirecting to another device lies within a few milliseconds for aligning with the frame rate of the display microservice.¶

Lastly, MEC application servers are usually considered resources provided by the network operator through its MEC infrastructure, while our use case here also foresees the placement and execution of microservices in end-user devices.¶

There also exists a plethora of mobile offloading platforms provided through proprietary platforms, all of which follow a similar approach as ETSI MEC in that a selected edge application server is being utilized to send functional descriptions and data for execution.¶

[APPCENTRES] outlines a number of enabling technologies for the use case, some of which have been realized in an Android-based realization of the microservices as a single application, which is capable of dynamically redirecting traffic to other microservice instances in the network. This capability, together with the underlying path-based forwarding capability (using SDN), was demonstrated publicly (e.g., at the Mobile World Congress 2018 and 2019).¶

3.1.4. Opportunities

3.1.5. Research Questions

3.2.1. Description

Extended Reality (XR) encompasses VR, Augmented Reality (AR) and Mixed Reality (MR). It provides the basis for the metaverse and is the driver of a number of advances in interactive technologies. While initially associated with gaming and immersive entertainment, applications now include remote diagnosis, maintenance, telemedicine, manufacturing and assembly, intelligent agriculture, smart cities, and immersive classrooms. XR is one example of the multisource-multidestination problem that combines video and haptics in interactive multiparty interactions under strict delay requirements. As such, XR can benefit from a functional distribution that includes fog computing for local information processing, the edge for aggregation, and the cloud for image processing.¶

XR stands to benefit significantly from computing capabilities in the network. For example, XR applications can offload intensive processing tasks to edge servers, considerably reducing latency when compared to cloud-based applications and enhancing the overall user experience. More importantly, COIN can enable collaborative XR experiences, where multiple users interact in the same virtual space in real time, regardless of their physical locations, by allowing resource discovery and re-routing of XR streams. While not a feature of most XR implementations, this capability opens up new possibilities for remote collaboration, training, and entertainment. Furthermore, COIN can support dynamic content delivery, allowing XR applications to seamlessly adapt to changing environments and user interactions. Hence, the integration of computing capabilities into the network architecture enhances the scalability, flexibility, and performance of XR applications by supplying telemetry and advanced stream management, paving the way for more immersive and interactive experiences.¶

Indeed, XR applications require real-time interactivity for immersive and increasingly mobile applications with tactile and time-sensitive data. Because high bandwidth is needed for high resolution images and local rendering for 3D images and holograms, strictly relying on cloud-based architectures, even with headset processing, limits some of its potential benefits in the collaborative space. As a consequence, innovation is needed to unlock the full potential of XR.¶

3.2.2. Characterization

As mentioned above, XR experiences, especially those involving collaboration, are difficult to deliver with a client-server cloud-based solution. This is because they require a combination of multistream aggregation, low delays and delay variations, means to recover from losses, and optimized caching and rendering as close as possible to the user at the network edge. Hence, implementing such XR solutions necessitates substantial computational power and minimal latency, which, for now, has spurred the development of better headsets, rather than spurring networked or distributed solutions, as factors like distance from cloud servers and limited bandwidth can still significantly lower application responsiveness. Furthermore, when XR deals with sensitive information, XR applications must also provide a secure environment and ensure user privacy, which represent additional burdens for delay-sensitive applications. Additionally, the sheer amount of data needed for and generated by XR applications, such as video holography, put them squarely in the realm of data-driven applications that can use recent trend analysis and mechanisms, as well as machine learning, in order to find the optimal caching and processing solution and ideally reduce the size of the data that needs transiting through the network. Other mechanisms, such as data filtering and reduction, and functional distribution and partitioning, are also needed to accommodate the low delay needs for the same applications.¶

With functional decomposition as the goal of a better XR experience, the elements involved in a COIN XR implementation include:¶

These characteristics of XR paired with the capabilities of COIN make it likely that COIN can help to realize XR over networks for collaborative applications. In particular, COIN functions can enable the distribution of the service components across different nodes in the network. For example, data filtering, image rendering, and video processing leverage different hardware capabilities with combinations of CPUs and Graphics Processing Units (GPUs) at the network edge and in the fog, where the content is consumed. These represent possible remedies for the high bandwidth demands of XR. Machine learning across the network nodes can better manage the data flows by distributing them over more adequate paths. In order to provide adequate quality of experience, multivariate and heterogeneous resource allocation and goal optimization problems need to be solved, likely requiring advanced analysis and artificial intelligence. For the purpose of this document, it is important to note that the use of COIN for XR does not imply a specific protocol but targets an architecture enabling the deployment of the services. In this context, similar considerations as for Section 3.1 apply.¶

3.2.3. Existing Solutions

The XR field has profited from extensive research in the past years in gaming, machine learning, network telemetry, high resolution imaging, smart cities, and the Internet of Things (IoT). Information-Centric Networking (ICN) (and related) approaches that combine publish-subscribe and distributed storage are also very suited for the multisource-multidestination applications of XR. New AR and VR headsets and glasses have continued to evolve towards autonomy with local computation capabilities, increasingly performing much of the processing that is needed to render and augment the local images. Mechanisms aimed at enhancing the computational and storage capacities of mobile devices could also improve XR capabilities, as they include discovering available servers within the environment and using them opportunistically to enhance the performance of interactive applications and distributed file systems.¶

While there is still no specific COIN research in AR and VR, the need for network support is important to offload some of the computations related to movement, multiuser interactions, and networked applications, notably in gaming but also in health [NetworkedVR]. This new approach to networked AR and VR is exemplified in [eCAR] by using synchronized messaging at the edge to share the information that all users need to interact. In [CompNet2021] and [WirelessNet2024], the offloading uses Artificial Intelligence (AI) to assign the 5G resources necessary for the real-time interactions, and one could think that implementing this scheme on a PND is essentially a natural next step. Hence, as AR, VR, and XR are increasingly becoming more interactive, the efficiency needed to implement novel applications will require some form or another of edge-core implementation and COIN support.¶

In summary, some XR solutions exist, and headsets continue to evolve to what is now claimed to be spatial computing. Additionally, with recent work on the metaverse, the number of publications related to XR has skyrocketed. However, in terms of networking, which is the focus of this document, current deployments do not take advantage of network capabilities. The information is rendered and displayed based on the local processing but does not readily discover the other elements in the vicinity or in the network that could improve its performance either locally, at the edge, or in the cloud. Yet, there are still very few interactive and immersive media applications over networks that allow for the federation of systems capabilities.¶

3.2.4. Opportunities

While delay is inherently related to information transmission, if we continue the analogy of the computer board to highlight some of the COIN capabilities in terms of computation and storage but also allocation of resources, there are some opportunities that XR could take advantage of:¶

3.2.5. Research Questions

3.2.6. Additional Desirable Capabilities

In addition to the capabilities driven by the research questions above, there are a number of other features that solutions in this space might benefit from. In particular, the provided XR experience should be optimized both in the amount of transmitted data, while equally optimizing loss protection. Furthermore, the means for trend analysis and telemetry to measure performance may foster uptake of the XR services, while the interaction of the XR system with indoor and outdoor positioning systems may improve on service experience and user perception.¶

3.3.1. Description

This use case is a deeper dive into a specific scenario of the immersive and extended reality class of use cases discussed in Section 3.2. It focuses on live productions of the performing arts where the performers and audience members are geographically distributed. The performance is conveyed through multiple networked streams, which are tailored to the requirements of the remote performers, the director, the sound and lighting technicians, and the individual audience members. Performers need to observe, interact, and synchronize with other performers in remote locations, and the performers receive live feedback from the audience, which may also be conveyed to other audience members.¶

There are two main aspects:¶

Examples of personalization include:¶

3.3.2. Characterization

There are several chained functional entities that are candidates for being deployed as COIN programs:¶

These are candidates for deployment as COIN programs in PNDs rather than being located in end systems (at the performers' site, the audience members' premises, or in a central cloud location) for several reasons:¶

3.3.3. Existing Solutions

Note: Existing solutions for some aspects of this use case are covered in Section 3.1, Section 3.2, and Section 5.1.¶

3.3.4. Opportunities

3.3.5. Research Questions

3.3.6. Additional Desirable Capabilities

In addition to the capabilities driven by the research questions above, there are a number of other features that solutions in this space might benefit from. In particular, if users are indeed empowered to specify requirements on network and processing metrics, one important capability of COIN systems will be to respect these user-specified requirements and constraints when routing flows and selecting PNDs for executing COIN programs. Similarly, solutions should be able to synchronize flow treatment and processing across multiple related flows, which may be on disjoint paths, to provide similar performance to different entities.¶

4.1.1. Description

The control of physical processes and components of industrial production lines is essential for the growing automation of production and ideally allows for a consistent quality level. Commonly, the control has been exercised by control software running on Programmable Logic Controllers (PLCs) located directly next to the controlled process or component. This approach is best suited for settings with a simple model that is focused on a single or a few controlled components.¶

Modern production lines and shop floors are characterized by an increasing number of involved devices and sensors, a growing level of dependency between the different components, and more complex control models. A centralized control is desirable to manage the large amount of available information, which often has to be preprocessed or aggregated with other information before it can be used. As a result, computations are increasingly spatially decoupled and moved away from the controlled objects, thus inducing additional latency. Instead, moving compute functionality onto COIN execution environments inside the network offers a new solution space to these challenges, providing new compute locations with much smaller latencies.¶

4.1.2. Characterization

A control process consists of two main components as illustrated in Figure 2: a system under control and a controller. In feedback control, the current state of the system is monitored (e.g., using sensors), and the controller influences the system based on the difference between the current and the reference state to keep it close to this reference state.¶

 reference
   state      ------------        --------    Output
---------->  | Controller | ---> | System | ---------->
           ^  ------------        --------       |
           |                                     |
           |   observed state                    |
           |                    ---------        |
            -------------------| Sensors | <-----
                                ---------

Apart from the control model, the quality of the control primarily depends on the timely reception of the sensor feedback, which can be subject to tight latency constraints, often in the single-digit millisecond range. Even shorter feedback requirements may exist in other use cases, such as interferometry or high-energy physics, but these use cases are out of scope for this document. While low latencies are essential, there is an even greater need for stable and deterministic levels of latency, because controllers can generally cope with different levels of latency if they are designed for them, but they are significantly challenged by dynamically changing or unstable latencies. The unpredictable latency of the Internet exemplifies this problem if, for example, off-premise cloud platforms are included.¶

4.1.3. Existing Solutions

Control functionality is commonly executed on PLCs close to the machinery. These PLCs typically require vendor-specific implementations and are often hard to upgrade and update, which makes such control processes inflexible and difficult to manage. Moving computations to more freely programmable devices thus has the potential of significantly improving the flexibility. In this context, directly moving control functionality to (central) cloud environments is generally possible, yet only feasible if latency constraints are lenient.¶

Early approaches such as [RÜTH] and [VESTIN] have already shown the general applicability of leveraging COIN for in-network control.¶

4.1.4. Opportunities

4.1.5. Research Questions

4.1.6. Additional Desirable Capabilities

In addition to the capabilities driven by the research questions above, there are a number of other features that approaches deploying control functionality in COIN execution environments could benefit from. For example, having an explicit interaction between the COIN execution environments and the global controller would ensure that it is always clear which entity is emitting which signals. In this context, it is also important that actions of COIN execution environments are overridable by the global controller such that the global controller has the final say in the process behavior. Finally, by accommodating the general characteristics of control approaches, functions in COIN execution environments should ideally expose reliable information on the predicted delay and must expose reliable information on the predicted accuracy to the global control such that these aspects can be accommodated in the overall control.¶

4.2.1. Description

In modern industrial networks, processes and machines are extensively monitored by distributed sensors with a large spectrum of capabilities, ranging from simple binary (e.g., light barriers) to sophisticated sensors with varying degrees of resolution. Sensors further serve different purposes, as some are used for time-critical process control, while others represent redundant fallback platforms. Overall, there is a high level of heterogeneity, which makes managing the sensor output a challenging task.¶

Depending on the deployed sensors and the complexity of the observed system, the resulting overall data volume can easily be in the range of several Gbit/s [GLEBKE]. These volumes are often already difficult to handle in local environments, and it becomes even more challenging when off-premise clouds are used for managing the data. While large networking companies can simply upgrade their infrastructure to accommodate the accruing data volumes, most industrial companies operate on tight infrastructure budgets such that frequently upgrading is not always feasible or possible. Hence, a major challenge is to devise a methodology that is able to handle such amounts of data efficiently and flexibly without relying on recurring infrastructure upgrades.¶

Data filtering and preprocessing, similar to the considerations in Section 3.2, can be building blocks for new solutions in this space. Such solutions, however, might also have to address the added challenge of business data leaving the premises and control of the company. As this data could include sensitive information or valuable business secrets, additional security measures have to be taken. Yet, typical security measures such as encrypting the data make filtering or preprocessing approaches hardly applicable as they typically work on unencrypted data. Consequently, incorporating security into these approaches, either by adding functionality for handling encrypted data or devising general security measures, is an additional auspicious field for research.¶

4.2.2. Characterization

In essence, the described monitoring systems consist of sensors that produce large volumes of monitoring data. This data is then transmitted to additional components that provide data processing and analysis capabilities or simply store the data in large data silos.¶

As sensors are often set up redundantly, parts of the collected data might also be redundant. Moreover, sensors are often hard to configure or not configurable at all, which is why their resolution or sampling frequency is often larger than required. Consequently, it is likely that more data is transmitted than is needed or desired, prompting the deployment of filtering techniques. For example, COIN programs deployed in the on-premise network could filter out redundant or undesired data before it leaves the premise using simple traffic filters, thus reducing the required (upload) bandwidths. The available sensor data could be scaled down using standard statistical sampling, packet-based sub-sampling (i.e., only forwarding every n-th packet), or using filtering as long as the sensor value is in an uninteresting range while forwarding with a higher resolution once the sensor value range becomes interesting (cf. [KUNZE-SIGNAL] and [TIRPITZ-REDUCIO]). While the former variants are oblivious to the semantics of the sensor data, the latter variant requires an understanding of the current sensor levels. In any case, it is important that end hosts are informed about the filtering so that they can distinguish between data loss and data filtered out on purpose.¶

In practice, the collected data is further processed using various forms of computation. Some of them are very complex or need the complete sensor data during the computation, but there are also simpler operations that can already be done on subsets of the overall dataset or earlier on the communication path as soon as all data is available. One example is finding the maximum of all sensor values, which can either be done iteratively at each intermediate hop or at the first hop where all data is available. Using expert knowledge about the exact computation steps and the concrete transmission path of the sensor data, simple computation steps can thus be deployed in the on-premise network, again reducing the overall data volume.¶

4.2.3. Existing Solutions

Current approaches for handling such large amounts of information typically build upon stream processing frameworks such as Apache Flink. These solutions allow for handling large-volume applications and map the compute functionality to performant server machines or distributed compute platforms. Augmenting the existing capabilities, COIN offers a new dimension of platforms for such processing frameworks.¶

4.2.4. Opportunities

4.2.5. Research Questions

Some of the following research questions are also relevant in the context of general stream processing systems.¶

4.2.6. Additional Desirable Capabilities

In addition to the capabilities driven by the research questions above, there are a number of other features that such large-volume applications could benefit from. In particular, conforming to standard application-level syntax and semantics likely simplifies embedding filters and preprocessors into the overall system. If these filters and preprocessors also leverage packet header and payload information for their operation, this could further improve the performance of any approach developed based on the above research questions.¶

4.3.1. Description

Despite an increasing automation in production processes, human workers are still often necessary. Consequently, safety measures have a high priority to ensure that no human life is endangered. In conventional factories, the regions of contact between humans and machines are well defined and interactions are simple. Simple safety measures like emergency switches at the working positions are enough to provide a good level of safety.¶

Modern factories are characterized by increasingly dynamic and complex environments with new interaction scenarios between humans and robots. Robots can directly assist humans, perform tasks autonomously, or even freely move around on the shop floor. Hence, the intersect between the human working area and the robots grows, and it is harder for human workers to fully observe the complete environment. Additional safety measures are essential to prevent accidents and support humans in observing the environment.¶

4.3.2. Characterization

Industrial safety measures are typically hardware solutions because they have to pass rigorous testing before they are certified and deployment ready. Standard measures include safety switches and light barriers. Additionally, the working area can be explicitly divided into "contact" and "safe" areas, indicating when workers have to watch out for interactions with machinery. For example, markings on the factory floor can show the areas where robots move or indicate their maximum physical reach.¶

These measures are static solutions, potentially relying on specialized hardware, and are challenged by the increased dynamics of modern factories where the factory configuration can be changed on demand or where all entities are freely moving around. Software solutions offer higher flexibility as they can dynamically respect new information gathered by the sensor systems, but in most cases they cannot give guaranteed safety. COIN systems could leverage the increased availability of sensor data and the detailed monitoring of the factories to enable additional safety measures with shorter response times and higher guarantees. Different safety indicators within the production hall could be combined within the network so that PNDs can give early responses if a potential safety breach is detected. For example, the positions of human workers and robots could be tracked, and robots could be stopped when they get too close to a human in a non-working area or if a human enters a defined safety zone. More advanced concepts could also include image data or combine arbitrary sensor data. Finally, the increasing softwarization of industrial processes can also lead to new problems, e.g., if software bugs cause unintended movements of robots. Here, COIN systems could independently double check issued commands to void unsafe commands.¶

4.3.3. Existing Solutions

Due to the importance of safety, there is a wide range of software-based approaches aiming at enhancing security. One example are tag-based systems (e.g., using RFID), where drivers of forklifts can be warned if pedestrian workers carrying tags are nearby. Such solutions, however, require setting up an additional system and do not leverage existing sensor data.¶

4.3.4. Opportunities

4.3.5. Research Questions

5.1.1. Description

Delivery of content to end users often relies on Content Delivery Networks (CDNs). CDNs store said content closer to end users for latency-reduced delivery as well as to reduce load on origin servers. For this, they often utilize DNS-based indirection to serve the request on behalf of the origin server. Both of these objectives are within scope to be addressed by COIN methods and solutions.¶

5.1.2. Characterization

From the perspective of this draft, a CDN can be interpreted as a (network service level) set of COIN programs. These programs implement a distributed logic for first distributing content from the origin server to the CDN ingress and then further to the CDN replication points, which ultimately serve the user-facing content requests.¶

5.1.3. Existing Solutions

CDN technologies have been well described and deployed in the existing Internet. Core technologies like Global Server Load Balancing (GSLB) [GSLB] and Anycast server solutions are used to deal with the required indirection of a content request (usually in the form of an HTTP request) to the most suitable local CDN server. Content is replicated from seeding servers, which serve as injection points for content from content owners/producers, to the actual CDN servers, which will eventually serve the user's request. The replication architecture and mechanisms themselves differ from one (CDN) provider to another, and often utilize private peering or network arrangements in order to distribute the content internationally and regionally.¶

Studies such as those in [FCDN] have shown that content distribution at the level of named content, utilizing efficient (e.g., Layer 2 (L2)) 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 required edge storage capacity by benefiting from the increased network efficiency to renew edge content more quickly against changing demand. Works such as those in [SILKROAD] utilize Application-Specific Integrated Circuits (ASICs) to replace server-based load balancing with significant cost reductions, thus showcasing the potential for in-network operations.¶

5.1.4. Opportunities

5.1.5. Research Questions

In addition to the research questions in Section 3.1.5:¶

5.2.1. Description

We interpret connected compute resources as operating at a suitable layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3), to allow for the exchange of suitable invocation methods, such as those exposed through verb-based or socket-based APIs. The specific invocations here are subject to the applications running over a selected pool of such connected compute resources.¶

Providing such a pool of connected compute resources (e.g., in regional or edge data centers, base stations, and even end-user devices) opens up the opportunity for infrastructure providers to offer CFaaS-like offerings to application providers, leaving the choice of the appropriate invocation method to the app and service provider. Through this, the compute resources can be utilized to execute the desired COIN programs of which the application is composed, while utilizing the interconnection between those compute resources to do so in a distributed manner.¶

5.2.2. Characterization

We foresee those CFaaS offerings to be tenant-specific, with a tenant here defined as the provider of at least one application. For this, we foresee an interaction between the 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, for example, 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 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 suitably interconnect all resources into the (tenant-specific) fabric exposed as CFaaS.¶

5.2.3. Existing Solutions

There exist a number of technologies to build non-local (wide area) L2 as well as L3 networks, which in turn allows for connecting compute resources for a distributed computational task. For instance, 5G-LAN [SA2-5GLAN] specifies a cellular L2 bearer for interconnecting L2 resources within a single cellular operator. The work in [ICN-5GLAN] outlines using a path-based forwarding solution over 5G-LAN as well as SDN-based LAN connectivity together with an ICN-based naming of IP and HTTP-level resources. This is done in order to achieve computational interconnections, including scenarios such as those outlined in Section 3.1. L2 network virtualization (see [L2Virt]) is one of the methods used for realizing so-called "cloud-based" applications for applications developed with "physical" networks in mind, thus forming an interconnected compute and storage fabric.¶

5.2.4. Opportunities

5.2.5. Research Questions

In addition to the research questions in Section 3.1.5:¶

5.3.1. Description

The term "virtual network programming" is proposed to describe mechanisms by which tenants deploy and operate COIN programs in their virtual network. Such COIN programs can be, for example, P4 programs, OpenFlow rules, or higher layer programs. This feature can enable other use cases described in this draft to be deployed using virtual network services, over underlying networks such as data centers, mobile networks, or other fixed or wireless networks.¶

For example, COIN programs could perform the following on a tenant's virtual network:¶

5.3.2. Characterization

To provide a concrete example of virtual COIN programming, we consider a use case using a 5G underlying network, the 5GLAN virtualization technology, and the P4 programming language and environment. As an assumption in this use case, some mobile network equipment (e.g., User Plane Functions (UPFs)) and devices (e.g., mobile phones or residential gateways) include a network switch functionality that is used as a PND.¶

Section 5.1 of [ICN-5GC] provides a description of the 5G network functions and interfaces relevant to 5GLAN, which are otherwise specified in [TS23.501] and [TS23.502]. From the 5GLAN service customer/tenant standpoint, the 5G network operates as a switch.¶

In the use case depicted in Figure 3, the tenant operates a network including a 5GLAN network segment (seen as a single logical switch), as well as fixed segments. The mobile devices (or User Equipment nodes) UE1, UE2, UE3, and UE4 are in the same 5GLAN, as well as Device1 and Device2 (through UE4). This scenario can take place in a plant or enterprise network, using a 5G non-public network, for example. The tenant uses P4 programs to determine the operation of both the fixed and 5GLAN switches. The tenant provisions a 5GLAN P4 program into the mobile network and can also operate a controller.¶

                                     ..... Tenant ........
                          P4 program :                   :
                          deployment :         Operation :
                                     V                   :
  +-----+  air interface +----------------+              :
  | UE1 +----------------+                |              :
  +-----+                |                |              :
                         |                |              :
  +-----+                |                |              V
  | UE2 +----------------+     5GLAN      |      +------------+
  +-----+                |    Logical     +------+ Controller |
                         |     Switch     |  P4  +-------+----+
  +-----+                |                |  runtime     |
  | UE3 +----------------+                |  API         |
  +-----+                |                |              |
                         |                |              |
  +-----+                |                |              |
+-+ UE4 +----------------+                |              |
| +-----+                +----------------+              |
|                                                        |
| Fixed or wireless connection                           |
|                                    P4 runtime API      |
|  +---------+           +-------------------------------+
+--+ Device1 |           |
|  +---------+           |
|                        |
|  +---------+    +------+-----+
`--+ Device2 +----+ P4 Switch  +--->(fixed network)
   +---------+    +------------+

5.3.3. Existing Solutions

Research has been conducted, for example by [Stoyanov], to enable P4 network programming of individual virtual switches. To our knowledge, no complete solution has been developed for deploying virtual COIN programs over mobile or data center networks.¶

5.3.4. Opportunities

Virtual network programming by tenants could bring benefits such as:¶

5.3.5. Research Questions

6.1.1. Description

There is a growing range of use cases demanding the realization of AI training capabilities among distributed endpoints. One such use case is to distribute large-scale model training across more than one data center (e.g., when facing energy issues at a single site or when simply reaching the scale of training capabilities at one site, thus wanting to complement training with the capabilities of another or possibly many sites). From a COIN perspective, those capabilities may be realized as COIN programs and executed throughout a COIN system, including in PNDs.¶

6.1.2. Characterization

Some solutions may desire the localization of reasoning logic (e.g., for deriving attributes that better preserve privacy of the utilized raw input data). Quickly establishing COIN program instances in nearby compute resources, including PNDs, may even satisfy such localization demands on the fly (e.g., when a particular use is being realized, then terminated after a given time).¶

Individual training "sites" may not be a data center, but may instead consist of powerful, yet stand-along devices that federate computing power towards training a model, captured as "federated training" and provided through platforms such as [FLOWER]. Use cases here may be that of distributed training on (user) image data, the training over federated social media sites [MASTODON], or others.¶

Apart from the distribution of compute power, the distribution of data may be a driver for distributed AI training use cases, such as in the Mastodon federated social media sites [MASTODON] or training over locally governed patient data or others.¶

6.1.3. Existing Solutions

Reasoning frameworks, such as TensorFlow, may be utilized for the realization of the (distributed) AI training logic, building on remote service invocation through protocols such as gRPC [GRPC] or the Message Passing Interface (MPI) [MPI] with the intention of providing an on-chip Neural Processor Unit (NPU) like abstraction to the AI framework.¶

A number of activities on distributed AI training exist in the area of developing the 5th and 6th generation mobile network, with various activities in the 3GPP Standards Development Organization (SDO) as well as use cases developed for the ETSI MEC initiative mentioned in previous use cases.¶

6.1.4. Opportunities

6.1.5. Research Questions

In addition to the research questions in Section 3.1.5:¶