rfc9817v4.txt   rfc9817.txt 
skipping to change at line 99 skipping to change at line 99
11. Informative References 11. Informative References
Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
The Internet was designed as a best-effort packet network, forwarding The Internet was designed as a best-effort packet network, forwarding
packets from source to destination with limited guarantees regarding packets from source to destination with limited guarantees regarding
their timely and successful reception. Data manipulation, their timely and successful reception. Data manipulation,
computation, and more complex protocol functionalities are generally computation, and more complex protocol functionalities are generally
provided by the end hosts, while network nodes are traditionally kept provided by the end hosts, while network nodes are commonly kept
simple and only offer a "store and forward" packet facility. This simple and only offer a "store and forward" packet facility. This
simplicity of purpose of the network has shown to be suitable for a simplicity of purpose of the network has shown to be suitable for a
wide variety of applications and has facilitated the rapid growth of wide variety of applications and has facilitated the rapid growth of
the Internet. However, introducing middleboxes with specialized the Internet. However, introducing middleboxes with specialized
functionality for enhancing performance has often led to problems due functionality for enhancing performance has often led to problems due
to their inflexibility. to their inflexibility.
However, with the rise of new services, some of which are described However, with the rise of new services, some of which are described
in this document, there is a growing number of application domains in this document, there is a growing number of application domains
that require more than best-effort forwarding, including strict that require more than best-effort forwarding, including strict
skipping to change at line 185 skipping to change at line 185
for any COIN solution addressing the particular use case; we limit for any COIN solution addressing the particular use case; we limit
these capabilities to those directly affecting COIN, recognizing these capabilities to those directly affecting COIN, recognizing
that any use case will realistically require many additional that any use case will realistically require many additional
capabilities for its realization. We omit this dedicated section capabilities for its realization. We omit this dedicated section
if relevant capabilities are already sufficiently covered by the if relevant capabilities are already sufficiently covered by the
corresponding research questions. corresponding research questions.
This document discusses these six aspects along a number of This document discusses these six aspects along a number of
individual use cases to demonstrate the diversity of COIN individual use cases to demonstrate the diversity of COIN
applications. It is intended as a basis for further analyses and applications. It is intended as a basis for further analyses and
discussions within the wider research community. This document discussions within the wider research community. This document has
represents the consensus of COINRG. received review comments at different stages of its development, by
experts within and out of COINRG, as detailed in the Acknowledgements
section. This document represents the consensus of COINRG.
2. Terminology 2. Terminology
This document uses the terminology defined below. This document uses the terminology defined below.
Programmable Network Devices (PNDs): network devices, such as Programmable Network Devices (PNDs): network devices, such as
network interface cards and switches, which are programmable network interface cards and switches, which are programmable
(e.g., using P4 [P4] or other languages). (e.g., using P4 [P4] or other languages).
(COIN) execution environment: a class of target environments for COIN execution environment: a class of target environments for
function execution, for example, an execution environment based on function execution, for example, an execution environment based on
the Java Virtual Machine (JVM) that can run functions represented the Java Virtual Machine (JVM) that can run functions represented
in JVM byte code. in JVM byte code.
COIN system: the PNDs (and end systems) and their execution COIN system: the PNDs (and end systems) and their execution
environments, together with the communication resources environments, together with the communication resources
interconnecting them, operated by a single provider or through interconnecting them, operated by a single provider or through
interactions between multiple providers that jointly offer COIN interactions between multiple providers that jointly offer COIN
capabilities. capabilities.
COIN capability: a feature enabled through the joint processing of COIN capability: a feature enabled through the joint processing of
computation and communication resources in the network. computation and communication resources in the network.
(COIN) program: a monolithic functionality that is provided COIN program: a monolithic functionality that is provided according
according to the specification for said program and which may be to the specification for said program and which may be requested
requested by a user. A composite service can be built by by a user. A composite service can be built by orchestrating a
orchestrating a combination of monolithic COIN programs. combination of monolithic COIN programs.
(COIN) program instance: one running instance of a program. COIN program instance: one running instance of a program.
COIN experience: a new user experience brought about through the COIN experience: a new user experience brought about through the
utilization of COIN capabilities. utilization of COIN capabilities.
3. Providing New COIN Experiences 3. Providing New COIN Experiences
3.1. Mobile Application Offloading 3.1. Mobile Application Offloading
3.1.1. Description 3.1.1. Description
This scenario can be exemplified in an immersive gaming application, This scenario can be exemplified in an immersive gaming application,
where a single user plays a game using a Virtual Reality (VR) where a single user plays a game using a Virtual Reality (VR)
headset. The headset hosts several (COIN) programs. For instance, headset. The headset hosts several COIN programs. For instance, the
the display (COIN) program renders frames to the user, while other display COIN program renders frames to the user, while other programs
programs are realized for VR content processing and to incorporate are realized for VR content processing and to incorporate input data
input data received from sensors (e.g., in bodily worn devices received from sensors (e.g., in bodily worn devices including the VR
including the VR headset). headset).
Once this application is partitioned into its constituent (COIN) Once this application is partitioned into its constituent COIN
programs and deployed throughout a COIN system utilizing a COIN programs and deployed throughout a COIN system utilizing a COIN
execution environment, only the display (COIN) program may be left in execution environment, only the display COIN program may be left in
the headset. Meanwhile, the CPU-intensive real-time VR content the headset. Meanwhile, the CPU-intensive real-time VR content
processing (COIN) program can be offloaded to a nearby resource rich processing COIN program can be offloaded to a nearby resource rich
home PC or a Programmable Network Device (PND) in the operator's home PC or a Programmable Network Device (PND) in the operator's
access network for a better execution (i.e., faster and possibly access network for a better execution (i.e., faster and possibly
higher resolution generation). higher resolution generation).
3.1.2. Characterization 3.1.2. Characterization
Partitioning a mobile application into several constituent (COIN) Partitioning a mobile application into several constituent COIN
programs allows for denoting the application as a collection of programs allows for denoting the application as a collection of COIN
(COIN) programs for a flexible composition and a distributed programs for a flexible composition and a distributed execution. In
execution. In our example above, most capabilities of a mobile our example above, most capabilities of a mobile application can be
application can be categorized into any of three groups: receiving, categorized into any of three groups: receiving, processing, and
processing, and displaying. displaying.
Any device may realize one or more of the (COIN) programs of a mobile 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 application and expose them to the COIN system and its constituent
(COIN) execution environments. When the (COIN) program sequence is COIN execution environments. When the COIN program sequence is
executed on a single device, the outcome is what you traditionally executed on a single device, the outcome is what you commonly see
see with applications running on mobile devices. with applications running on mobile devices.
However, the execution of a (COIN) program may be moved to other However, the execution of a COIN program may be moved to other (e.g.,
(e.g., more suitable) devices, including PNDs, which have exposed the more suitable) devices, including PNDs, which have exposed the
corresponding (COIN) program as individual (COIN) program instances corresponding COIN program as individual COIN program instances to
to the (COIN) system by means of a service identifier. The result is the COIN system by means of a service identifier. The result is the
the equivalent to mobile function offloading, in that it offers the equivalent to mobile function offloading, in that it offers the
possible reduction of power consumption (e.g., offloading CPU- possible reduction of power consumption (e.g., offloading CPU-
intensive process functions to a remote server) or an improved end- intensive process functions to a remote server) or an improved end-
user experience (e.g., moving display functions to a nearby smart TV) user experience (e.g., moving display functions to a nearby smart TV)
by selecting more suitably placed (COIN) program instances in the by selecting more suitably placed COIN program instances in the
overall (COIN) system. overall COIN system.
We can already see a trend toward supporting such functionality that We can already see a trend toward supporting such functionality that
relies on dedicated cloud hardware (e.g., gaming platforms rendering relies on dedicated cloud hardware (e.g., gaming platforms rendering
content externally). We envision, however, that such functionality content externally). We envision, however, that such functionality
is becoming more pervasive through specific facilities, such as is becoming more pervasive through specific facilities, such as
entertainment parks or even hotels, in order to deploy needed edge entertainment parks or even hotels, in order to deploy needed edge
computing capabilities to enable localized gaming as well as non- computing capabilities to enable localized gaming as well as non-
gaming scenarios. gaming scenarios.
Figure 1 shows one realization of the above scenario, where a "DPR Figure 1 shows one realization of the above scenario, where a "DPR
app" is running on a mobile device (containing the partitioned COIN app" is running on a mobile device (containing the partitioned COIN
programs Display (D), Process (P) and Receive (R)) over a programs Display (D), Process (P) and Receive (R)) over a
programmable switching network, e.g., a Software-Defined Network programmable switching network, e.g., a Software-Defined Network
(SDN) here. The packaged applications are made available through a (SDN) here. The packaged applications are made available through a
localized "playstore server". The mobile application installation is localized "playstore server". The mobile application installation is
realized as a service deployment process, combining the local app realized as a service deployment process, combining the local app
installation with a distributed deployment (and orchestration) of one installation with a distributed deployment (and orchestration) of one
or more (COIN) programs on most suitable end systems or PNDs (here, a or more COIN programs on most suitable end systems or PNDs (here, a
"processing server"). "processing server").
+----------+ Processing Server +----------+ Processing Server
Mobile | +------+ | Mobile | +------+ |
+---------+ | | P | | +---------+ | | P | |
| App | | +------+ | | App | | +------+ |
| +-----+ | | +------+ | | +-----+ | | +------+ |
| |D|P|R| | | | SR | | | |D|P|R| | | | SR | |
| +-----+ | | +------+ | Internet | +-----+ | | +------+ | Internet
| +-----+ | +----------+ / | +-----+ | +----------+ /
skipping to change at line 319 skipping to change at line 321
|+-------+| /+--+ |+-------+| /+--+
|| SR || +---------+ || SR || +---------+
|+-------+| |Playstore| |+-------+| |Playstore|
+---------+ | Server | +---------+ | Server |
TV +---------+ TV +---------+
Figure 1: Application Function Offloading Example Figure 1: Application Function Offloading Example
Such localized deployment could, for instance, be provided by a Such localized deployment could, for instance, be provided by a
visiting site, such as a hotel or a theme park. Once the processing visiting site, such as a hotel or a theme park. Once the processing
(COIN) program is terminated on the mobile device, the "service COIN program is terminated on the mobile device, the "service routing
routing (SR)" elements in the network route (service) requests (SR)" elements in the network route (service) requests instead to the
instead to the (previously deployed) processing (COIN) program (previously deployed) processing COIN program running on the
running on the processing server over an existing SDN network. Here, processing server over an existing SDN network. Here, capabilities
capabilities and other constraints for selecting the appropriate and other constraints for selecting the appropriate COIN program, in
(COIN) program, in case of having deployed more than one, may be case of having deployed more than one, may be provided both in the
provided both in the advertisement of the (COIN) program and the advertisement of the COIN program and the service request itself.
service request itself.
As an extension to the above scenarios, we can also envision that As an extension to the above scenarios, we can also envision that
content from one processing (COIN) program may be distributed to more content from one processing COIN program may be distributed to more
than one display (COIN) program (e.g., for multi- and many-viewing than one display COIN program (e.g., for multi- and many-viewing
scenarios). Here, an offloaded processing program may collate input scenarios). Here, an offloaded processing program may collate input
from several users in the (virtual) environment to generate a from several users in the (virtual) environment to generate a
possibly three-dimensional render that is then distributed via a possibly three-dimensional render that is then distributed via a
service-level multicast capability towards more than one display service-level multicast capability towards more than one display COIN
(COIN) program. program.
3.1.3. Existing Solutions 3.1.3. Existing Solutions
The ETSI Mobile-access Edge Computing (MEC) [ETSI] suite of The ETSI Multi-access Edge Computing (MEC) [ETSI] suite of
technologies provides solutions for mobile function offloading by technologies provides solutions for mobile function offloading by
allowing mobile applications to select resources in edge devices to allowing mobile applications to select resources in edge devices to
execute functions instead of the mobile device directly. For this, execute functions instead of the mobile device directly. For this,
ETSI MEC utilizes a set of interfaces for the selection of suitable ETSI MEC utilizes a set of interfaces for the selection of suitable
edge resources, connecting to so-called MEC application servers, edge resources, connecting to so-called MEC application servers,
while also allowing for sending data for function execution to the while also allowing for sending data for function execution to the
application server. application server.
However, the technologies do not utilize microservices However, the technologies do not utilize microservices
[Microservices]; they mainly rely on virtualization approaches such [Microservices]; they mainly rely on virtualization approaches such
as containers or virtual machines, thus requiring a heavier as containers or virtual machines, thus requiring a heavier
processing and memory footprint in a COIN execution environment and processing and memory footprint in a COIN execution environment and
the executing intermediaries. Also, the ETSI work does not allow for the executing intermediaries. Also, the ETSI work does not allow for
the dynamic selection and redirection of (COIN) program calls to the dynamic selection and redirection of COIN program calls to
varying edge resources; it does allow for them to a single MEC varying edge resources; it does allow for them to a single MEC
application server. application server.
Also, the selection of the edge resource (the app server) is Also, the selection of the edge resource (the app server) is
relatively static, relying on DNS-based endpoint selection, which relatively static, relying on DNS-based endpoint selection, which
does not cater to the requirements of the example provided above, does not cater to the requirements of the example provided above,
where the latency for redirecting to another device lies within a few where the latency for redirecting to another device lies within a few
milliseconds for aligning with the frame rate of the display milliseconds for aligning with the frame rate of the display
microservice. microservice.
skipping to change at line 385 skipping to change at line 386
case, some of which have been realized in an Android-based case, some of which have been realized in an Android-based
realization of the microservices as a single application, which is realization of the microservices as a single application, which is
capable of dynamically redirecting traffic to other microservice capable of dynamically redirecting traffic to other microservice
instances in the network. This capability, together with the instances in the network. This capability, together with the
underlying path-based forwarding capability (using SDN), was underlying path-based forwarding capability (using SDN), was
demonstrated publicly (e.g., at the Mobile World Congress 2018 and demonstrated publicly (e.g., at the Mobile World Congress 2018 and
2019). 2019).
3.1.4. Opportunities 3.1.4. Opportunities
* The packaging of (COIN) programs into existing mobile application * The packaging of COIN programs into existing mobile application
packaging may enable the migration from current (mobile) device- packaging may enable the migration from current (mobile) device-
centric execution of those mobile applications toward a possible centric execution of those mobile applications toward a possible
distributed execution of the constituent (COIN) programs that are distributed execution of the constituent COIN programs that are
part of the overall mobile application. part of the overall mobile application.
* The orchestration for deploying (COIN) program instances in * The orchestration for deploying COIN program instances in specific
specific end systems and PNDs alike may open up the possibility end systems and PNDs alike may open up the possibility for
for localized infrastructure owners, such as hotels or venue localized infrastructure owners, such as hotels or venue owners,
owners, to offer their compute capabilities to their visitors for to offer their compute capabilities to their visitors for improved
improved or even site-specific experiences. or even site-specific experiences.
* The execution of (current mobile) app-level (COIN) programs may * The execution of (current mobile) app-level COIN programs may
speed up the execution of said (COIN) program by relocating the speed up the execution of said COIN program by relocating the
execution to more suitable devices, including PNDs that may reside execution to more suitable devices, including PNDs that may reside
better located in relation to other (COIN) programs and thus better located in relation to other COIN programs and thus improve
improve performance, such as latency. performance, such as latency.
* The support for service-level routing of requests (such as service * The support for service-level routing of requests (such as service
routing in [APPCENTRES]) may support higher flexibility when routing in [APPCENTRES]) may support higher flexibility when
switching from one (COIN) program instance to another (e.g., due switching from one COIN program instance to another (e.g., due to
to changing constraints for selecting the new (COIN) program changing constraints for selecting the new COIN program instance).
instance). Here, PNDs may support service routing solutions by Here, PNDs may support service routing solutions by acting as
acting as routing overlay nodes to implement the necessary routing overlay nodes to implement the necessary additional lookup
additional lookup functionality and also possibly support the functionality and also possibly support the handling of affinity
handling of affinity relations (i.e., the forwarding of one packet relations (i.e., the forwarding of one packet to the destination
to the destination of a previous one due to a higher level service of a previous one due to a higher level service relation as
relation as discussed and described in [SarNet2021]). discussed and described in [SarNet2021]).
* The ability to identify service-level COIN elements will allow for * The ability to identify service-level COIN elements will allow for
routing service requests to those COIN elements, including PNDs, routing service requests to those COIN elements, including PNDs,
therefore possibly allowing for a new COIN functionality to be therefore possibly allowing for a new COIN functionality to be
included in the mobile application. included in the mobile application.
* The support for constraint-based selection of a specific (COIN) * The support for constraint-based selection of a specific COIN
program instance over others (e.g., constraint-based routing in program instance over others (e.g., constraint-based routing in
[APPCENTRES], showcased for PNDs in [SarNet2021]) may allow for a [APPCENTRES], showcased for PNDs in [SarNet2021]) may allow for a
more flexible and app-specific selection of (COIN) program more flexible and app-specific selection of COIN program
instances, thereby allowing for better meeting the app-specific instances, thereby allowing for better meeting the app-specific
and end-user requirements. and end-user requirements.
3.1.5. Research Questions 3.1.5. Research Questions
* RQ 3.1.1: How to combine service-level orchestration frameworks, * RQ 3.1.1: How to combine service-level orchestration frameworks,
such as TOSCA orchestration templates [TOSCA], with app-level such as TOSCA orchestration templates [TOSCA], with app-level
(e.g., mobile application) packaging methods, ultimately providing (e.g., mobile application) packaging methods, ultimately providing
the means for packaging microservices for deployments in the means for packaging microservices for deployments in
distributed networked computing environments? distributed networked computing environments?
* RQ 3.1.2: How to reduce latencies involved in (COIN) program * RQ 3.1.2: How to reduce latencies involved in COIN program
interactions where (COIN) program instance locations may change interactions where COIN program instance locations may change
quickly? Can service-level requests be routed directly through quickly? Can service-level requests be routed directly through
in-band signaling methods instead of relying on out-of-band in-band signaling methods instead of relying on out-of-band
discovery, such as through the DNS? discovery, such as through the DNS?
* RQ 3.1.3: How to signal constraints used for routing requests * RQ 3.1.3: How to signal constraints used for routing requests
towards (COIN) program instances in a scalable manner (i.e., for towards COIN program instances in a scalable manner (i.e., for
dynamically choosing the best possible service sequence of one or dynamically choosing the best possible service sequence of one or
more (COIN) programs for a given application experience through more COIN programs for a given application experience through
chaining (COIN) program executions)? chaining COIN program executions)?
* RQ 3.1.4: How to identify (COIN) programs and program instances so * RQ 3.1.4: How to identify COIN programs and program instances so
as to allow routing (service) requests to specific instances of a as to allow routing (service) requests to specific instances of a
given service? given service?
* RQ 3.1.5: How to identify a specific choice of a (COIN) program * RQ 3.1.5: How to identify a specific choice of a COIN program
instance over others, thus allowing pinning the execution of a instance over others, thus allowing pinning the execution of a
service of a specific (COIN) program to a specific resource (i.e., service of a specific COIN program to a specific resource (i.e., a
a (COIN) program instance in the distributed environment)? COIN program instance in the distributed environment)?
* RQ 3.1.6: How to provide affinity of service requests towards * RQ 3.1.6: How to provide affinity of service requests towards COIN
(COIN) program instances (i.e., longer-term transactions with program instances (i.e., longer-term transactions with ephemeral
ephemeral state established at a specific (COIN) program state established at a specific COIN program instance)?
instance)?
* RQ 3.1.7: How to provide constraint-based routing decisions that * RQ 3.1.7: How to provide constraint-based routing decisions that
can be realized at packet forwarding speed (e.g., using techniques can be realized at packet forwarding speed (e.g., using techniques
explored in [SarNet2021] at the forwarding plane or using explored in [SarNet2021] at the forwarding plane or using
approaches like [Multi2020] for extended routing protocols)? approaches like [Multi2020] for extended routing protocols)?
* RQ 3.1.8: What COIN capabilities may support the execution of * RQ 3.1.8: What COIN capabilities may support the execution of COIN
(COIN) programs and their instances? programs and their instances?
* RQ 3.1.9: How to ensure real-time synchronization and consistency * RQ 3.1.9: How to ensure real-time synchronization and consistency
of distributed application states among (COIN) program instances, of distributed application states among COIN program instances, in
in particular, when frequently changing the choice for a particular, when frequently changing the choice for a particular
particular (COIN) program in terms of executing a service COIN program in terms of executing a service instance?
instance?
3.2. Extended Reality and Immersive Media 3.2. Extended Reality and Immersive Media
3.2.1. Description 3.2.1. Description
Extended Reality (XR) encompasses VR, Augmented Reality (AR) and Extended Reality (XR) encompasses VR, Augmented Reality (AR) and
Mixed Reality (MR). It provides the basis for the metaverse and is Mixed Reality (MR). It provides the basis for the metaverse and is
the driver of a number of advances in interactive technologies. the driver of a number of advances in interactive technologies.
While initially associated with gaming and immersive entertainment, While initially associated with gaming and immersive entertainment,
applications now include remote diagnosis, maintenance, telemedicine, applications now include remote diagnosis, maintenance, telemedicine,
skipping to change at line 587 skipping to change at line 586
the purpose of this document, it is important to note that the use of 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 COIN for XR does not imply a specific protocol but targets an
architecture enabling the deployment of the services. In this architecture enabling the deployment of the services. In this
context, similar considerations as for Section 3.1 apply. context, similar considerations as for Section 3.1 apply.
3.2.3. Existing Solutions 3.2.3. Existing Solutions
The XR field has profited from extensive research in the past years The XR field has profited from extensive research in the past years
in gaming, machine learning, network telemetry, high resolution in gaming, machine learning, network telemetry, high resolution
imaging, smart cities, and the Internet of Things (IoT). imaging, smart cities, and the Internet of Things (IoT).
Information-centric networking (and related) approaches that combine, Information-Centric Networking (ICN) (and related) approaches that
publish, subscribe, and distribute storage are also very suited for combine, publish, subscribe, and distribute storage are also very
the multisource-multidestination applications of XR. New AR and VR suited for the multisource-multidestination applications of XR. New
headsets and glasses have continued to evolve towards autonomy with AR and VR headsets and glasses have continued to evolve towards
local computation capabilities, increasingly performing much of the autonomy with local computation capabilities, increasingly performing
processing that is needed to render and augment the local images. much of the processing that is needed to render and augment the local
Mechanisms aimed at enhancing the computational and storage images. Mechanisms aimed at enhancing the computational and storage
capacities of mobile devices could also improve XR capabilities as capacities of mobile devices could also improve XR capabilities as
they include the discovery of available servers within the they include the discovery of available servers within the
environment and using them opportunistically to enhance the environment and using them opportunistically to enhance the
performance of interactive applications and distributed file systems. performance of interactive applications and distributed file systems.
While there is still no specific COIN research in AR and VR, the need 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 for network support is important to offload some of the computations
related to movement, multiuser interactions, and networked related to movement, multiuser interactions, and networked
applications, notably in gaming but also in health [NetworkedVR]. applications, notably in gaming but also in health [NetworkedVR].
This new approach to networked AR and VR is exemplified in [eCAR] by This new approach to networked AR and VR is exemplified in [eCAR] by
skipping to change at line 732 skipping to change at line 731
performers receive live feedback from the audience, which may also be performers receive live feedback from the audience, which may also be
conveyed to other audience members. conveyed to other audience members.
There are two main aspects: There are two main aspects:
i. to emulate as closely as possible the experience of live i. to emulate as closely as possible the experience of live
performances where the performers, audience, director, and performances where the performers, audience, director, and
technicians are co-located in the same physical space, such as a technicians are co-located in the same physical space, such as a
theater; and theater; and
ii. to enhance traditional physical performances with features such ii. to enhance conventional physical performances with features such
as personalization of the experience according to the as personalization of the experience according to the
preferences or needs of the performers, directors, and audience preferences or needs of the performers, directors, and audience
members. members.
Examples of personalization include: Examples of personalization include:
* Viewpoint selection, such as choosing a specific seat in the * Viewpoint selection, such as choosing a specific seat in the
theater or for more advanced positioning of the audience member's theater or for more advanced positioning of the audience member's
viewpoint outside of the traditional seating (i.e., amongst, viewpoint outside of the conventional seating (i.e., amongst,
above, or behind the performers, but within some limits that may above, or behind the performers, but within some limits that may
be imposed by the performers or the director for artistic be imposed by the performers or the director for artistic
reasons); reasons);
* Augmentation of the performance with subtitles, audio description, * Augmentation of the performance with subtitles, audio description,
actor tagging, language translation, advertisements and product actor tagging, language translation, advertisements and product
placement, and other enhancements and filters to make the placement, and other enhancements and filters to make the
performance accessible to audience members who are disabled (e.g., performance accessible to audience members who are disabled (e.g.,
the removal of flashing images for audience members who have the removal of flashing images for audience members who have
epilepsy or alternative color schemes for those who have color epilepsy or alternative color schemes for those who have color
blindness). blindness).
3.3.2. Characterization 3.3.2. Characterization
There are several chained functional entities that are candidates for There are several chained functional entities that are candidates for
being deployed as (COIN) programs: being deployed as COIN programs:
* Performer aggregation and editing functions * Performer aggregation and editing functions
* Distribution and encoding functions * Distribution and encoding functions
* Personalization functions * Personalization functions
- to select which of the existing streams should be forwarded to - to select which of the existing streams should be forwarded to
the audience member, remote performer, or member of the the audience member, remote performer, or member of the
production team production team
skipping to change at line 788 skipping to change at line 787
audience head position) when this processing has been offloaded audience head position) when this processing has been offloaded
from the viewer's end system to the COIN function due to from the viewer's end system to the COIN function due to
limited processing power in the end system or due to limited limited processing power in the end system or due to limited
network bandwidth to receive all of the individual streams to network bandwidth to receive all of the individual streams to
be processed. be processed.
* Audience feedback sensor processing functions * Audience feedback sensor processing functions
* Audience feedback aggregation functions * Audience feedback aggregation functions
These are candidates for deployment as (COIN) programs in PNDs rather These are candidates for deployment as COIN programs in PNDs rather
than being located in end systems (at the performers' site, the than being located in end systems (at the performers' site, the
audience members' premises, or in a central cloud location) for audience members' premises, or in a central cloud location) for
several reasons: several reasons:
* Personalization of the performance according to viewer preferences * Personalization of the performance according to viewer preferences
and requirements makes it infeasible to be done in a centralized and requirements makes it infeasible to be done in a centralized
manner at the performer premises: the computational resources and manner at the performer premises: the computational resources and
network bandwidth would need to scale with the number of network bandwidth would need to scale with the number of
personalized streams. personalized streams.
skipping to change at line 823 skipping to change at line 822
processing capabilities at centralized data centers. processing capabilities at centralized data centers.
3.3.3. Existing Solutions 3.3.3. Existing Solutions
Note: Existing solutions for some aspects of this use case are Note: Existing solutions for some aspects of this use case are
covered in Section 3.1, Section 3.2, and Section 5.1. covered in Section 3.1, Section 3.2, and Section 5.1.
3.3.4. Opportunities 3.3.4. Opportunities
* Executing media processing and personalization functions on-path * Executing media processing and personalization functions on-path
as (COIN) programs in PNDs can avoid detour/stretch to central as COIN programs in PNDs can avoid detour/stretch to central
servers, thus reducing latency and bandwidth consumption. For servers, thus reducing latency and bandwidth consumption. For
example, the overall delay for performance capture, aggregation, example, the overall delay for performance capture, aggregation,
distribution, personalization, consumption, capture of audience distribution, personalization, consumption, capture of audience
response, feedback processing, aggregation, and rendering should response, feedback processing, aggregation, and rendering should
be achieved within an upper bound of latency (the tolerable amount be achieved within an upper bound of latency (the tolerable amount
is to be defined, but in the order of 100s of ms to mimic is to be defined, but in the order of 100s of ms to mimic
performers perceiving audience feedback, such as laughter or other performers perceiving audience feedback, such as laughter or other
emotional responses in a theater setting). emotional responses in a theater setting).
* Processing of media streams allows (COIN) programs, PNDs, and the * Processing of media streams allows COIN programs, PNDs, and the
wider (COIN) system/environment to be contextually aware of flows wider COIN system/environment to be contextually aware of flows
and their requirements, which can be used for determining network and their requirements, which can be used for determining network
treatment of the flows (e.g., path selection, prioritization, treatment of the flows (e.g., path selection, prioritization,
multiflow coordination, synchronization, and resilience). multiflow coordination, synchronization, and resilience).
3.3.5. Research Questions 3.3.5. Research Questions
* RQ 3.3.1: In which PNDs should (COIN) programs for aggregation, * RQ 3.3.1: In which PNDs should COIN programs for aggregation,
encoding, and personalization functions be located? Close to the encoding, and personalization functions be located? Close to the
performers or close to the viewers? performers or close to the viewers?
* RQ 3.3.2: How far from the direct network path from performer to * RQ 3.3.2: How far from the direct network path from performer to
viewer should (COIN) programs be located, considering the latency viewer should COIN programs be located, considering the latency
implications of path-stretch and the availability of processing implications of path-stretch and the availability of processing
capacity at PNDs? How should tolerances be defined by users? capacity at PNDs? How should tolerances be defined by users?
* RQ 3.3.3: Should users decide which PNDs should be used for * RQ 3.3.3: Should users decide which PNDs should be used for
executing (COIN) programs for their flows, or should they express executing COIN programs for their flows, or should they express
requirements and constraints that will direct decisions by the requirements and constraints that will direct decisions by the
orchestrator/manager of a COIN system? In case of the latter, how orchestrator/manager of a COIN system? In case of the latter, how
can users specify requirements on network and processing metrics can users specify requirements on network and processing metrics
(such as latency and throughput bounds)? (such as latency and throughput bounds)?
* RQ 3.3.4: How to achieve synchronization across multiple streams * RQ 3.3.4: How to achieve synchronization across multiple streams
to allow for merging, audio-video interpolation, and other cross- to allow for merging, audio-video interpolation, and other cross-
stream processing functions that require time synchronization for stream processing functions that require time synchronization for
the integrity of the output? How can this be achieved considering the integrity of the output? How can this be achieved considering
that synchronization may be required between flows that are: that synchronization may be required between flows that are:
skipping to change at line 881 skipping to change at line 880
This RQ raises issues associated with synchronization across This RQ raises issues associated with synchronization across
multiple media streams and substreams [RFC7272] as well as time multiple media streams and substreams [RFC7272] as well as time
synchronization between PNDs/routers on multiple paths [RFC8039]. synchronization between PNDs/routers on multiple paths [RFC8039].
* RQ 3.3.5: Where will COIN programs be executed? In the data plane * RQ 3.3.5: Where will COIN programs be executed? In the data plane
of PNDs, in other on-router computational capabilities within of PNDs, in other on-router computational capabilities within
PNDs, or in adjacent computational nodes? PNDs, or in adjacent computational nodes?
* RQ 3.3.6: Are computationally intensive tasks, such as video * RQ 3.3.6: Are computationally intensive tasks, such as video
stitching or media recognition and annotation (cf. Section 3.2), stitching or media recognition and annotation (cf. Section 3.2),
considered as suitable candidate (COIN) programs or should they be considered as suitable candidate COIN programs or should they be
implemented in end systems? implemented in end systems?
* RQ 3.3.7: If the execution of COIN programs is offloaded to * RQ 3.3.7: If the execution of COIN programs is offloaded to
computational nodes outside of PNDs (e.g., for processing by computational nodes outside of PNDs (e.g., for processing by
GPUs), should this still be considered as COIN? Where is the GPUs), should this still be considered as COIN? Where is the
boundary between COIN capabilities and explicit routing of flows boundary between COIN capabilities and explicit routing of flows
to end systems? to end systems?
3.3.6. Additional Desirable Capabilities 3.3.6. Additional Desirable Capabilities
In addition to the capabilities driven by the research questions In addition to the capabilities driven by the research questions
above, there are a number of other features that solutions in this above, there are a number of other features that solutions in this
space might benefit from. In particular, if users are indeed space might benefit from. In particular, if users are indeed
empowered to specify requirements on network and processing metrics, empowered to specify requirements on network and processing metrics,
one important capability of COIN systems will be to respect these one important capability of COIN systems will be to respect these
user-specified requirements and constraints when routing flows and user-specified requirements and constraints when routing flows and
selecting PNDs for executing (COIN) programs. Similarly, solutions selecting PNDs for executing COIN programs. Similarly, solutions
should be able to synchronize flow treatment and processing across should be able to synchronize flow treatment and processing across
multiple related flows, which may be on disjoint paths, to provide multiple related flows, which may be on disjoint paths, to provide
similar performance to different entities. similar performance to different entities.
4. Supporting New COIN Systems 4. Supporting New COIN Systems
4.1. In-Network Control / Time-Sensitive Applications 4.1. In-Network Control / Time-Sensitive Applications
4.1.1. Description 4.1.1. Description
The control of physical processes and components of industrial The control of physical processes and components of industrial
production lines is essential for the growing automation of production lines is essential for the growing automation of
production and ideally allows for a consistent quality level. production and ideally allows for a consistent quality level.
Traditionally, the control has been exercised by control software Commonly, the control has been exercised by control software running
running on Programmable Logic Controllers (PLCs) located directly on Programmable Logic Controllers (PLCs) located directly next to the
next to the controlled process or component. This approach is best controlled process or component. This approach is best suited for
suited for settings with a simple model that is focused on a single settings with a simple model that is focused on a single or a few
or a few controlled components. controlled components.
Modern production lines and shop floors are characterized by an Modern production lines and shop floors are characterized by an
increasing number of involved devices and sensors, a growing level of increasing number of involved devices and sensors, a growing level of
dependency between the different components, and more complex control dependency between the different components, and more complex control
models. A centralized control is desirable to manage the large models. A centralized control is desirable to manage the large
amount of available information, which often has to be preprocessed amount of available information, which often has to be preprocessed
or aggregated with other information before it can be used. As a or aggregated with other information before it can be used. As a
result, computations are increasingly spatially decoupled and moved result, computations are increasingly spatially decoupled and moved
away from the controlled objects, thus inducing additional latency. away from the controlled objects, thus inducing additional latency.
Instead, moving compute functionality onto COIN execution Instead, moving compute functionality onto COIN execution
skipping to change at line 968 skipping to change at line 967
latencies are essential, there is an even greater need for stable and latencies are essential, there is an even greater need for stable and
deterministic levels of latency, because controllers can generally deterministic levels of latency, because controllers can generally
cope with different levels of latency if they are designed for them, cope with different levels of latency if they are designed for them,
but they are significantly challenged by dynamically changing or but they are significantly challenged by dynamically changing or
unstable latencies. The unpredictable latency of the Internet unstable latencies. The unpredictable latency of the Internet
exemplifies this problem if, for example, off-premise cloud platforms exemplifies this problem if, for example, off-premise cloud platforms
are included. are included.
4.1.3. Existing Solutions 4.1.3. Existing Solutions
Control functionality is traditionally executed on PLCs close to the Control functionality is commonly executed on PLCs close to the
machinery. These PLCs typically require vendor-specific machinery. These PLCs typically require vendor-specific
implementations and are often hard to upgrade and update, which makes implementations and are often hard to upgrade and update, which makes
such control processes inflexible and difficult to manage. Moving such control processes inflexible and difficult to manage. Moving
computations to more freely programmable devices thus has the computations to more freely programmable devices thus has the
potential of significantly improving the flexibility. In this potential of significantly improving the flexibility. In this
context, directly moving control functionality to (central) cloud context, directly moving control functionality to (central) cloud
environments is generally possible, yet only feasible if latency environments is generally possible, yet only feasible if latency
constraints are lenient. constraints are lenient.
Early approaches such as [RÜTH] and [VESTIN] have already shown the Early approaches such as [RÜTH] and [VESTIN] have already shown the
skipping to change at line 1199 skipping to change at line 1198
the performance of any approach developed based on the above research the performance of any approach developed based on the above research
questions. questions.
4.3. Industrial Safety 4.3. Industrial Safety
4.3.1. Description 4.3.1. Description
Despite an increasing automation in production processes, human Despite an increasing automation in production processes, human
workers are still often necessary. Consequently, safety measures workers are still often necessary. Consequently, safety measures
have a high priority to ensure that no human life is endangered. In have a high priority to ensure that no human life is endangered. In
traditional factories, the regions of contact between humans and conventional factories, the regions of contact between humans and
machines are well defined and interactions are simple. Simple safety machines are well defined and interactions are simple. Simple safety
measures like emergency switches at the working positions are enough measures like emergency switches at the working positions are enough
to provide a good level of safety. to provide a good level of safety.
Modern factories are characterized by increasingly dynamic and Modern factories are characterized by increasingly dynamic and
complex environments with new interaction scenarios between humans complex environments with new interaction scenarios between humans
and robots. Robots can directly assist humans, perform tasks and robots. Robots can directly assist humans, perform tasks
autonomously, or even freely move around on the shop floor. Hence, autonomously, or even freely move around on the shop floor. Hence,
the intersect between the human working area and the robots grows, the intersect between the human working area and the robots grows,
and it is harder for human workers to fully observe the complete and it is harder for human workers to fully observe the complete
skipping to change at line 1293 skipping to change at line 1292
Delivery of content to end users often relies on Content Delivery Delivery of content to end users often relies on Content Delivery
Networks (CDNs). CDNs store said content closer to end users for Networks (CDNs). CDNs store said content closer to end users for
latency-reduced delivery as well as to reduce load on origin servers. latency-reduced delivery as well as to reduce load on origin servers.
For this, they often utilize DNS-based indirection to serve the For this, they often utilize DNS-based indirection to serve the
request on behalf of the origin server. Both of these objectives are request on behalf of the origin server. Both of these objectives are
within scope to be addressed by COIN methods and solutions. within scope to be addressed by COIN methods and solutions.
5.1.2. Characterization 5.1.2. Characterization
From the perspective of this draft, a CDN can be interpreted as a From the perspective of this draft, a CDN can be interpreted as a
(network service level) set of (COIN) programs. These programs (network service level) set of COIN programs. These programs
implement a distributed logic for first distributing content from the implement a distributed logic for first distributing content from the
origin server to the CDN ingress and then further to the CDN origin server to the CDN ingress and then further to the CDN
replication points, which ultimately serve the user-facing content replication points, which ultimately serve the user-facing content
requests. requests.
5.1.3. Existing Solutions 5.1.3. Existing Solutions
CDN technologies have been well described and deployed in the CDN technologies have been well described and deployed in the
existing Internet. Core technologies like Global Server Load existing Internet. Core technologies like Global Server Load
Balancing (GSLB) [GSLB] and Anycast server solutions are used to deal Balancing (GSLB) [GSLB] and Anycast server solutions are used to deal
skipping to change at line 1324 skipping to change at line 1323
Studies such as those in [FCDN] have shown that content distribution Studies such as those in [FCDN] have shown that content distribution
at the level of named content, utilizing efficient (e.g., Layer 2 at the level of named content, utilizing efficient (e.g., Layer 2
(L2)) multicast for replication towards edge CDN nodes, can (L2)) multicast for replication towards edge CDN nodes, can
significantly increase the overall network and server efficiency. It significantly increase the overall network and server efficiency. It
also reduces indirection latency for content retrieval as well as also reduces indirection latency for content retrieval as well as
required edge storage capacity by benefiting from the increased required edge storage capacity by benefiting from the increased
network efficiency to renew edge content more quickly against network efficiency to renew edge content more quickly against
changing demand. Works such as those in [SILKROAD] utilize changing demand. Works such as those in [SILKROAD] utilize
Application-Specific Integrated Circuits (ASICs) to replace server- Application-Specific Integrated Circuits (ASICs) to replace server-
based load balancing with significant cost reductions, thus based load balancing with significant cost reductions, thus
showcasing the potential for in-network CN operations. showcasing the potential for in-network operations.
5.1.4. Opportunities 5.1.4. Opportunities
* Supporting service-level routing of requests (such as service * Supporting service-level routing of requests (such as service
routing in [APPCENTRES]) to specific (COIN) program instances may routing in [APPCENTRES]) to specific COIN program instances may
improve on end-user experience in retrieving faster (and possibly improve on end-user experience in retrieving faster (and possibly
better quality) content. better quality) content.
* COIN instances may also be utilized to integrate service-related * COIN instances may also be utilized to integrate service-related
telemetry information to support the selection of the final telemetry information to support the selection of the final
service instance destination from a pool of possible choices. service instance destination from a pool of possible choices.
* Supporting the selection of a service destination from a set of * Supporting the selection of a service destination from a set of
possible choices (virtualized and distributed) in (COIN) program possible choices (virtualized and distributed) in COIN program
instances (e.g., through constraint-based routing decisions as instances (e.g., through constraint-based routing decisions as
seen in [APPCENTRES]) to improve the overall end-user experience seen in [APPCENTRES]) to improve the overall end-user experience
by selecting a "more suitable" service destination over another by selecting a "more suitable" service destination over another
(e.g., avoiding/reducing overload situations in specific service (e.g., avoiding/reducing overload situations in specific service
destinations). destinations).
* Supporting L2 capabilities for multicast (compute interconnection * Supporting L2 capabilities for multicast (compute interconnection
and collective communication as seen in [APPCENTRES]) may reduce and collective communication as seen in [APPCENTRES]) may reduce
the network utilization and therefore increase the overall system the network utilization and therefore increase the overall system
efficiency. For example, this support may be through in-network, efficiency. For example, this support may be through in-network,
skipping to change at line 1367 skipping to change at line 1366
How to utilize COIN capabilities in those designs, such as through How to utilize COIN capabilities in those designs, such as through
on-path optimizations for fanouts? on-path optimizations for fanouts?
* RQ 5.1.2: What forwarding methods may support the required * RQ 5.1.2: What forwarding methods may support the required
multicast capabilities (see [FCDN]) and how could programmable multicast capabilities (see [FCDN]) and how could programmable
COIN forwarding elements support those methods (e.g., extending COIN forwarding elements support those methods (e.g., extending
current SDN capabilities)? current SDN capabilities)?
* RQ 5.1.3: What are the constraints, reflecting both compute and * RQ 5.1.3: What are the constraints, reflecting both compute and
network capabilities, that may support joint optimization of network capabilities, that may support joint optimization of
routing and computing? How could intermediary (COIN) program routing and computing? How could intermediary COIN program
instances support, for example, the aggregation of those instances support, for example, the aggregation of those
constraints to reduce overall telemetry network traffic? constraints to reduce overall telemetry network traffic?
* RQ 5.1.4: Could traffic steering be performed on the data path and * RQ 5.1.4: Could traffic steering be performed on the data path and
per service request (e.g., through (COIN) program instances that per service request (e.g., through COIN program instances that
perform novel routing request lookup methods)? If so, what would perform novel routing request lookup methods)? If so, what would
be performance improvements? be performance improvements?
* RQ 5.1.5: How could storage be traded off against frequent, * RQ 5.1.5: How could storage be traded off against frequent,
multicast-based replication (see [FCDN])? Could intermediary/in- multicast-based replication (see [FCDN])? Could intermediary/in-
network (COIN) elements support the storage beyond current network COIN elements support the storage beyond current endpoint-
endpoint-based methods? based methods?
* RQ 5.1.6: What scalability limits exist for L2 multicast * RQ 5.1.6: What scalability limits exist for L2 multicast
capabilities? How to overcome them, e.g., through (COIN) program capabilities? How to overcome them, e.g., through COIN program
instances serving as stateful subtree aggregators to reduce the instances serving as stateful subtree aggregators to reduce the
needed identifier space (e.g., for bit-based forwarding)? needed identifier space (e.g., for bit-based forwarding)?
5.2. Compute-Fabric-as-a-Service (CFaaS) 5.2. Compute-Fabric-as-a-Service (CFaaS)
5.2.1. Description 5.2.1. Description
We interpret connected compute resources as operating at a suitable We interpret connected compute resources as operating at a suitable
layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3), to layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3), to
allow for the exchange of suitable invocation methods, such as those allow for the exchange of suitable invocation methods, such as those
exposed through verb-based or socket-based APIs. The specific exposed through verb-based or socket-based APIs. The specific
invocations here are subject to the applications running over a invocations here are subject to the applications running over a
selected pool of such connected compute resources. selected pool of such connected compute resources.
Providing such a pool of connected compute resources (e.g., in Providing such a pool of connected compute resources (e.g., in
regional or edge data centers, base stations, and even end-user regional or edge data centers, base stations, and even end-user
devices) opens up the opportunity for infrastructure providers to devices) opens up the opportunity for infrastructure providers to
offer CFaaS-like offerings to application providers, leaving the offer CFaaS-like offerings to application providers, leaving the
choice of the appropriate invocation method to the app and service choice of the appropriate invocation method to the app and service
provider. Through this, the compute resources can be utilized to provider. Through this, the compute resources can be utilized to
execute the desired (COIN) programs of which the application is execute the desired COIN programs of which the application is
composed, while utilizing the interconnection between those compute composed, while utilizing the interconnection between those compute
resources to do so in a distributed manner. resources to do so in a distributed manner.
5.2.2. Characterization 5.2.2. Characterization
We foresee those CFaaS offerings to be tenant-specific, with a tenant We foresee those CFaaS offerings to be tenant-specific, with a tenant
here defined as the provider of at least one application. For this, here defined as the provider of at least one application. For this,
we foresee an interaction between the CFaaS provider and tenant to we foresee an interaction between the CFaaS provider and tenant to
dynamically select the appropriate resources to define the demand dynamically select the appropriate resources to define the demand
side of the fabric. Conversely, we also foresee the supply side of side of the fabric. Conversely, we also foresee the supply side of
skipping to change at line 1437 skipping to change at line 1436
5.2.3. Existing Solutions 5.2.3. Existing Solutions
There exist a number of technologies to build non-local (wide area) There exist a number of technologies to build non-local (wide area)
L2 as well as L3 networks, which in turn allows for connecting L2 as well as L3 networks, which in turn allows for connecting
compute resources for a distributed computational task. For compute resources for a distributed computational task. For
instance, 5G-LAN [SA2-5GLAN] specifies a cellular L2 bearer for instance, 5G-LAN [SA2-5GLAN] specifies a cellular L2 bearer for
interconnecting L2 resources within a single cellular operator. The interconnecting L2 resources within a single cellular operator. The
work in [ICN-5GLAN] outlines using a path-based forwarding solution work in [ICN-5GLAN] outlines using a path-based forwarding solution
over 5G-LAN as well as SDN-based LAN connectivity together with an over 5G-LAN as well as SDN-based LAN connectivity together with an
Information-Centric Network (ICN) based naming of IP and HTTP-level ICN-based naming of IP and HTTP-level resources. This is done in
resources. This is done in order to achieve computational order to achieve computational interconnections, including scenarios
interconnections, including scenarios such as those outlined in such as those outlined in Section 3.1. L2 network virtualization
Section 3.1. L2 network virtualization (see [L2Virt]) is one of the (see [L2Virt]) is one of the methods used for realizing so-called
methods used for realizing so-called "cloud-native" applications for "cloud-based" applications for applications developed with "physical"
applications developed with "physical" networks in mind, thus forming networks in mind, thus forming an interconnected compute and storage
an interconnected compute and storage fabric. fabric.
5.2.4. Opportunities 5.2.4. Opportunities
* Supporting service-level routing of compute resource requests * Supporting service-level routing of compute resource requests
(such as service routing in [APPCENTRES]) may allow for utilizing (such as service routing in [APPCENTRES]) may allow for utilizing
the wealth of compute resources in the overall CFaaS fabric for the wealth of compute resources in the overall CFaaS fabric for
execution of distributed applications, where the distributed execution of distributed applications, where the distributed
constituents of those applications are realized as (COIN) programs constituents of those applications are realized as COIN programs
and executed within a COIN system as (COIN) program instances. and executed within a COIN system as COIN program instances.
* Supporting the constraint-based selection of a specific (COIN) * Supporting the constraint-based selection of a specific COIN
program instance over others (such as constraint-based routing in program instance over others (such as constraint-based routing in
[APPCENTRES]) will allow for optimizing both the CFaaS provider [APPCENTRES]) will allow for optimizing both the CFaaS provider
constraints as well as tenant-specific constraints. constraints as well as tenant-specific constraints.
* Supporting L2 and L3 capabilities for multicast (such as compute * Supporting L2 and L3 capabilities for multicast (such as compute
interconnection and collective communication in [APPCENTRES]) will interconnection and collective communication in [APPCENTRES]) will
allow for decreasing both network utilization but also possible allow for decreasing both network utilization but also possible
compute utilization (due to avoiding unicast replication at those compute utilization (due to avoiding unicast replication at those
compute endpoints), thereby decreasing total cost of ownership for compute endpoints), thereby decreasing total cost of ownership for
the CFaaS offering. the CFaaS offering.
* Supporting intermediary (COIN) program instances to allow for the * Supporting intermediary COIN program instances to allow for the
enforcement of trust relationships and isolation policies (e.g., enforcement of trust relationships and isolation policies (e.g.,
enforcing specific traffic shares or strict isolation of traffic enforcing specific traffic shares or strict isolation of traffic
through differentiated queueing). through differentiated queueing).
5.2.5. Research Questions 5.2.5. Research Questions
In addition to the research questions in Section 3.1.5: In addition to the research questions in Section 3.1.5:
* RQ 5.2.1: How to convey tenant-specific requirements for the * RQ 5.2.1: How to convey tenant-specific requirements for the
creation of the CFaaS fabric? creation of the CFaaS fabric?
* RQ 5.2.2: How to dynamically integrate resources into the compute * RQ 5.2.2: How to dynamically integrate resources into the compute
fabric being utilized for the app execution (those resources fabric being utilized for the app execution (those resources
include, but are not limited to, end-user provided resources), include, but are not limited to, end-user provided resources),
particularly when driven by tenant-level requirements and changing particularly when driven by tenant-level requirements and changing
service-specific constraints? How can those resources be exposed service-specific constraints? How can those resources be exposed
through possible (COIN) execution environments? through possible COIN execution environments?
* RQ 5.2.3: How to utilize COIN capabilities to aid the availability * RQ 5.2.3: How to utilize COIN capabilities to aid the availability
and accountability of resources, i.e., what may be (COIN) programs and accountability of resources, i.e., what may be COIN programs
for a CFaaS environment that in turn would utilize the distributed for a CFaaS environment that in turn would utilize the distributed
execution capability of a COIN system? execution capability of a COIN system?
* RQ 5.2.4: How to utilize COIN capabilities to enforce traffic and * RQ 5.2.4: How to utilize COIN capabilities to enforce traffic and
isolation policies for establishing trust between tenant and CFaaS isolation policies for establishing trust between tenant and CFaaS
provider in an assured operation? provider in an assured operation?
* RQ 5.2.5: How to optimize the interconnection of compute * RQ 5.2.5: How to optimize the interconnection of compute
resources, including those dynamically added and removed during resources, including those dynamically added and removed during
the provisioning of the tenant-specific compute fabric? the provisioning of the tenant-specific compute fabric?
skipping to change at line 1673 skipping to change at line 1672
6.1.1. Description 6.1.1. Description
There is a growing range of use cases demanding the realization of AI There is a growing range of use cases demanding the realization of AI
training capabilities among distributed endpoints. One such use case training capabilities among distributed endpoints. One such use case
is to distribute large-scale model training across more than one data 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 center (e.g., when facing energy issues at a single site or when
simply reaching the scale of training capabilities at one site, thus simply reaching the scale of training capabilities at one site, thus
wanting to complement training with the capabilities of another or wanting to complement training with the capabilities of another or
possibly many sites). From a COIN perspective, those capabilities possibly many sites). From a COIN perspective, those capabilities
may be realized as (COIN) programs and executed throughout a COIN may be realized as COIN programs and executed throughout a COIN
system, including in PNDs. system, including in PNDs.
6.1.2. Characterization 6.1.2. Characterization
Some solutions may desire the localization of reasoning logic (e.g., Some solutions may desire the localization of reasoning logic (e.g.,
for deriving attributes that better preserve privacy of the utilized for deriving attributes that better preserve privacy of the utilized
raw input data). Quickly establishing (COIN) program instances in raw input data). Quickly establishing COIN program instances in
nearby compute resources, including PNDs, may even satisfy such nearby compute resources, including PNDs, may even satisfy such
localization demands on the fly (e.g., when a particular use is being localization demands on the fly (e.g., when a particular use is being
realized, then terminated after a given time). realized, then terminated after a given time).
Individual training "sites" may not be a data center, but may instead Individual training "sites" may not be a data center, but may instead
consist of powerful, yet stand-along devices that federate computing consist of powerful, yet stand-along devices that federate computing
power towards training a model, captured as "federated training" and power towards training a model, captured as "federated training" and
provided through platforms such as [FLOWER]. Use cases here may be provided through platforms such as [FLOWER]. Use cases here may be
that of distributed training on (user) image data, the training over that of distributed training on (user) image data, the training over
federated social media sites [MASTODON], or others. federated social media sites [MASTODON], or others.
skipping to change at line 1716 skipping to change at line 1715
A number of activities on distributed AI training exist in the area A number of activities on distributed AI training exist in the area
of developing the 5th and 6th generation mobile network, with various of developing the 5th and 6th generation mobile network, with various
activities in the 3GPP Standards Development Organization (SDO) as activities in the 3GPP Standards Development Organization (SDO) as
well as use cases developed for the ETSI MEC initiative mentioned in well as use cases developed for the ETSI MEC initiative mentioned in
previous use cases. previous use cases.
6.1.4. Opportunities 6.1.4. Opportunities
* Supporting service-level routing of training requests (such as * Supporting service-level routing of training requests (such as
service routing in [APPCENTRES]) with AI services being exposed to service routing in [APPCENTRES]) with AI services being exposed to
the network, and where (COIN) program instances may support the the network, and where COIN program instances may support the
selection of the most suitable service instance based on control selection of the most suitable service instance based on control
plane information (e.g., on AI worker compute capabilities being plane information (e.g., on AI worker compute capabilities being
distributed across (COIN) program instances). distributed across COIN program instances).
* Supporting the collective communication primitives, such as all- * Supporting the collective communication primitives, such as all-
to-all and scatter-gather, utilized by the (distributed) AI to-all and scatter-gather, utilized by the (distributed) AI
workers may increase the overall network efficiency (e.g., through workers may increase the overall network efficiency (e.g., through
avoiding endpoint-based replication or even directly performing avoiding endpoint-based replication or even directly performing
collective primitive operations in (COIN) program instances placed collective primitive operations in COIN program instances placed
in topologically advantageous places). in topologically advantageous places).
* Supporting collective communication between multiple instances of * Supporting collective communication between multiple instances of
AI services (i.e., (COIN) program instances) may positively impact AI services (i.e., COIN program instances) may positively impact
network but also compute utilization by moving from unicast network but also compute utilization by moving from unicast
replication to network-assisted multicast operation. replication to network-assisted multicast operation.
6.1.5. Research Questions 6.1.5. Research Questions
In addition to the research questions in Section 3.1.5: In addition to the research questions in Section 3.1.5:
* RQ 6.1.1: What are the communication patterns that may be * RQ 6.1.1: What are the communication patterns that may be
supported by collective communication solutions, where those supported by collective communication solutions, where those
solutions directly utilize (COIN) program instance capabilities solutions directly utilize COIN program instance capabilities
within the network (e.g., perform Reduce options in a central within the network (e.g., perform Reduce options in a central COIN
(COIN) program instance)? program instance)?
* RQ 6.1.2: How to achieve scalable collective communication * RQ 6.1.2: How to achieve scalable collective communication
primitives with rapidly changing receiver sets (e.g., where primitives with rapidly changing receiver sets (e.g., where
training workers may be dynamically selected based on energy training workers may be dynamically selected based on energy
efficiency constraints [GREENAI])? efficiency constraints [GREENAI])?
* RQ 6.1.3: What COIN capabilities may support the collective * RQ 6.1.3: What COIN capabilities may support the collective
communication patterns found in distributed AI problems? communication patterns found in distributed AI problems?
* RQ 6.1.4: How to support AI-specific invocation protocols, such as * RQ 6.1.4: How to support AI-specific invocation protocols, such as
MPI or Remote Direct Memory Access (RDMA)? MPI or Remote Direct Memory Access (RDMA)?
* RQ 6.1.5: What are the constraints for placing (AI) execution * RQ 6.1.5: What are the constraints for placing (AI) execution
logic in the form of (COIN) programs in certain logical execution logic in the form of COIN programs in certain logical execution
points (and their associated physical locations), including PNDs, points (and their associated physical locations), including PNDs,
and how to signal and act upon them? and how to signal and act upon them?
7. Preliminary Categorization of the Research Questions 7. Preliminary Categorization of the Research Questions
This section describes a preliminary categorization of the research This section describes a preliminary categorization of the research
questions illustrated in Figure 4. A more comprehensive analysis has questions illustrated in Figure 4. A more comprehensive analysis has
been initiated by members of the COINRG community in [USE-CASE-AN] been initiated by members of the COINRG community in [USE-CASE-AN]
but has not been completed at the time of writing this memo. but has not been completed at the time of writing this memo.
skipping to change at line 1799 skipping to change at line 1798
category, these research questions look at the problem from a more category, these research questions look at the problem from a more
philosophical perspective. In particular, the questions center philosophical perspective. In particular, the questions center
around where to perform computations, which tasks are suitable for around where to perform computations, which tasks are suitable for
COIN, for which tasks COIN is suitable, and which forms of deploying COIN, for which tasks COIN is suitable, and which forms of deploying
COIN might be desirable. This category includes the research COIN might be desirable. This category includes the research
questions 3.1.8, 3.2.1, 3.3.5, 3.3.6, 3.3.7, 5.3.3, 6.1.1, and 6.1.3. questions 3.1.8, 3.2.1, 3.3.5, 3.3.6, 3.3.7, 5.3.3, 6.1.1, and 6.1.3.
The "Enabling Technologies for COIN" category digs into what The "Enabling Technologies for COIN" category digs into what
technologies are needed to enable COIN, which of the existing technologies are needed to enable COIN, which of the existing
technologies can be reused for COIN, and what might be needed to make technologies can be reused for COIN, and what might be needed to make
the "Visions(s) for COIN" a reality. In contrast to the "Vision(s) the "Vision(s) for COIN" a reality. In contrast to the "Vision(s)
for COIN", these research questions look at the problem from a for COIN", these research questions look at the problem from a
practical perspective (e.g., by considering how COIN can be practical perspective (e.g., by considering how COIN can be
incorporated in existing systems or how the interoperability of COIN incorporated in existing systems or how the interoperability of COIN
execution environments can be enhanced). This category includes the execution environments can be enhanced). This category includes the
research questions 3.1.7, 3.1.8, 3.2.3, 4.2.7, 5.1.1, 5.1.2, 5.1.6, research questions 3.1.7, 3.1.8, 3.2.3, 4.2.7, 5.1.1, 5.1.2, 5.1.6,
5.3.1, 6.1.2, and 6.1.3. 5.3.1, 6.1.2, and 6.1.3.
The "Distributed Computing Frameworks and Languages to COIN" category The "Distributed Computing Frameworks and Languages to COIN" category
focuses on how COIN programs can be deployed and orchestrated. focuses on how COIN programs can be deployed and orchestrated.
Central questions arise regarding the composition of COIN programs, Central questions arise regarding the composition of COIN programs,
skipping to change at line 1921 skipping to change at line 1920
responsible for large-scale outages. In particular, some deployments responsible for large-scale outages. In particular, some deployments
could be used to amplify DoS attacks. Similar to other middlebox could be used to amplify DoS attacks. Similar to other middlebox
deployments, these potential risks must be considered when deploying deployments, these potential risks must be considered when deploying
COIN functionality and may influence the selection of suitable COIN functionality and may influence the selection of suitable
security protocols. security protocols.
Additional system-level security considerations may arise from Additional system-level security considerations may arise from
regulatory requirements imposed on COIN systems overall, stemming regulatory requirements imposed on COIN systems overall, stemming
from regulation regarding lawful interception, data localization, or from regulation regarding lawful interception, data localization, or
AI use, for example. These requirements may impact, for example, the AI use, for example. These requirements may impact, for example, the
manner in which (COIN) programs may be placed or executed in the manner in which COIN programs may be placed or executed in the
overall system, who can invoke certain (COIN) programs in what PND or overall system, who can invoke certain COIN programs in what PND or
COIN device, and what type of (COIN) program can be run. These COIN device, and what type of COIN program can be run. These
considerations will impact the design of the possible implementing considerations will impact the design of the possible implementing
protocols but also the policies that govern the execution of (COIN) protocols but also the policies that govern the execution of COIN
programs. programs.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. Conclusion 10. Conclusion
This document presents use cases gathered from several application This document presents use cases gathered from several application
domains that can and could profit from capabilities that are provided domains that can and could profit from capabilities that are provided
skipping to change at line 2030 skipping to change at line 2029
server-load-balancing-gslb/>. server-load-balancing-gslb/>.
[ICN-5GC] Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G. [ICN-5GC] Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G.
White, "Enabling ICN in 3GPP's 5G NextGen Core White, "Enabling ICN in 3GPP's 5G NextGen Core
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ravi-icnrg-5gc-icn-04, 31 May 2019, ravi-icnrg-5gc-icn-04, 31 May 2019,
<https://datatracker.ietf.org/doc/html/draft-ravi-icnrg- <https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-
5gc-icn-04>. 5gc-icn-04>.
[ICN-5GLAN] [ICN-5GLAN]
Trossen, D., Wang, C., Robitzsch, S., Reed, M., AL-Naday, Trossen, D., Robitzsch, S., Essex, U., AL-Naday, M., and
M., and J. Riihijarvi, "IP-based Services over ICN in 5G J. Riihijarvi, "Internet Services over ICN in 5G LAN
LAN Environments", Work in Progress, Internet-Draft, Environments", Work in Progress, Internet-Draft, draft-
draft-trossen-icnrg-ip-icn-5glan-00, 6 June 2019, trossen-icnrg-internet-icn-5glan-04, 1 October 2020,
<https://datatracker.ietf.org/doc/html/draft-trossen- <https://datatracker.ietf.org/doc/html/draft-trossen-
icnrg-ip-icn-5glan-00>. icnrg-internet-icn-5glan-04>.
[KUNZE-APPLICABILITY] [KUNZE-APPLICABILITY]
Kunze, I., Glebke, R., Scheiper, J., Bodenbenner, M., Kunze, I., Glebke, R., Scheiper, J., Bodenbenner, M.,
Schmitt, R., and K. Wehrle, "Investigating the Schmitt, R., and K. Wehrle, "Investigating the
Applicability of In-Network Computing to Industrial Applicability of In-Network Computing to Industrial
Scenarios", 2021 4th IEEE International Conference on Scenarios", 2021 4th IEEE International Conference on
Industrial Cyber-Physical Systems (ICPS), pp. 334-340, Industrial Cyber-Physical Systems (ICPS), pp. 334-340,
DOI 10.1109/icps49255.2021.9468247, May 2021, DOI 10.1109/icps49255.2021.9468247, May 2021,
<https://doi.org/10.1109/icps49255.2021.9468247>. <https://doi.org/10.1109/icps49255.2021.9468247>.
 End of changes. 79 change blocks. 
159 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.48.