< draft-irtf-coinrg-use-cases-01.txt   draft-irtf-coinrg-use-cases-02.txt >
COINRG I. Kunze COINRG I. Kunze
Internet-Draft K. Wehrle Internet-Draft K. Wehrle
Intended status: Informational RWTH Aachen Intended status: Informational RWTH Aachen
Expires: 28 April 2022 D. Trossen Expires: 8 September 2022 D. Trossen
Huawei Huawei
M.J. Montpetit M.J. Montpetit
Concordia Concordia
X. de Foy X. de Foy
InterDigital Communications, LLC InterDigital Communications, LLC
D. Griffin D. Griffin
M. Rio M. Rio
UCL UCL
25 October 2021 7 March 2022
Use Cases for In-Network Computing Use Cases for In-Network Computing
draft-irtf-coinrg-use-cases-01 draft-irtf-coinrg-use-cases-02
Abstract Abstract
Computing in the Network (COIN) comes with the prospect of deploying Computing in the Network (COIN) comes with the prospect of deploying
processing functionality on networking devices, such as switches and processing functionality on networking devices, such as switches and
network interface cards. While such functionality can be beneficial network interface cards. While such functionality can be beneficial
in several contexts, it has to be carefully placed into the context in several contexts, it has to be carefully placed into the context
of the general Internet communication. This document discusses some of the general Internet communication.
use cases to demonstrate how real applications can benefit from COIN
and to showcase essential requirements that have to be fulfilled by This document discusses some use cases to demonstrate how real
COIN applications. applications can benefit from COIN and to showcase essential
requirements that have to be fulfilled by COIN applications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 April 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Providing New COIN Experiences . . . . . . . . . . . . . . . 6 3. Providing New COIN Experiences . . . . . . . . . . . . . . . 6
3.1. Mobile Application Offloading . . . . . . . . . . . . . . 6 3.1. Mobile Application Offloading . . . . . . . . . . . . . . 6
3.1.1. Description . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Description . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Characterization . . . . . . . . . . . . . . . . . . 7 3.1.2. Characterization . . . . . . . . . . . . . . . . . . 7
3.1.3. Existing Solutions . . . . . . . . . . . . . . . . . 9 3.1.3. Existing Solutions . . . . . . . . . . . . . . . . . 9
3.1.4. Opportunities and Research Questions for COIN . . . . 9 3.1.4. Opportunities . . . . . . . . . . . . . . . . . . . . 9
3.1.5. Requirements . . . . . . . . . . . . . . . . . . . . 10 3.1.5. Research Questions . . . . . . . . . . . . . . . . . 9
3.2. Extended Reality (XR) . . . . . . . . . . . . . . . . . . 11 3.1.6. Requirements . . . . . . . . . . . . . . . . . . . . 10
3.2. Extended Reality and Immersive Media . . . . . . . . . . 11
3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Characterization . . . . . . . . . . . . . . . . . . 11 3.2.2. Characterization . . . . . . . . . . . . . . . . . . 11
3.2.3. Existing Solutions . . . . . . . . . . . . . . . . . 11 3.2.3. Existing Solutions . . . . . . . . . . . . . . . . . 12
3.2.4. Opportunities and Research Questions for COIN . . . . 12 3.2.4. Opportunities . . . . . . . . . . . . . . . . . . . . 13
3.2.5. Requirements . . . . . . . . . . . . . . . . . . . . 14 3.2.5. Research Questions . . . . . . . . . . . . . . . . . 13
3.3. Personalised and interactive performing arts . . . . . . 15 3.2.6. Requirements . . . . . . . . . . . . . . . . . . . . 14
3.3. Personalised and interactive performing arts . . . . . . 14
3.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15 3.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15
3.3.2. Characterization . . . . . . . . . . . . . . . . . . 15 3.3.2. Characterization . . . . . . . . . . . . . . . . . . 15
3.3.3. Existing solutions . . . . . . . . . . . . . . . . . 17 3.3.3. Existing solutions . . . . . . . . . . . . . . . . . 17
3.3.4. Opportunities . . . . . . . . . . . . . . . . . . . . 17 3.3.4. Opportunities . . . . . . . . . . . . . . . . . . . . 17
3.3.5. Research Questions: . . . . . . . . . . . . . . . . . 17 3.3.5. Research Questions: . . . . . . . . . . . . . . . . . 17
3.3.6. Requirements . . . . . . . . . . . . . . . . . . . . 18 3.3.6. Requirements . . . . . . . . . . . . . . . . . . . . 18
4. Supporting new COIN Systems . . . . . . . . . . . . . . . . . 19 4. Supporting new COIN Systems . . . . . . . . . . . . . . . . . 18
4.1. Industrial Network Scenario . . . . . . . . . . . . . . . 19 4.1. Industrial Network Scenario . . . . . . . . . . . . . . . 19
4.2. In-Network Control / Time-sensitive applications . . . . 20 4.2. In-Network Control / Time-sensitive applications . . . . 20
4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 20 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 20
4.2.2. Characterization . . . . . . . . . . . . . . . . . . 21 4.2.2. Characterization . . . . . . . . . . . . . . . . . . 21
4.2.3. Existing Solutions . . . . . . . . . . . . . . . . . 21 4.2.3. Existing Solutions . . . . . . . . . . . . . . . . . 21
4.2.4. Opportunities for COIN . . . . . . . . . . . . . . . 22 4.2.4. Opportunities . . . . . . . . . . . . . . . . . . . . 22
4.2.5. Research Questions for COIN . . . . . . . . . . . . . 22 4.2.5. Research Questions . . . . . . . . . . . . . . . . . 22
4.2.6. Requirements . . . . . . . . . . . . . . . . . . . . 23 4.2.6. Requirements . . . . . . . . . . . . . . . . . . . . 23
4.3. Large Volume Applications - Filtering . . . . . . . . . . 23 4.3. Large Volume Applications - Filtering . . . . . . . . . . 23
4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 23 4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 23
4.3.2. Characterization . . . . . . . . . . . . . . . . . . 24 4.3.2. Characterization . . . . . . . . . . . . . . . . . . 24
4.3.3. Existing Solutions . . . . . . . . . . . . . . . . . 25 4.3.3. Existing Solutions . . . . . . . . . . . . . . . . . 25
4.3.4. Opportunities for COIN . . . . . . . . . . . . . . . 25 4.3.4. Opportunities . . . . . . . . . . . . . . . . . . . . 25
4.3.5. Research Questions for COIN . . . . . . . . . . . . . 25 4.3.5. Research Questions . . . . . . . . . . . . . . . . . 26
4.3.6. Requirements . . . . . . . . . . . . . . . . . . . . 26 4.3.6. Requirements . . . . . . . . . . . . . . . . . . . . 26
4.4. Large Volume Applications - (Pre-)Preprocessing . . . . . 26 4.4. Large Volume Applications - (Pre-)Preprocessing . . . . . 26
4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 26 4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 26
4.4.2. Characterization . . . . . . . . . . . . . . . . . . 26 4.4.2. Characterization . . . . . . . . . . . . . . . . . . 26
4.4.3. Existing Solutions . . . . . . . . . . . . . . . . . 26 4.4.3. Existing Solutions . . . . . . . . . . . . . . . . . 27
4.4.4. Opportunities for COIN . . . . . . . . . . . . . . . 27 4.4.4. Opportunities . . . . . . . . . . . . . . . . . . . . 27
4.4.5. Research Questions for COIN . . . . . . . . . . . . . 27 4.4.5. Research Questions . . . . . . . . . . . . . . . . . 27
4.4.6. Requirements . . . . . . . . . . . . . . . . . . . . 27 4.4.6. Requirements . . . . . . . . . . . . . . . . . . . . 27
4.5. Industrial Safety . . . . . . . . . . . . . . . . . . . . 27 4.5. Industrial Safety . . . . . . . . . . . . . . . . . . . . 28
4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 28 4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 28
4.5.2. Characterization . . . . . . . . . . . . . . . . . . 28 4.5.2. Characterization . . . . . . . . . . . . . . . . . . 28
4.5.3. Existing Solutions . . . . . . . . . . . . . . . . . 28 4.5.3. Existing Solutions . . . . . . . . . . . . . . . . . 28
4.5.4. Opportunities for COIN . . . . . . . . . . . . . . . 29 4.5.4. Opportunities . . . . . . . . . . . . . . . . . . . . 29
4.5.5. Research Questions for COIN . . . . . . . . . . . . . 29 4.5.5. Research Questions . . . . . . . . . . . . . . . . . 29
4.5.6. Requirements . . . . . . . . . . . . . . . . . . . . 29 4.5.6. Requirements . . . . . . . . . . . . . . . . . . . . 29
5. Improving existing COIN capabilities . . . . . . . . . . . . 29 5. Improving existing COIN capabilities . . . . . . . . . . . . 29
5.1. Content Delivery Networks . . . . . . . . . . . . . . . . 29 5.1. Content Delivery Networks . . . . . . . . . . . . . . . . 29
5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 29 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 29
5.1.2. Characterization . . . . . . . . . . . . . . . . . . 30 5.1.2. Characterization . . . . . . . . . . . . . . . . . . 30
5.1.3. Existing Solutions . . . . . . . . . . . . . . . . . 30 5.1.3. Existing Solutions . . . . . . . . . . . . . . . . . 30
5.1.4. Opportunities and Research Questions for COIN . . . . 30 5.1.4. Opportunities . . . . . . . . . . . . . . . . . . . . 30
5.1.5. Requirements . . . . . . . . . . . . . . . . . . . . 31 5.1.5. Research Questions . . . . . . . . . . . . . . . . . 30
5.1.6. Requirements . . . . . . . . . . . . . . . . . . . . 31
5.2. Compute-Fabric-as-a-Service (CFaaS) . . . . . . . . . . . 31 5.2. Compute-Fabric-as-a-Service (CFaaS) . . . . . . . . . . . 31
5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 31 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 31
5.2.2. Characterization . . . . . . . . . . . . . . . . . . 31 5.2.2. Characterization . . . . . . . . . . . . . . . . . . 31
5.2.3. Existing Solutions . . . . . . . . . . . . . . . . . 32 5.2.3. Existing Solutions . . . . . . . . . . . . . . . . . 32
5.2.4. Opportunities and Research Questions for COIN . . . . 32 5.2.4. Opportunities . . . . . . . . . . . . . . . . . . . . 32
5.2.5. Requirements . . . . . . . . . . . . . . . . . . . . 33 5.2.5. Research Questions . . . . . . . . . . . . . . . . . 32
5.2.6. Requirements . . . . . . . . . . . . . . . . . . . . 33
5.3. Virtual Networks Programming . . . . . . . . . . . . . . 33 5.3. Virtual Networks Programming . . . . . . . . . . . . . . 33
5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 33 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 33
5.3.2. Characterization . . . . . . . . . . . . . . . . . . 34 5.3.2. Characterization . . . . . . . . . . . . . . . . . . 34
5.3.3. Existing Solutions . . . . . . . . . . . . . . . . . 36 5.3.3. Existing Solutions . . . . . . . . . . . . . . . . . 36
5.3.4. Opportunities . . . . . . . . . . . . . . . . . . . . 36 5.3.4. Opportunities . . . . . . . . . . . . . . . . . . . . 36
5.3.5. Research Questions for COIN . . . . . . . . . . . . . 37 5.3.5. Research Questions . . . . . . . . . . . . . . . . . 37
5.3.6. Requirements . . . . . . . . . . . . . . . . . . . . 38 5.3.6. Requirements . . . . . . . . . . . . . . . . . . . . 38
6. Enabling new COIN capabilities . . . . . . . . . . . . . . . 38 6. Enabling new COIN capabilities . . . . . . . . . . . . . . . 38
6.1. Distributed AI . . . . . . . . . . . . . . . . . . . . . 38 6.1. Distributed AI . . . . . . . . . . . . . . . . . . . . . 38
6.1.1. Description . . . . . . . . . . . . . . . . . . . . . 38 6.1.1. Description . . . . . . . . . . . . . . . . . . . . . 38
6.1.2. Characterization . . . . . . . . . . . . . . . . . . 39 6.1.2. Characterization . . . . . . . . . . . . . . . . . . 39
6.1.3. Existing Solutions . . . . . . . . . . . . . . . . . 39 6.1.3. Existing Solutions . . . . . . . . . . . . . . . . . 39
6.1.4. Opportunities and Research Questions for COIN . . . . 39 6.1.4. Opportunities . . . . . . . . . . . . . . . . . . . . 39
6.1.5. Requirements . . . . . . . . . . . . . . . . . . . . 40 6.1.5. Research Questions . . . . . . . . . . . . . . . . . 40
6.1.6. Requirements . . . . . . . . . . . . . . . . . . . . 40
7. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 7.1. Opportunities . . . . . . . . . . . . . . . . . . . . . . 40
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 7.2. Research Questions . . . . . . . . . . . . . . . . . . . 41
10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 41 7.2.1. Categorization . . . . . . . . . . . . . . . . . . . 41
11. List of Use Case Contributors . . . . . . . . . . . . . . . . 41 7.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 42
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 49
12.1. Normative References . . . . . . . . . . . . . . . . . . 42 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
12.2. Informative References . . . . . . . . . . . . . . . . . 42 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 49
11. List of Use Case Contributors . . . . . . . . . . . . . . . . 50
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. Normative References . . . . . . . . . . . . . . . . . . 50
12.2. Informative References . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
The Internet is a best-effort network that offers limited guarantees The Internet was designed as a best-effort packet network that offers
regarding the timely and successful transmission of packets. Data limited guarantees regarding the timely and successful transmission
manipulation and protocol functionality is generally provided by the of packets. Data manipulation, computation, and more complex
end-hosts while the network is kept simple and only intended as a protocol functionality is generally provided by the end-hosts while
"store and forward" packet facility. This design choice is suitable network nodes are kept simple and only offer a "store and forward"
for a wide variety of applications and has helped in the rapid growth packet facility. This design choice has shown suitable for a wide
of the Internet. variety of applications and has helped in the rapid growth of the
Internet.
However, there are several domains which, e.g., demand a number of However, with the expansion of the Internet, there are more and more
strict performance guarantees that cannot be provided over regular fields that require more than best-effort forwarding including strict
best-effort networks or require more closed loop integration to performance guarantees or closed-loop integration to manage data
manage data flows. In this context, allowing for a tighter flows. In this context, allowing for a tighter integration of
integration of compute and network resources, enabling the more computing and networking resources, enabling a more flexible
flexible distribution of computation tasks across the network, i.e., distribution of computation tasks across the network, e.g., beyond
beyond 'just' endpoints, may help to achieve the desired guarantees 'just' endpoints, may help to achieve the desired guarantees and
and behaviours as well as increase the overall performance. The behaviors as well as increase overall performance. The vision of
vision of 'in-network computing' and the provisioning of capabilities 'in-network computing' and the provisioning of such capabilities that
that capitalize on such joint computation and communication resource capitalize on joint computation and communication resource usage
usage throughout the network is core to the efforts in the COIN RG; throughout the network is core to the efforts in the COIN RG; we
we term those capabilities as 'COIN capabilities' in the remainder of refer to those capabilities as 'COIN capabilities' in the remainder
the document. of the document.
We believe that such vision of 'in-network computing' can be best We believe that such vision of 'in-network computing' can be best
outlined along four dimensions of use cases, namely those that (i) outlined along four dimensions of use cases, namely those that (i)
provide new user experiences through the utilization of COIN provide new user experiences through the utilization of COIN
capabilities (termed 'COIN experiences'), (ii) enable new COIN capabilities (referred to as 'COIN experiences'), (ii) enable new
systems, e.g., through new interactions between communication and COIN systems, e.g., through new interactions between communication
compute providers, (iii) improve on already existing COIN and compute providers, (iii) improve on already existing COIN
capabilities as well as (iv) enable new such COIN capabilities. capabilities and (iv) enable new COIN capabilities. Sections 3
Sections 3 through 6 capture those categories of use cases as the through 6 capture those categories of use cases and provide the main
main structure of this document. structure of this document. The goal is to present how the presence
of computing resources inside the network impacts existing services
and applications or allows for innovation in emerging fields.
Through delving into individual examples within each of the above Through delving into some individual examples within each of the
categories, we aim to outline oppportunities and possible research above categories, we aim to outline opportunities and propose
questions that may need consideration by the wider community when possible research questions for consideration by the wider community
pushing forward the 'in-network computing' vision. Furthermore, when pushing forward the 'in-network computing' vision. Furthermore,
insights into possible requirements for an evolving solution space of insights into possible requirements for an evolving solution space of
collected COIN capabilities is another objective of the individual collected COIN capabilities is another objective of the individual
use case descriptions. This results in the following taxonomy used use case descriptions. This results in the following taxonomy used
to describe each of the use cases: to describe each of the use cases:
1. Description: Purpose of the use case and explanation of the use 1. Description: Purpose of the use case and explanation of the use
case behavior case behavior
2. Characterization: Explanation of the services that are being 2. Characterization: Explanation of the services that are being
utilized and realized as well as the semantics of interactions in utilized and realized as well as the semantics of interactions in
skipping to change at page 5, line 32 skipping to change at page 5, line 45
5. Research questions: State essential questions that are suitable 5. Research questions: State essential questions that are suitable
for guiding research to achieve the outlined opportunities for guiding research to achieve the outlined opportunities
6. Requirements: Describe the requirements for any solutions for 6. Requirements: Describe the requirements for any solutions for
COIN capabilities that may need development along the COIN capabilities that may need development along the
opportunities outlined in item 4; here, we limit requirements to opportunities outlined in item 4; here, we limit requirements to
those COIN capabilities, recognizing that any use case will those COIN capabilities, recognizing that any use case will
realistically hold many additional requirements for its realistically hold many additional requirements for its
realization. realization.
In order to provide a useful input into future roadmapping on what In Section 7, we will summarize the key research questions across all
COIN capabilities may emerge and how solutions of such capabilities use cases and identify key requirements across all use cases. This
may look like as well as what questions remain to realize such will provide a useful input into future roadmapping on what COIN
solutions, we will analyze the use cases in Section 7 by providing an capabilities may emerge and how solutions of such capabilities may
overview of key research questions across all use cases, while look like. It will also identify what open questions remain for
similarly gathering key requirements identified across all use cases. these use cases to materialize as well as define requirements to
Through this, we intent to converge to key aspects in the form of steer future (COIN) research work.
possible open questions as well as requirements that may steer future
(COIN) research work.
2. Terminology 2. Terminology
The following terminology has been partly aligned with The following terminology has been partly aligned with
[I-D.draft-kutscher-coinrg-dir]: [I-D.draft-kutscher-coinrg-dir]:
(COIN) Program: a set of computations requested by a user (COIN) Program: a set of computations requested by a user
(COIN) Program Instance: one currently executing instance of a (COIN) Program Instance: one currently executing instance of a
program program
skipping to change at page 9, line 9 skipping to change at page 9, line 9
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/many-viewing than one display (COIN) program, e.g., for multi/many-viewing
scenarios, thereby realizing a service-level multicast capability scenarios, thereby realizing a service-level multicast capability
towards more than one (COIN) program. towards more than one (COIN) program.
3.1.3. Existing Solutions 3.1.3. Existing Solutions
NOTE: material on solutions like ETSI MEC will be added here later NOTE: material on solutions like ETSI MEC will be added here later
3.1.4. Opportunities and Research Questions for COIN 3.1.4. Opportunities
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 application towards a possible centric execution of those mobile application towards 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 end systems and PNDs alike may open up the possibility specific end systems and PNDs alike may open up the possibility
for localized infrastructure owners, such as hotels or venue for localized infrastructure owners, such as hotels or venue
skipping to change at page 9, line 45 skipping to change at page 9, line 43
elements will allow for routing service requests to those COIN elements will allow for routing service requests to those COIN
elements, including PNDs, therefore possibly allowing for new in- elements, including PNDs, therefore possibly allowing for new in-
network functionality to be included in the mobile application. network functionality to be 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 (constraint-based routing in program instance over others (constraint-based routing in
[APPCENTRES]) may allow for a more flexible and app-specific [APPCENTRES]) may allow for a more flexible and app-specific
selection of (COIN) program instances, thereby allowing for better selection of (COIN) program instances, thereby allowing for better
meeting the app-specific and end user requirements. meeting the app-specific and end user requirements.
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
with app-level packaging methods? with app-level packaging methods?
* 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? quickly?
* 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? towards (COIN) program instances in a scalable manner?
skipping to change at page 10, line 23 skipping to change at page 10, line 23
* 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) program instances, i.e., longer-term transactions with (COIN) program instances, i.e., longer-term transactions with
ephemeral state established at a specific (COIN) program instance? ephemeral state established at a specific (COIN) program instance?
* RQ 3.1.7: How to provide constraint-based routing decisions at * RQ 3.1.7: How to provide constraint-based routing decisions at
packet forwarding speed? packet forwarding speed?
* RQ 3.1.8: What in-network capabilities may support the execution * RQ 3.1.8: What in-network capabilities may support the execution
of (COIN) programs and their instances? of (COIN) programs and their instances?
3.1.5. Requirements 3.1.6. Requirements
Req 3.1.1: Any COIN system MUST provide means for routing of service * Req 3.1.1: Any COIN system MUST provide means for routing of
requests between resources in the distributed environment. service requests between resources in the distributed environment.
Req 3.1.2: Any COIN system MUST provide means for identifying * Req 3.1.2: Any COIN system MUST provide means for identifying
services exposed by (COIN) programs for directing service requests services exposed by (COIN) programs for directing service requests
Req 3.1.3: Any COIN system MUST provide means for identifying (COIN) * (Req 3.1.3: Any COIN system MUST provide means for identifying
program instances for directing (affinity) requests to a specific (COIN) program instances for directing (affinity) requests to a
(COIN) program instance specific (COIN) program instance
Req 3.1.4: Any COIN system MUST provide means for dynamically * Req 3.1.4: Any COIN system MUST provide means for dynamically
choosing the best possible service sequence of one or more (COIN) choosing the best possible service sequence of one or more (COIN)
programs for a given application experience, i.e., support for programs for a given application experience, i.e., support for
chaining (COIN) program executions. chaining (COIN) program executions.
Req 3.1.5: Means for discovering suitable (COIN) programs SHOULD be * Req 3.1.5: Means for discovering suitable (COIN) programs SHOULD
provided. be provided.
Req 3.1.6: Any COIN system MUST provide means for pinning the * Req 3.1.6: Any COIN system MUST provide means for pinning the
execution of a service of a specific (COIN) program to a specific execution of a service of a specific (COIN) program to a specific
resource, i.e., (COIN) program instance in the distributed resource, i.e., (COIN) program instance in the distributed
environment. environment.
Req 3.1.7: Any COIN system SHOULD provide means for packaging micro- * Req 3.1.7: Any COIN system SHOULD provide means for packaging
services for deployments in distributed networked computing micro-services for deployments in distributed networked computing
environments. environments.
Req 3.1.8: The packaging MAY include any constraints regarding the * Req 3.1.8: The packaging MAY include any constraints regarding the
deployment of (COIN) program instances in specific network locations deployment of (COIN) program instances in specific network
or compute resources, including PNDs. locations or compute resources, including PNDs.
Req 3.1.9: Such packaging SHOULD conform to existing application * Req 3.1.9: Such packaging SHOULD conform to existing application
deployment models, such as mobile application packaging, TOSCA deployment models, such as mobile application packaging, TOSCA
orchestration templates or tar balls or combinations thereof. orchestration templates or tar balls or combinations thereof.
Req 3.1.10: Any COIN system MUST provide means for real-time * Req 3.1.10: Any COIN system MUST provide means for real-time
synchronization and consistency of distributed application states. synchronization and consistency of distributed application states.
3.2. Extended Reality (XR) 3.2. Extended Reality and Immersive Media
3.2.1. Description 3.2.1. Description
Virtual Reality (VR) and Augmented Reality (AR) taken together as Virtual Reality (VR), Augmented Reality (AR) and immersive media (the
Extended Reality (XR) are at the center of a number of advances in metaverse) taken together as Extended Reality (XR) are the drivers of
interactive technologies. While initially associated with gaming and a number of advances in interactive technologies. XR is one example
entertainment, XR applications now include remote diagnosis, of the Multisource-Multidestination Problem that combines video,
maintenance, telemedicine, manufacturing and assembly, autonomous haptics, and tactile experiences in interactive or networked multi-
systems, smart cities, and immersive classrooms. party and social interactions. While initially associated with
gaming and entertainment, XR applications now include remote
diagnosis, maintenance, telemedicine, manufacturing and assembly,
autonomous systems, smart cities, and immersive classrooms.
Because XR requirements include the need to provide real-time
interactivity for immersive and increasingly mobile immersive
applications with tactile and time-sensitive data and high bandwidth
for high resolution images and local rendering for 3D images and
holograms, they are difficult to run over traditional networks; in
consequence innovation is needed to deply the full potential of the
applications.
3.2.2. Characterization 3.2.2. Characterization
XR is one example of the Multisource-Multidestination Problem that Collaborative XR experiences are difficult to deliver with a client-
combines video, haptics, and tactile experiences in interactive or server cloud-based solution as they require a combination of: stream
networked multi-party and social interactions. Thus, XR is difficult synchronization, low delays and delay variations, means to recover
to deliver with a client-server cloud-based solution as it requires a from losses and optimized caching and rendering as close as possible
combination of: stream synchronization, low delays and delay to the user at the network edge. XR deals with personal information
variations, means to recover from losses and optimized caching and and potentially protected content this an XR application must also
rendering as close as possible to the user at the network edge. Many provide a secure environment and ensure user privacy. Additionally,
XR services that involve video holography and haptics, require very the sheer amount of data needed for and generated by the XR
low delay or generate large amounts of data, both requiring a careful applications can use recent trend analysis and mechanisms, including
look at data filtering and reduction, functional distribution and machine learning to find these trends and reduce the size of the data
partitioning. Hence, XR uses recent advances in in-network sets. Video holography and haptics require very low delay or
programming, distributed networks, orchestration and resource generate large amounts of data, both requiring a careful look at data
discovery to support the XR advanced immersive requirements. It is filtering and reduction, functional distribution and partitioning.
important to note that the use of in-network computing for XR does
not imply a specific protocol but targets an architecture enabling The operation of XR over networks requires some computing in the
the deployment of the services. This includes computing in the nodes nodes from content source to destination. But a lot of these remain
from content source to destination. in the realm of research to resolve the resource allocation problem
and provide adequate quality of experience. These include multi-
variate and heterogeneous goal optimization problems at merging nodes
requiring advanced analysis. Image rendering and video processing in
XR leverages different HW capabilities combinations of CPU and GPU at
the edge (even at the mobile edge) and in the fog network where the
content is consumed. It is important to note that the use of in-
network computing for XR does not imply a specific protocol but
targets an architecture enabling the deployment of the services.
3.2.3. Existing Solutions 3.2.3. Existing Solutions
Related XR or XR-enabling solutions using in-network computation or In-network computing for XR profits from the heritage of extensive
related technologies include: research in the past years on Information Centric Networking, Machine
Learning, network telemetry, imaging and IoT as well as distributed
security and in-network coding.
* Enabling Scalable Edge Video Analytics with Computing-In-Network * Enabling Scalable Edge Video Analytics with Computing-In-Network
(Jun Chen Jiang of the University of Chicago): this work brings a (Jun Chen Jiang of the University of Chicago): this work brings a
periodical re-profiling to adapt the video pipeline to the dynamic periodical re-profiling to adapt the video pipeline to the dynamic
video content that is a characteristic of XR. The implication is video content that is a characteristic of XR. The implication is
that "need tight network-app coupling" for real time video that we "need tight network-app coupling" for real time video
analytics. analytics.
* VR journalism, interactive VR movies and meetings in cyberspace * VR journalism, interactive VR movies and meetings in cyberspace
(many projects PBS, MIT interactive documentary lab, Huawei (many projects PBS, MIT interactive documentary lab, Huawei
research - references to be provided): typical VR is not made for research - references to be provided): typical VR is not made for
multiparty and these applications require a tight coupling of the multiparty and these applications require a tight coupling of the
local and remote rendering and data capture and combinations of local and remote rendering and data capture and combinations of
cloud (for more static information) and edge (for dynamic cloud (for more static information) and edge (for dynamic
content). content).
skipping to change at page 12, line 33 skipping to change at page 13, line 5
large amounts of data necessary to transmit and use holographic large amounts of data necessary to transmit and use holographic
imagery in communications. Transmitting the near field imagery in communications. Transmitting the near field
information and rendering the image locally allows to reduce the information and rendering the image locally allows to reduce the
data rates by 1 or 2. data rates by 1 or 2.
* ICE-AR [ICE] project at UCLA (Jeff Burke): while this project is a * ICE-AR [ICE] project at UCLA (Jeff Burke): while this project is a
showcase of the NDN network artchitecture it also uses a lof of showcase of the NDN network artchitecture it also uses a lof of
edge-cloud capabilities for example for inter-server games and edge-cloud capabilities for example for inter-server games and
advanced video applications. advanced video applications.
3.2.4. Opportunities and Research Questions for COIN 3.2.4. Opportunities
Opportunities:
In-network computing for XR profits from the heritage of extensive
research in the past years on Information Centric Networking, Machine
Learning, network telemetry, imaging and IoT as well as distributed
security and in-network coding. The opportunities include:
* Reduced latency: the physical distance between the content cloud * Reduced latency: the physical distance between the content cloud
and the users must be short enough to limit the propagation delay and the users must be short enough to limit the propagation delay
to the 20 ms usually cited for XR applications; the use of local to the 20 ms usually cited for XR applications; the use of local
CPU and IoT devices for range of interest (RoI) detection and CPU and IoT devices for range of interest (RoI) detection and
fynamic rendering may enable this. fynamic rendering may enable this.
* Video transmission: better transcoding and use of advanced * Video transmission: better transcoding and use of advanced
context-based compression algorithms, pre-fetching and pre-caching context-based compression algorithms, pre-fetching and pre-caching
and movement prediction not only in the cloud. and movement prediction not only in the cloud.
skipping to change at page 13, line 20 skipping to change at page 13, line 32
algorithms for congestion control and application-based load algorithms for congestion control and application-based load
balancing based on machine learning and user data patterns. balancing based on machine learning and user data patterns.
* Functional decomposition: functional decomposition, localization * Functional decomposition: functional decomposition, localization
and discovery of computing and storage resources in the network. and discovery of computing and storage resources in the network.
But it is not only finding the best resources but qualifying those But it is not only finding the best resources but qualifying those
resources in terms of reliability especially for mission critical resources in terms of reliability especially for mission critical
services in XR (medicine for example). This could include services in XR (medicine for example). This could include
intelligence services. intelligence services.
Research Questions: 3.2.5. Research Questions
There is a need for more research resource allocation problems at the
edge to enable interactive operation and quality of experience in VR.
These include multi-variate and heterogeneous goal optimization
problems requiring advanced analysis. Image rendering and video
processing in XR leverages different HW capabilities combinations of
CPU and GPU. Research questions include:
* RQ 3.2.1: Can current programmable network entities be sufficient * RQ 3.2.1: Can current programmable network entities be sufficient
to provide the speed required to provide and execute complex to provide the speed required to provide and execute complex
filtering operations that includes metadata analysis for complex filtering operations that includes metadata analysis for complex
and dynamic scene rendering? and dynamic scene rendering?
* RQ 3.2.2: How can the interoperability of CPU/GPU be optimized to * RQ 3.2.2: How can the interoperability of CPU/GPU be optimized to
combine low level packet filteting with the higher layer combine low level packet filtering with the higher layer
processors needed for image processing and haptics? processors needed for image processing and haptics?
* RQ 3.2.3: Can the use of joint learning algorithms across both * RQ 3.2.3: Can the use of joint learning algorithms across both
data center and edge computers be used to create optimal data center and edge computers be used to create optimal
functionality allocation and the creation of semi-permanent functionality allocation and the creation of semi-permanent
datasets and analytics for usage trending resulting in better datasets and analytics for usage trending resulting in better
localization of XR functions? localization of XR functions?
* RQ 3.2.4: Can COIN improve the dynamic distribution of control, * RQ 3.2.4: Can COIN improve the dynamic distribution of control,
forwarding and storage resources and related usage models in XR? forwarding and storage resources and related usage models in XR?
3.2.5. Requirements 3.2.6. Requirements
XR requirements include the need to provide real-time interactivity
for immersive and increasingly mobile immersive applications with
tactile and time-sensitive data and high bandwidth for high
resolution images and local rendering for 3D images and holograms.
Since XR deals with personal information and potentially protected
content XR must also provide a secure environment and ensure user
privacy. Additionally, the sheer amount of data needed for and
generated by the XR applications can use recent trend analysis and
mechanisms, including machine learning to find these trends and
reduce the size of the data sets. The requirements can be summarized
as:
Req 3.2.1: Allow joint collaboration. * Req 3.2.1: Allow joint collaboration.
Req 3.2.2: Provide multi-views. * Req 3.2.2: Provide multi-views.
Req 3.2.3: Include extra streams dynamically for data intensive * Req 3.2.3: Include extra streams dynamically for data intensive
services, manufacturing and industrial processes. services, manufacturing and industrial processes.
Req 3.2.4: Enable multistream, multidevice, multidestination * Req 3.2.4: Enable multistream, multidevice, multidestination
applications. applications.
Req 3.2.5: Use new Internet Architectures at the edge for improved * Req 3.2.5: Use new Internet Architectures at the edge for improved
performance and performance management. performance and performance management.
Req 3.2.6: Integrate with holography, 3D displays and image rendering * Req 3.2.6: Integrate with holography, 3D displays and image
processors. rendering processors.
Req 3.2.7: All the use of multicast distribution and processing as * Req 3.2.7: All the use of multicast distribution and processing as
well as peer to peer distribution in bandwidth and capacity well as peer to peer distribution in bandwidth and capacity
constrained environments. constrained environments.
Req 3.2.8: Evaluate the integration local and fog caching with cloud- * Req 3.2.8: Evaluate the integration local and fog caching with
based pre-rendering. cloud-based pre-rendering.
Req 3.2.9: Evaluate ML-based congestion control to manage XR sessions * Req 3.2.9: Evaluate ML-based congestion control to manage XR
quality of service and to determine how to priortize data. sessions quality of service and to determine how to priortize
data.
Req 3.2.10: Consider higher layer protocols optimization to reduce * Req 3.2.10: Consider higher layer protocols optimization to reduce
latency especially in data intensive applications at the edge. latency especially in data intensive applications at the edge.
Req 3.2.11: Provide trust, including blockchains and smart-contracts * Req 3.2.11: Provide trust, including blockchains and smart-
to enable secure community building across domains. contracts to enable secure community building across domains.
Req 3.2.12: Support nomadicity and mobility (link to mobile edge). * Req 3.2.12: Support nomadicity and mobility (link to mobile edge).
Req 3.2.13: Use 5G slicing to create independent session-driven * Req 3.2.13: Use 5G slicing to create independent session-driven
processing/rendering. processing/rendering.
Req 3.2.14: Provide performance optimization by data reduction, * Req 3.2.14: Provide performance optimization by data reduction,
tunneling, session virtualization and loss protection. tunneling, session virtualization and loss protection.
Req 3.2.15: Use AI/ML for trend analysis and data reduction when * Req 3.2.15: Use AI/ML for trend analysis and data reduction when
appropriate. appropriate.
3.3. Personalised and interactive performing arts 3.3. Personalised and interactive performing arts
3.3.1. Description 3.3.1. Description
This use case covers live productions of the performing arts where This use case covers live productions of the performing arts where
the performers and audience are in different physical locations. The the performers and audience are in different physical locations. The
performance is conveyed to the audience through multiple networked performance is conveyed to the audience through multiple networked
streams which may be tailored to the requirements of individual streams which may be tailored to the requirements of individual
audience members; and the performers receive live feedback from the audience members; and the performers receive live feedback from the
audience. audience.
There are two main aspects: i) to emulate as closely as possible the There are two main aspects: i) to emulate as closely as possible the
experience of live performances where the performers and audience are experience of live performances where the performers and audience are
co-located in the same physical space, such as a theatre; and ii) to co-located in the same physical space, such as a theatre; and ii) to
enhance traditional physical performances with features such as enhance traditional physical performances with features such as
personalisation of the experience according to the preferences or personalisation of the experience according to the preferences or
needs of the audience members. needs of the audience members.
Examples of personalisation include: Examples of personalisation include:
* viewpoint selection such as choosing a specific seat in the * Viewpoint selection such as choosing a specific seat in the
theatre or for more advanced positioning of the audience member's theatre or for more advanced positioning of the audience member's
viewpoint outside of the traditional seating - amongst, above or viewpoint outside of the traditional seating - amongst, above or
behind the performers (but within some limits which may be imposed behind the performers (but within some limits which may be imposed
by the performers or the director for artistic reasons); by the performers or the director for artistic reasons);
* augmentation of the performance with subtitles, audio-description, * Augmentation of the performance with subtitles, audio-description,
actor-tagging, language translation, advertisements/product- actor-tagging, language translation, advertisements/product-
placement, other enhancements/filters to make the performance placement, other enhancements/filters to make the performance
accessible to disabled audience members (removal of flashing accessible to disabled audience members (removal of flashing
images for epileptics, alternative colour schemes for colour-blind images for epileptics, alternative colour schemes for colour-blind
audience members, etc.). audience members, etc.).
3.3.2. Characterization 3.3.2. Characterization
There are several chained functional entities which are candidates There are several chained functional entities which are candidates
for being deployed as (COIN) Programs. for being deployed as (COIN) Programs.
skipping to change at page 16, line 35 skipping to change at page 16, line 26
* 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:
* personalisation of the performance according to audience * Personalisation of the performance according to audience
preferences and requirements makes it unfeasible to be done in a preferences and requirements makes it unfeasible to be done in a
centralised manner at the performer premises: the computational centralised manner at the performer premises: the computational
resources and network bandwidth would need to scale with the resources and network bandwidth would need to scale with the
number of audience members' personalised streams. number of audience members' personalised streams.
* rendering of VR headset content to follow viewer head movements * Rendering of VR headset content to follow viewer head movements
has an upper bound on lag to maintain viewer QoE, which requires has an upper bound on lag to maintain viewer QoE, which requires
the processing to be undertaken sufficiently close to the viewer the processing to be undertaken sufficiently close to the viewer
to avoid large network latencies. to avoid large network latencies.
* viewer devices may not have the processing-power to undertake the * Viewer devices may not have the processing-power to undertake the
personalisation or the viewers' network may not have the capacity personalisation or the viewers' network may not have the capacity
to receive all of the constituent streams to undertake the to receive all of the constituent streams to undertake the
personalisation functions. personalisation functions.
* there are strict latency requirements for live and interactive * There are strict latency requirements for live and interactive
aspects that require the deviation from the direct network path aspects that require the deviation from the direct network path
from performers to audience to be minimised, which reduces the from performers to audience to be minimised, which reduces the
opportunity to route streams via large-scale processing opportunity to route streams via large-scale processing
capabilities at centralised data-centres. capabilities at centralised data-centres.
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 the Mobile Application Offloading, Extended Reality, and covered in the Mobile Application Offloading, Extended Reality, and
Content Delivery Networks use cases. Content Delivery Networks use cases.
skipping to change at page 17, line 41 skipping to change at page 17, line 35
setting). 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 contextual aware of flows wider (COIN) System/Environment to be contextual 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, prioritisation, treatment of the flows, e.g. path selection, prioritisation,
multi-flow coordination, synchronisation & resilience. multi-flow coordination, synchronisation & 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 personalisation functions be located? Close to the encoding and personalisation functions be located? Close to the
performers or close to the audience members? performers or close to the audience members?
* 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
audience should (COIN) programs be located, considering the audience should (COIN) programs be located, considering the
latency implications of path-stretch and the availability of latency implications of path-stretch and the availability of
processing capacity at PNDs? How should tolerances be defined by processing capacity at PNDs? How should tolerances be defined by
users? 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
skipping to change at page 19, line 9 skipping to change at page 18, line 42
(COIN) Programs. (COIN) Programs.
* Req 3.3.2: A COIN System should be able to synchronise flow * Req 3.3.2: A COIN System should be able to synchronise flow
treatment and processing across multiple related flows which may treatment and processing across multiple related flows which may
be on disjoint paths. be on disjoint paths.
4. Supporting new COIN Systems 4. Supporting new COIN Systems
While the best-effort nature of the Internet enables a wide variety While the best-effort nature of the Internet enables a wide variety
of applications, there are several domains whose requirements are of applications, there are several domains whose requirements are
hard to satisfy over regular best-effort networks. Consequently, hard to satisfy over regular best-effort networks.
there is a large number of specialized appliances and protocols
designed to provide the required strict performance guarantees, e.g., Consequently, there is a large number of specialized appliances and
regarding real-time capabilities. Time-Sensitive-Networking [TSN] as protocols designed to provide the required strict performance
an enhancement to the standard Ethernet, e.g., tries to achieve these guarantees, e.g., regarding real-time capabilities.
requirements on the link layer by statically reserving shares of the
bandwidth. However, solutions on the link layer alone are not always Time-Sensitive-Networking [TSN] as an enhancement to the standard
sufficient. Ethernet, e.g., tries to achieve these requirements on the link layer
by statically reserving shares of the bandwidth. However, solutions
on the link layer alone are not always sufficient.
The industrial domain, e.g., currently evolves towards increasingly The industrial domain, e.g., currently evolves towards increasingly
interconnected systems in turn increasing the complexity of the interconnected systems in turn increasing the complexity of the
underlying networks, making them more dynamic, and creating more underlying networks, making them more dynamic, and creating more
diverse sets of requirements. Concepts satisfying the dynamic diverse sets of requirements. Concepts satisfying the dynamic
performance requirements of modern industrial applications thus performance requirements of modern industrial applications thus
become harder to develop. In this context, COIN offers new become harder to develop. In this context, COIN offers new
possibilities as it allows to flexibly distribute computation tasks possibilities as it allows to flexibly distribute computation tasks
across the network and enables novel forms of interaction between across the network and enables novel forms of interaction between
communication and computation providers. communication and computation providers.
skipping to change at page 21, line 8 skipping to change at page 21, line 8
not designed for this array of tasks and computations could not designed for this array of tasks and computations could
theoretically be moved to more powerful devices. These devices are theoretically be moved to more powerful devices. These devices are
no longer close to the controlled objects and induce additional no longer close to the controlled objects and induce additional
latency. Moving compute functionality onto COIN execution latency. Moving compute functionality onto COIN execution
environments inside the network offers a new solution space to these environments inside the network offers a new solution space to these
challenges. challenges.
4.2.2. Characterization 4.2.2. Characterization
A control process consists of two main components as illustrated in A control process consists of two main components as illustrated in
Figure 3: a system under control and a controller. In feedback Figure 3: a system under control and a controller.
control, the current state of the system is monitored, e.g., using
sensors and the controller influences the system based on the In feedback control, the current state of the system is monitored,
difference between the current and the reference state to keep it 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. close to this reference state.
reference reference
state ------------ -------- Output state ------------ -------- Output
----------> | Controller | ---> | System | ----------> ----------> | Controller | ---> | System | ---------->
^ ------------ -------- | ^ ------------ -------- |
| | | |
| observed state | | observed state |
| --------- | | --------- |
-------------------| Sensors | <----- -------------------| Sensors | <-----
skipping to change at page 22, line 5 skipping to change at page 22, line 5
Control functionality is traditionally executed on PLCs close to the Control functionality is traditionally 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.
4.2.4. Opportunities for COIN 4.2.4. Opportunities
COIN offers the possibility of bringing the system and the controller COIN offers the possibility of bringing the system and the controller
closer together, thus possibly satisfying the latency requirements, closer together, thus possibly satisfying the latency requirements,
by performing simple control logic on PNDs and/or in COIN execution by performing simple control logic on PNDs and/or in COIN execution
environments. While control models, in general, can become involved, environments.
there is a variety of control algorithms that are composed of simple
While control models, in general, can become involved, there is a
variety of control algorithms that are composed of simple
computations such as matrix multiplication. These are supported by computations such as matrix multiplication. These are supported by
some PNDs and it is thus possible to compose simplified some PNDs and it is thus possible to compose simplified
approximations of the more complex algorithms and deploy them in the approximations of the more complex algorithms and deploy them in the
network. While the simplified versions induce a more inaccurate network. While the simplified versions induce a more inaccurate
control, they allow for a quicker response and might be sufficient to control, they allow for a quicker response and might be sufficient to
operate a basic tight control loop while the overall control can operate a basic tight control loop while the overall control can
still be exercised from the cloud. still be exercised from the cloud.
Opportunities: Opportunities:
* Execute simple (end-host) COIN functions on PNDs to satisfy tight * Execute simple (end-host) COIN functions on PNDs to satisfy tight
latency constraints of control processes latency constraints of control processes
4.2.5. Research Questions for COIN 4.2.5. Research Questions
Bringing the required computations to PNDs is challenging as these Bringing the required computations to PNDs is challenging as these
devices typically only allow for integer precision computation while devices typically only allow for integer precision computation while
floating-point precision is needed by most control algorithms. floating-point precision is needed by most control algorithms.
Additionally, computational capabilities vary for different available Additionally, computational capabilities vary for different available
PNDs [KUNZE]. Yet, early approaches like [RUETH] and [VESTIN] have PNDs [KUNZE]. Yet, early approaches like [RUETH] and [VESTIN] have
already shown the general applicability of such ideas, but there are already shown the general applicability of such ideas, but there are
still a lot of open research questions not limited to the following: still a lot of open research questions not limited to the following:
Research Questions: Research Questions:
skipping to change at page 23, line 16 skipping to change at page 23, line 16
& higher latency" (more powerful COIN execution environments, & higher latency" (more powerful COIN execution environments,
farer away), "very accurate & very high latency" (cloud farer away), "very accurate & very high latency" (cloud
environments, far away)? environments, far away)?
- Who decides which control instance is executed and how? - Who decides which control instance is executed and how?
- How do the different control instances interact? - How do the different control instances interact?
4.2.6. Requirements 4.2.6. Requirements
Req 4.2.1: The interaction between the COIN execution environments * Req 4.2.1: The interaction between the COIN execution environments
and the global controller SHOULD be explicit. and the global controller SHOULD be explicit.
Req 4.2.2: The interaction between the COIN execution environments * Req 4.2.2: The interaction between the COIN execution environments
and the global controller MUST NOT negatively impact the control and the global controller MUST NOT negatively impact the control
quality. quality.
Req 4.2.3: Actions of the COIN execution environments MUST be * Req 4.2.3: Actions of the COIN execution environments MUST be
overridable by the global controller. overridable by the global controller.
Req 4.2.4: Functions in COIN execution environments SHOULD be * Req 4.2.4: Functions in COIN execution environments SHOULD be
executed with predictable delay. executed with predictable delay.
Req 4.2.5: Functions in COIN execution environments MUST be executed * Req 4.2.5: Functions in COIN execution environments MUST be
with predictable accuracy. executed with predictable accuracy.
4.3. Large Volume Applications - Filtering 4.3. Large Volume Applications - Filtering
4.3.1. Description 4.3.1. Description
In modern industrial networks, processes and machines can be In modern industrial networks, processes and machines can be
monitored closely resulting in large volumes of available monitored closely resulting in large volumes of available
information. This data can be used to find previously unknown information. This data can be used to find previously unknown
correlations between different parts of the value chain, e.g., by correlations between different parts of the value chain, e.g., by
deploying machine learning (ML) techniques, which in turn helps to deploying machine learning (ML) techniques, which in turn helps to
skipping to change at page 25, line 22 skipping to change at page 25, line 22
4.3.3. Existing Solutions 4.3.3. Existing Solutions
Current approaches for handling such large amounts of information Current approaches for handling such large amounts of information
typically build upon stream processing frameworks such as Apache typically build upon stream processing frameworks such as Apache
Flink. While they allow for handling large volume applications, they Flink. While they allow for handling large volume applications, they
are tied to performant server machines and upscaling the information are tied to performant server machines and upscaling the information
density also requires a corresponding upscaling of the compute density also requires a corresponding upscaling of the compute
infrastructure. infrastructure.
4.3.4. Opportunities for COIN 4.3.4. Opportunities
PNDs and COIN execution environments are in a unique position to PNDs and COIN execution environments are in a unique position to
reduce the data rates due to their line-rate packet processing reduce the data rates due to their line-rate packet processing
capabilities. Using these capabilities, it is possible to filter out capabilities. Using these capabilities, it is possible to filter out
redundant or undesired data before it leaves the premise using simple redundant or undesired data before it leaves the premise using simple
traffic filters that are deployed in the on-premise network. There traffic filters that are deployed in the on-premise network. There
are different approaches to how this topic can be tackled. A first are different approaches to how this topic can be tackled.
step could be to scale down the available sensor data to the data
rate that is needed. For example, if a sensor transmits with a A first step could be to scale down the available sensor data to the
data rate that is needed. For example, if a sensor transmits with a
frequency of 5 kHz, but the control entity only needs 1 kHz, only frequency of 5 kHz, but the control entity only needs 1 kHz, only
every fifth packet containing sensor data is let through. every fifth packet containing sensor data is let through.
Alternatively, sensor data could be filtered down to a lower Alternatively, sensor data could be filtered down to a lower
frequency while the sensor value is in an uninteresting range, but frequency while the sensor value is in an uninteresting range, but
let through with higher resolution once the sensor value range let through with higher resolution once the sensor value range
becomes interesting. While the former variant is oblivious to the becomes interesting.
semantics of the sensor data, the latter variant requires an
understanding of the current sensor levels. In any case, it is While the former variant is oblivious to the semantics of the sensor
important that end-hosts are informed about the filtering so that data, the latter variant requires an understanding of the current
they can distinguish between data loss and data filtered out on sensor levels. In any case, it is important that end-hosts are
purpose. informed about the filtering so that they can distinguish between
data loss and data filtered out on purpose.
Opportunities: Opportunities:
* (Semantic) packet filtering based on packet header and payload, as * (Semantic) packet filtering based on packet header and payload, as
well as multi-packet information well as multi-packet information
4.3.5. Research Questions for COIN 4.3.5. Research Questions
* RQ 4.3.1: How to design COIN programs for (semantic) packet * RQ 4.3.1: How to design COIN programs for (semantic) packet
filtering? filtering?
- Which criteria for filtering make sense? - Which criteria for filtering make sense?
* RQ 4.3.2: How to distribute and coordinate COIN programs? * RQ 4.3.2: How to distribute and coordinate COIN programs?
* RQ 4.3.3: How to dynamically change COIN programs? * RQ 4.3.3: How to dynamically change COIN programs?
* RQ 4.3.4: How to signal traffic filtering by COIN programs to end- * RQ 4.3.4: How to signal traffic filtering by COIN programs to end-
hosts? hosts?
4.3.6. Requirements 4.3.6. Requirements
Req 4.3.1: Filters MUST conform to application-level syntax and * Req 4.3.1: Filters MUST conform to application-level syntax and
semantics. semantics.
Req 4.3.2: Filters MAY leverage packet header and payload * Req 4.3.2: Filters MAY leverage packet header and payload
information. information.
Req 4.3.3: Filters SHOULD be reconfigurable at run-time. * Req 4.3.3: Filters SHOULD be reconfigurable at run-time.
4.4. Large Volume Applications - (Pre-)Preprocessing 4.4. Large Volume Applications - (Pre-)Preprocessing
4.4.1. Description 4.4.1. Description
See Section 4.3.1. See Section 4.3.1.
4.4.2. Characterization 4.4.2. Characterization
4.4.2.1. General Characterization of Large Volume Applications 4.4.2.1. General Characterization of Large Volume Applications
skipping to change at page 27, line 5 skipping to change at page 27, line 9
simpler operations which can be done on subsets of the overall simpler operations which can be done on subsets of the overall
dataset or earlier on the communication path as soon as all data is dataset or earlier on the communication path as soon as all data is
available. One example is finding the maximum of all sensor values available. One example is finding the maximum of all sensor values
which can either be done iteratively at each intermediate hop or at which can either be done iteratively at each intermediate hop or at
the first hop, where all data is available. the first hop, where all data is available.
4.4.3. Existing Solutions 4.4.3. Existing Solutions
See Section 4.3.3. See Section 4.3.3.
4.4.4. Opportunities for COIN 4.4.4. Opportunities
Using expert knowledge about the exact computation steps and the Using expert knowledge about the exact computation steps and the
concrete transmission path of the sensor data, simple computation concrete transmission path of the sensor data, simple computation
steps can be deployed in the on-premise network to reduce the overall steps can be deployed in the on-premise network to reduce the overall
data volume and potentially speed up the processing time in the data volume and potentially speed up the processing time in the
cloud. cloud.
Related work has already shown that in-network aggregation can help Related work has already shown that in-network aggregation can help
to improve the performance of distributed ML applications [SAPIO]. to improve the performance of distributed ML applications [SAPIO].
Investigating the applicability of stream data processing techniques Investigating the applicability of stream data processing techniques
to PNDs is also interesting, because sensor data is usually streamed. to PNDs is also interesting, because sensor data is usually streamed.
Opportunities: Opportunities:
* (Semantic) data (pre-)processing, e.g., in the form of * (Semantic) data (pre-)processing, e.g., in the form of
computations across multiple packets and potentially leveraging computations across multiple packets and potentially leveraging
packet payload packet payload
4.4.5. Research Questions for COIN 4.4.5. Research Questions
* RQ 4.4.1: Which kinds of COIN programs can be leveraged for * RQ 4.4.1: Which kinds of COIN programs can be leveraged for
(pre-)processing steps? (pre-)processing steps?
- How complex can they become? - How complex can they become?
* RQ 4.4.2: How to distribute and coordinate COIN programs? * RQ 4.4.2: How to distribute and coordinate COIN programs?
* RQ 4.4.3: How to dynamically change COIN programs? * RQ 4.4.3: How to dynamically change COIN programs?
* RQ 4.4.4: How to incorporate the (pre-)processing steps into the * RQ 4.4.4: How to incorporate the (pre-)processing steps into the
overall system? overall system?
4.4.6. Requirements 4.4.6. Requirements
Req 4.4.1: Preprocessors MUST conform to application-level syntax and * Req 4.4.1: Preprocessors MUST conform to application-level syntax
semantics. and semantics.
Req 4.4.2: Preprocessors MAY leverage packet header and payload * Req 4.4.2: Preprocessors MAY leverage packet header and payload
information. information.
Req 4.4.3: Preprocessors SHOULD be reconfigurable at run-time. * Req 4.4.3: Preprocessors SHOULD be reconfigurable at run-time.
4.5. Industrial Safety 4.5. Industrial Safety
4.5.1. Description 4.5.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 traditional 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 decent level of safety. to provide a decent level of safety.
skipping to change at page 29, line 5 skipping to change at page 29, line 5
4.5.3. Existing Solutions 4.5.3. Existing Solutions
Due to the importance of safety, there is a wide range of software- Due to the importance of safety, there is a wide range of software-
based approaches aiming at enhancing security. One example are tag- based approaches aiming at enhancing security. One example are tag-
based systems, e.g., using RFID, where drivers of forklifts can be based systems, e.g., using RFID, where drivers of forklifts can be
warned if pedestrian workers carrying tags are nearby. Such warned if pedestrian workers carrying tags are nearby. Such
solutions, however, require setting up an additional system and do solutions, however, require setting up an additional system and do
not leverage existing sensor data. not leverage existing sensor data.
4.5.4. Opportunities for COIN 4.5.4. Opportunities
COIN systems could leverage the increased availability of sensor data COIN systems could leverage the increased availability of sensor data
and the detailed monitoring of the factories to enable additional and the detailed monitoring of the factories to enable additional
safety measures. Different safety indicators within the production safety measures. Different safety indicators within the production
hall can be combined within the network so that PNDs can give early hall can be combined within the network so that PNDs can give early
responses if a potential safety breach is detected. responses if a potential safety breach is detected.
One possibility could be to track the positions of human workers and One possibility could be to track the positions of human workers and
robots. Whenever a robot gets too close to a human in a non-working robots. Whenever a robot gets too close to a human in a non-working
area or if a human enters a defined safety zone, robots are stopped area or if a human enters a defined safety zone, robots are stopped
to prevent injuries. More advanced concepts could also include image to prevent injuries. More advanced concepts could also include image
data or combine arbitrary sensor data. data or combine arbitrary sensor data.
Opportunities: Opportunities:
* Execute simple (end-host) COIN functions on PNDs to create early * Execute simple (end-host) COIN functions on PNDs to create early
emergency reactions based on diverse sensor feedback emergency reactions based on diverse sensor feedback
4.5.5. Research Questions for COIN 4.5.5. Research Questions
* RQ 4.5.1: Which additional safety measures can be provided? * RQ 4.5.1: Which additional safety measures can be provided?
- Do these measures actually improve safety? - Do these measures actually improve safety?
* RQ 4.5.2: Which sensor information can be combined and how? * RQ 4.5.2: Which sensor information can be combined and how?
4.5.6. Requirements 4.5.6. Requirements
Req 4.5.1: COIN-based safety measures MUST NOT degrade existing * Req 4.5.1: COIN-based safety measures MUST NOT degrade existing
safety measures. safety measures.
Req 4.5.2: COIN-based safety measures MAY enhance existing safety * Req 4.5.2: COIN-based safety measures MAY enhance existing safety
measures. measures.
5. Improving existing COIN capabilities 5. Improving existing COIN capabilities
5.1. Content Delivery Networks 5.1. Content Delivery Networks
5.1.1. Description 5.1.1. Description
Delivery of content to end users often relies on Content Delivery Delivery of content to end users often relies on Content Delivery
Networks (CDNs) storing said content closer to end users for latency Networks (CDNs) storing said content closer to end users for latency
reduced delivery with DNS-based indirection being utilized to serve reduced delivery with DNS-based indirection being utilized to serve
skipping to change at page 30, line 26 skipping to change at page 30, line 26
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)
multicast for replication towards edge CDN nodes, can significantly multicast for replication towards edge CDN nodes, can significantly
increase the overall network and server efficiency. It also reduces increase the overall network and server efficiency. It also reduces
indirection latency for content retrieval as well as reduces required indirection latency for content retrieval as well as reduces required
edge storage capacity by benefiting from the increased network edge storage capacity by benefiting from the increased network
efficiency to renew edge content more quickly against changing efficiency to renew edge content more quickly against changing
demand. demand.
5.1.4. Opportunities and Research Questions for COIN 5.1.4. Opportunities
Opportunities:
* The support for service-level routing of requests (service routing * Supporting service-level routing of requests (service routing in
in [APPCENTRES]) to specific (COIN) program instances may improve [APPCENTRES]) to specific (COIN) program instances may improve on
on end user experience in faster retrieving (possibly also more, end user experience in faster retrieving (possibly also more,
e.g., better quality) content. e.g., better quality) content.
* Supporting the constraint-based selection of a specific (COIN) * Supporting the constraint-based selection of a specific (COIN)
program instance over others (constraint-based routing in program instance over others (constraint-based routing in
[APPCENTRES]) may improve the overall end user experience by [APPCENTRES]) may improve the overall end user experience by
selecting a 'more suitable' (COIN) program instance over another, selecting a 'more suitable' (COIN) program instance over another,
e.g., avoiding/reducing overload situation in specific (COIN) e.g., avoiding/reducing overload situation in specific (COIN)
program instances. program instances.
* Supporting Layer 2 capabilities for multicast (compute * Supporting Layer 2 capabilities for multicast (compute
interconnection and collective communication in [APPCENTRES]) may interconnection and collective communication in [APPCENTRES]) may
increase the network utilization and therefore increase the increase the network utilization and therefore increase the
overall system utilization. overall system utilization.
Research Questions: in addition to those request question for 5.1.5. Research Questions
Section 3.1,
In addition to those request question for Section 3.1:
* RQ 5.1.1: How to utilize L2 multicast to improve on CDN designs? * RQ 5.1.1: How to utilize L2 multicast to improve on CDN designs?
How to utilize in-network capabilities in those designs? How to utilize in-network capabilities in those designs?
* 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]) multicast capabilities (see [FCDN])
* RQ 5.1.3: What are the right routing constraints that reflect both * RQ 5.1.3: What are the right routing constraints that reflect both
compute and network capabilities? compute and network capabilities?
* RQ 5.1.4: Could traffic steering be performed at the data path and * RQ 5.1.4: Could traffic steering be performed at the data path and
per service request? If so, what would be performance per service request? If so, what would be performance
improvements? 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])? multicast-based, replication (see [FCDN])?
* 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? capabilities? How to overcome them?
5.1.5. Requirements 5.1.6. Requirements
Requirements 3.1.1 through 3.1.6 also apply for CDN service access. Requirements 3.1.1 through 3.1.6 also apply for CDN service access.
In addition: In addition:
Req 5.1.1: Any solution SHOULD utilize Layer 2 multicast transmission * Req 5.1.1: Any solution SHOULD utilize Layer 2 multicast
capabilities for responses to concurrent service requests. transmission capabilities for responses to concurrent service
requests.
5.2. Compute-Fabric-as-a-Service (CFaaS) 5.2. Compute-Fabric-as-a-Service (CFaaS)
5.2.1. Description 5.2.1. Description
Layer 2 connected compute resources, e.g., in regional or edge data Layer 2 connected compute resources, e.g., in regional or edge data
centres, base stations and even end-user devices, provide the centres, base stations and even end-user devices, provide the
opportunity for infrastructure providers to offer CFaaS type of opportunity for infrastructure providers to offer CFaaS type of
offerings to application providers. App and service providers may offerings to application providers. App and service providers may
utilize the compute fabric exposed by this CFaaS offering for the utilize the compute fabric exposed by this CFaaS offering for the
skipping to change at page 32, line 20 skipping to change at page 32, line 21
relationships to be built dynamically between the resource relationships to be built dynamically between the resource
provider(s) and the CFaaS provider. This also requires the provider(s) and the CFaaS provider. This also requires the
communication resources to be dynamically adjusted to interconnect communication resources to be dynamically adjusted to interconnect
all resources suitably into the (tenant-specific) fabric exposed as all resources suitably into the (tenant-specific) fabric exposed as
CFaaS. CFaaS.
5.2.3. Existing Solutions 5.2.3. Existing Solutions
NOTE: material on solutions will be added here later NOTE: material on solutions will be added here later
5.2.4. Opportunities and Research Questions for COIN 5.2.4. Opportunities
Opportunities:
* Supporting service-level routing of compute resource requests * Supporting service-level routing of compute resource requests
(service routing in [APPCENTRES]) may allow for utilizing the (service routing in [APPCENTRES]) may allow for utilizing the
wealth of compute resources in the overall CFaaS fabric for 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 (constraint-based routing in program instance over others (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 Layer 2 capabilities for multicast (compute * Supporting Layer 2 capabilities for multicast (compute
interconnection and collective communication in [APPCENTRES]) will interconnection and collective communication in [APPCENTRES]) will
allow for increasing both network utilization but also possible allow for increasing 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.
Research Questions: similar to those for Section 3.1, in addition 5.2.5. Research Questions
Similar to those for Section 3.1. In addition:
* 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 L2 fabric? creation of the L2 fabric?
* RQ 5.2.2: How to dynamically integrate resources, particularly * RQ 5.2.2: How to dynamically integrate resources, particularly
when driven by tenant-level requirements and changing service- when driven by tenant-level requirements and changing service-
specific constraints? specific constraints?
* RQ 5.2.3: How to utilize in-network capabilities to aid the * RQ 5.2.3: How to utilize in-network capabilities to aid the
availability and accountability of resources, i.e., what may be availability and accountability of resources, i.e., what may be
(COIN) programs for a CFaaS environment that in turn would utilize (COIN) programs for a CFaaS environment that in turn would utilize
the distributed execution capability of a COIN system? the distributed execution capability of a COIN system?
5.2.5. Requirements 5.2.6. Requirements
For the provisioning of services atop the CFaaS, requirements 3.1.1 For the provisioning of services atop the CFaaS, requirements 3.1.1
through 3.1.6 should be addressed, too. In addition: through 3.1.6 should be addressed, too. In addition:
Req 5.2.1: Any solution SHOULD expose means to specify the * Req 5.2.1: Any solution SHOULD expose means to specify the
requirements for the tenant-specific compute fabric being utilized requirements for the tenant-specific compute fabric being utilized
for the service execution. for the service execution.
Req 5.2.2: Any solution SHOULD allow for dynamic integration of * Req 5.2.2: Any solution SHOULD allow for dynamic integration of
compute resources into the compute fabric being utilized for the app compute resources into the compute fabric being utilized for the
execution; those resources include, but are not limited to, end user app execution; those resources include, but are not limited to,
provided resources. From a COIN system perspective, new resources end user provided resources. From a COIN system perspective, new
must be possible to be exposed as possible (COIN) execution resources must be possible to be exposed as possible (COIN)
environments. execution environments.
Req 5.2.3: Any solution MUST provide means to optimize the inter- * Req 5.2.3: Any solution MUST provide means to optimize the inter-
connection of compute resources, including those dynamically added connection of compute resources, including those dynamically added
and removed during the provisioning of the tenant-specific compute and removed during the provisioning of the tenant-specific compute
fabric. fabric.
Req 5.2.4: Any solution MUST provide means for ensuring availability * Req 5.2.4: Any solution MUST provide means for ensuring
and usage of resources is accounted for. availability and usage of resources is accounted for.
5.3. Virtual Networks Programming 5.3. Virtual Networks Programming
5.3.1. Description 5.3.1. Description
The term "virtual network programming" is proposed to describe The term "virtual network programming" is proposed to describe
mechanisms by which tenants deploy and operate COIN programs in their mechanisms by which tenants deploy and operate COIN programs in their
virtual network. Such COIN programs can for example be P4 programs, virtual network. Such COIN programs can for example be P4 programs,
OpenFlow rules, or higher layer programs. This feature can enable OpenFlow rules, or higher layer programs. This feature can enable
other use cases described in this draft to be deployed using virtual other use cases described in this draft to be deployed using virtual
skipping to change at page 35, line 47 skipping to change at page 35, line 47
Looking in more details in Figure 5, the 5GLAN P4 program can be Looking in more details in Figure 5, the 5GLAN P4 program can be
split between multiple data plane nodes (PDU Session Anchor (PSA) split between multiple data plane nodes (PDU Session Anchor (PSA)
User Plane Functions (UPF), other UPFs, or even mobile devices), User Plane Functions (UPF), other UPFs, or even mobile devices),
although in some cases the P4 program may be hosted on a single node. although in some cases the P4 program may be hosted on a single node.
In the most general case, a distributed deployment is useful to keep In the most general case, a distributed deployment is useful to keep
traffic on optimal paths, because, except in simple cases, within a traffic on optimal paths, because, except in simple cases, within a
5GLAN all traffic will not pass through a single node. In this 5GLAN all traffic will not pass through a single node. In this
example, P4 programs could be deployed in UPF1, UPF2, UPF3, UE3 and example, P4 programs could be deployed in UPF1, UPF2, UPF3, UE3 and
UE4. UE1-UE2 traffic is using a local switch on PSA UPF1, UE1-UE3 UE4. UE1-UE2 traffic is using a local switch on PSA UPF1, UE1-UE3
traffic is tunneled between PSA UPF1 and PSA UPF2 through the N19 traffic is tunneled between PSA UPF1 and PSA UPF2 through the N19
interface, and UE1-UE4 traffic is forwarded through an external Data interface, and UE1-UE4 traffic is forwarded throughan external Data
Network (DN). Traffic between Device1 and Device2 is forwarded Network (DN). Traffic between Device1 and Device2 is forwarded
through UE4. through UE4.
+-----+ +-----+ +------------+ +-----+ +-----+ +------------+
| AMF | | SMF | | Controller | | AMF | | SMF | | Controller |
+-+-+-+ +--+--+ +-----+------+ +-+-+-+ +--+--+ +-----+------+
/ | | P4| / | | P4|
+---------+ | N4| Runtime| +---------+ | N4| Runtime|
N1 / |N2 | V N1 / |N2 | V
+------+ | | (all P4 programs*) +------+ | | (all P4 programs*)
skipping to change at page 37, line 22 skipping to change at page 37, line 22
typical configuration capabilities. For example, 5G network typical configuration capabilities. For example, 5G network
evolution points to an ever increasing specialization and evolution points to an ever increasing specialization and
customization of private mobile networks, which could be handled customization of private mobile networks, which could be handled
by tenants using a programming model similar to P4. by tenants using a programming model similar to P4.
* Using network programs to influence underlying network service * Using network programs to influence underlying network service
(e.g., request specific QoS for some flows in 5G or datacenters), (e.g., request specific QoS for some flows in 5G or datacenters),
to increases the level of in-depth customization available to to increases the level of in-depth customization available to
tenants. tenants.
5.3.5. Research Questions for COIN 5.3.5. Research Questions
* RQ 5.3.1: Underlying Network Awareness: a virtual COIN program can * RQ 5.3.1: Underlying Network Awareness: a virtual COIN program can
be able to influence, and be influenced by, the underling network be able to influence, and be influenced by, the underling network
(e.g., the 5G network or data center). For example, a virtual (e.g., the 5G network or data center). For example, a virtual
COIN program may be aware of the slice used by a flow, and COIN program may be aware of the slice used by a flow, and
possibly influence slice selection. Since some information and possibly influence slice selection. Since some information and
actions may be available on some nodes and not others, underlying actions may be available on some nodes and not others, underlying
network awareness may impose additional constraints on distributed network awareness may impose additional constraints on distributed
network programs location. network programs location.
skipping to change at page 39, line 28 skipping to change at page 39, line 28
Reasoning frameworks, such as TensorFlow, may be utilized for the Reasoning frameworks, such as TensorFlow, may be utilized for the
realization of the (distributed) AI logic, building on remote service realization of the (distributed) AI logic, building on remote service
invocation through protocols such as gRPC [GRPC] or MPI [MPI] with invocation through protocols such as gRPC [GRPC] or MPI [MPI] with
the intention of providing an on-chip NPU (neural processor unit) the intention of providing an on-chip NPU (neural processor unit)
like abstraction to the AI framework. like abstraction to the AI framework.
NOTE: material on solutions like ETSI MEC and 3GPP work will be added NOTE: material on solutions like ETSI MEC and 3GPP work will be added
here later here later
6.1.4. Opportunities and Research Questions for COIN 6.1.4. Opportunities
Opportunities:
* Supporting service-level routing of requests (service routing in * Supporting service-level routing of requests (service routing in
[APPCENTRES]), with AI services being exposed to the network and [APPCENTRES]), with AI services being exposed to the network and
executed as part of (COIN) programs in selected (COIN) program executed as part of (COIN) programs in selected (COIN) program
instances, may provide a highly distributed execution of the instances, may provide a highly distributed execution of the
overall AI logic, thereby addressing, e.g., localization but also overall AI logic, thereby addressing, e.g., localization but also
computational concerns (scale-in/out). computational concerns (scale-in/out).
* The support for constraint-based selection of a specific (COIN) * The support for constraint-based selection of a specific (COIN)
program instance over others (constraint-based routing in program instance over others (constraint-based routing in
skipping to change at page 39, line 52 skipping to change at page 40, line 5
capabilities (e.g., support for specific AI HW assistance in the capabilities (e.g., support for specific AI HW assistance in the
COIN element, including a PND), while also allowing to select COIN element, including a PND), while also allowing to select
resources, e.g., based on available compute ability such as number resources, e.g., based on available compute ability such as number
of cores to be used. of cores to be used.
* 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.
Research Questions: 6.1.5. Research Questions
* RQ 6.1.1: similar to use case in Section 3.1 * RQ 6.1.1: similar to use case in Section 3.1
* RQ 6.1.2: What are the communication patterns that may be * RQ 6.1.2: What are the communication patterns that may be
supported by collective communication solutions? supported by collective communication solutions?
* RQ 6.1.3: How to achieve scalable multicast delivery with rapidly * RQ 6.1.3: How to achieve scalable multicast delivery with rapidly
changing receiver sets? changing receiver sets?
* RQ 6.1.4: What in-network capabilities may support the collective * RQ 6.1.4: What in-network capabilities may support the collective
communication patterns found in distributed AI problems? communication patterns found in distributed AI problems?
* RQ 6.1.5: How to provide a service routing capability that * RQ 6.1.5: How to provide a service routing capability that
supports any invocation protocol (beyond HTTP)? supports any invocation protocol (beyond HTTP)?
6.1.5. Requirements 6.1.6. Requirements
Requirements 3.1.1 through 3.1.6 also apply for general distributed Requirements 3.1.1 through 3.1.6 also apply for general distributed
AI capabilities. In addition: AI capabilities. In addition:
Req 6.1.1: Any COIN system MUST provide means to specify the * Req 6.1.1: Any COIN system MUST provide means to specify the
constraints for placing (AI) execution logic in the form of (COIN) constraints for placing (AI) execution logic in the form of (COIN)
programs in certain logical execution points (and their associated programs in certain logical execution points (and their associated
physical locations), including PNDs. physical locations), including PNDs.
Req 6.1.2: Any COIN system MUST provide support for app/micro-service * Req 6.1.2: Any COIN system MUST provide support for app/micro-
specific invocation protocols for requesting (COIN) program services service specific invocation protocols for requesting (COIN)
exposed to the COIN system. program services exposed to the COIN system.
7. Analysis 7. Analysis
The goal of this analysis is to identify aspects that are relevant The goal of this analysis is to identify aspects that are relevant
across all use cases to help in shaping the research agenda of across all use cases to help in shaping the research agenda of
COINRG. For this purpose, this section will condense the COINRG. For this purpose, this section will condense the
opportunities, research questions, as well as requirements of the opportunities, research questions, as well as requirements of the
different presented use cases and analyze these for similarities different presented use cases and analyze these for similarities
across the use cases. across the use cases.
Through this, we intend to identify cross-cutting opportunities, Through this, we intend to identify cross-cutting opportunities,
research questions as well as requirements (for COIN system research questions as well as requirements (for COIN system
solutions) that may aid the future work of COINRG as well as the solutions) that may aid the future work of COINRG as well as the
larger research community. larger research community.
7.1. Opportunities
To be added later.
7.2. Research Questions
After carefully considering the different use cases along with their
research questions, we propose the following layered categorization
to structure the content of the research questions which we
illustrate in Figure 6.
+--------------------------------------------------------------+
+ Applicability Areas +
+ .............................................................+
+ Transport | App | Data | Routing & | (Industrial) +
+ | Design | Processing | Forwarding | Control +
+--------------------------------------------------------------+
+--------------------------------------------------------------+
+ Distributed Computing FRAMEWORKS and LANGUAGES to COIN +
+--------------------------------------------------------------+
+--------------------------------------------------------------+
+ ENABLING TECHNOLOGIES for COIN +
+--------------------------------------------------------------+
+--------------------------------------------------------------+
+ VISION(S) for COIN +
+--------------------------------------------------------------+
Figure 6: Research Questions Categorization
7.2.1. Categorization
Three categories deal with concretizing fundamental building blocks
of COIN and COIN itself.
* VISION(S) for COIN: Questions that aim at defining and shaping the
exact scope of COIN.
* ENABLING TECHNOLOGIES for COIN: Questions that target the
capabilities of the technologies and devices intended to be used
in COIN.
* Distributed Computing FRAMEWORKS and LANGUAGES to COIN: Questions
that aim at concretizing how a framework or languages for
deploying and operating COIN systems might look like.
Additionally, there are use-case near research questions that are
heavily influenced by the specific constraints and goals of the use
cases. We call this category "applicability areas" and refine it
into the following subgroups:
* Transport:
* App Design:
* Data Processing:
* Routing & Forwarding:
* (Industrial) Control
7.2.2. Analysis
7.2.2.1. VISION(S) for COIN
The following research questions presented in the use cases belong to
this category:
3.1.8, 3.2.1, 3.3.5, 3.3.6, 3.3.7, 5.3.3, 6.1.2, 6.1.4
The research questions centering around the COIN VISION dig into what
is considered COIN and what scope COIN functionality should have. In
contrast to the ENABLING TECHNOLOGIES, this section looks at the
problem from a more philosophical perspective.
7.2.2.1.1. Where to perform computations
The first aspect of this is where/on which devices COIN programs
will/should be executed (3.3.5). In particular, it is debatable
whether COIN programs will/should only be executed in PNDs or whether
other "adjacent" computational nodes are also in scope. In case of
the latter, an arising question is whether such computations are
still to be considered as "in-network processing" and where the exact
line is between "in-network processing" and "routing to end systems"
(3.3.7). In this context, it is also interesting to reason about the
desired feature sets of PNDs (and other COIN execution environments)
as these will shift the line between "in-network processing" and
"routing to end systems" (3.1.8).
7.2.2.1.2. Are tasks suitable for COIN
Digging deeper into the desired feature sets, some research questions
address the question of which domains are to be considered of
interest/relevant to COIN. For example, whether computationally-
intensive tasks are suitable candidates for (COIN) Programs (3.3.6).
7.2.2.1.3. (Is COIN)/(What parts of COIN are) suitable for the tasks
Turning the previous aspect around, some questions try to reason
whether COIN can be sensibly used for specific tasks. For example,
it is a question of whether current PNDs are fast and expressive
enough for complex filtering operations (3.2.1).
There are also more general notions of this question, e.g., what "in-
network capabilities" might be used to address certain problem
patterns (6.1.4) and what new patterns might be supported (6.1.2).
What is interesting about these different questions is that the
former raises the question of whether COIN can be used for specific
tasks while the latter asks which tasks in a larger domain COIN might
be suitable for.
7.2.2.1.4. What are desired forms for deploying COIN functionality
The final topic addressed in this part deals with the deployment
vision for COIN programs (5.3.3).
In general, multiple programs can be deployed on a single PND/COIN
element. However, to date, multi-tenancy concepts are, above all,
available for "end-host-based" platforms, and, as such, there are
manifold questions centering around (1) whether multi-tenancy is
desirable for PNDs/COIN elements and (2) how exactly such
functionality should be shaped out, e.g., which (new forms of)
hardware support needs to be provided by PNDs/COIN elements.
7.2.2.2. ENABLING TECHNOLOGIES for COIN
The following research questions presented in the use cases belong to
this category:
3.1.7, 3.1.8, 3.2.2, 4.3.4, 4.4.4, 5.1.1, 5.1.2, 5.1.6, 5.3.1, 6.1.3,
6.1.4,
The research questions centering around the ENABLING TECHNOLOGIES for
COIN dig into what technologies are needed to enable COIN, which of
the existing technologies can be reused for COIN and what might be
needed to make the VISION(S) for COIN a reality. In contrast to the
VISION(S), this section looks at the problem from a practical
perspective.
7.2.2.2.1. COIN compute technologies
Picking up on the topics discussed in Section 7.2.2.1.1 and
Section 7.2.2.1.2, this category deals with how such technologies
might be realized in PNDs and with which functionality should even be
realized (3.1.8).
7.2.2.2.2. Forwarding technology
Another group of research questions focuses on "traditional"
networking tasks, i.e., L2/L3 switching and routing decisions.
For example, how COIN-powered routing decisions can be provided at
line-rate (3.1.7). Similarly, how (L2) multicast can be used for
COIN (vice versa) (5.1.1), which (new) forwarding capabilities might
be required within PNDs to support the concepts (5.1.2), and how
scalability limits of existing multicast capabilities might be
overcome using COIN (5.1.6).
In this context, it is also interesting how these technologies can be
used to address quickly changing receiver sets (6.1.3), especially in
the context of collective communication (6.1.4).
7.2.2.2.3. Incorporating COIN in existing systems
Some research questions deal with questions around how COIN
(functionality) can be included in existing systems.
For example, if COIN is used to perform traffic filtering, how end-
hosts can be made aware that data/information/traffic is deliberately
withheld (4.3.4). Similarly, if data is pre-processed by COIN, how
can end-hosts be signaled the new semantics of the received data
(4.4.4).
In particular, these are not only questions concerning the
functionality scope of PNDs or protocols but might also depend on how
programming frameworks for COIN are designed. Overall, this category
deals with how to handle knowledge and action imbalances between
different nodes within COIN networks (5.3.1).
7.2.2.2.4. Enhancing device interoperability
Finally, the increasing diversity of devices within COIN raises
interesting questions of how the capabilities of the different
devices can be combined and optimized (3.2.2).
7.2.2.3. Distributed Computing FRAMEWORKS and LANGUAGES to COIN
The following research questions presented in the use cases belong to
this category:
3.1.1, 3.2.3, 3.3.1, 3.3.2, 3.3.3, 3.3.5, 4.2.1, 4.2.2, 4.3.2/4.4.2,
4.3.3/4.4.3, 4.3.4, 4.4.4, 5.2.1, 5.2.2, 5.2.3, 5.3.1, 5.3.2, 5.3.3,
5.3.4, 5.3.5,
This category mostly deals with how COIN programs can be deployed and
orchestrated.
7.2.2.3.1. COIN program composition
One aspect of this topic is how the exact functional scope of COIN
programs can/should be defined. For example, it might be an idea to
define an "overall" program that then needs to be deployed to several
devices (5.3.2). In that case, how should this composition be done:
manually or automatically? Further aspects to consider here are how
the different computational capabilities of the available devices can
be taken into account and how these can be leveraged to obtain
suitable distributed versions of the overall program (4.2.1).
In particular, it is an open question of how "service-level"
frameworks can be combined with "app-level" packaging methods (3.1.1)
or whether virtual network models can help facilitate the composition
of COIN programs (5.3.5). This topic also again includes the
considerations regarding multi-tenancy support (5.3.3, cf.
Section 7.2.2.1.4) as such function distribution might necessitate
deploying functions of several entities on a single device.
7.2.2.3.2. COIN function placement
In this context, another interesting aspect is where exactly
functions should be placed and who should influence these decisions.
Such function placement could, e.g., be guided by the available
devices (3.3.5, c.f. Section 7.2.2.1.1) and their position with
regards to the communicating entities (3.3.1), and it could also be
specified in terms of the "distance" from the "direct" network path
(3.3.2).
However, it might also be an option to leave the decision to users or
at least provide means to express requirements/constraints (3.3.3).
Here, the main question is how tenant-specific requirements can
actually be conveyed (5.2.1).
7.2.2.3.3. COIN function deployment
Once the position for deployment is fixed, a next problem that arises
is how the functions can actually be deployed (4.3.2,4.4.2). Here,
first relevant questions are how COIN programs/program instances can
be identified (3.1.4) and how preferences for specific COIN program
instances can be noted (3.1.5). It is then interesting to define how
different COIN program can be coordinated (4.3.2,4.4.2), especially
if there are program dependencies (4.2.2, cf. Section 7.2.2.3.1).
7.2.2.3.4. COIN dynamic system operation
In addition to static solutions to the described problems, the
increasing dynamics of today's networks will also require dynamic
solutions. For example, it might be necessary to dynamically change
COIN programs at run-time (4.3.3, 4.4.3) or to include new resources,
especially if service-specific constraints or tenant requirements
change (5.2.2). It will be interesting to see if COIN frameworks can
actually support the sometimes required dynamic changes (3.2.4). In
this context, providing availability and accountability of resources
can also be an important aspect.
7.2.2.3.5. COIN system integration
COIN systems will potentially not only exist in isolation, but will
have to interact with existing systems. Thus, there are also several
questions addressing the integration of COIN systems into existing
ones. As already described in Section 7.2.2.2.3, the semantics of
changes made by COIN programs, e.g., filtering packets or changing
payload, will have to be communicated to end-hosts (4.3.4,4.4.4).
Overall, there has to be a common middleground so that COIN systems
can provide new functionality while not breaking "legacy" systems.
How to bridge different levels of "network awareness" (5.3.1) in an
explicit and general manner might be a crucial aspect to investigate.
7.2.2.3.6. COIN system properties - optimality, security and more
A final category deals with meta objectives that should be tackled
while thinking about how to realize the new concepts. In particular,
devising strategies for achieving an optimal function allocation/
placement are important to effectively the high heterogeneity of the
involved devices (3.2.3).
On another note, security in all its facets needs to be considered as
well, e.g., how to protect against misuse of the systems,
unauthorized traffic and more (5.3.4). We acknowledge that these
issues are not yet discussed in detail in this document.
7.2.2.4. Applicability Area - Transport
The following research questions presented in the use cases belong to
this category:
3.1.2
Further research questions concerning transport solutions are
discussed in more detail in [TRANSPORT].
Today's transport protocols are generally intended for end-to-end
communications. Thus, one important question is how COIN program
interactions should be handled, especially if the deployment
locations of the program instances change (quickly) (3.1.2).
7.2.2.5. Applicability Area - App Design
The following research questions presented in the use cases belong to
this category:
4.3.1, 5.1.1, 5.1.3, 5.1.5
The possibility of incorporating COIN resources into application
programs increases the scope for how applications can be designed and
implemented. In this context, the general question of how the
applications can be designed and which (low-level) triggers could be
included in the program logic comes up (4.3.1). Similarly, providing
sensible constraints to route between compute and network
capabilities (when both kinds of capabilities are included) is also
important (5.1.3). Many of these considerations boil down to a
question of trade-off, e.g, between storage and frequent updates
(5.1.5), and how (new) COIN capabilities can be sensibly used for
novel application design (5.1.1).
7.2.2.6. Applicability Area - Data Processing
The following research questions presented in the use cases belong to
this category:
3.2.3, 4.4.1, 4.5.2
Many of the use cases deal with novel ways of processing data using
COIN. Interesting questions in this context are which types of COIN
programs can be used to (pre-)process data (4.4.1) and which parts of
packet information can be used for these processing steps, e.g.,
payload vs. header information (4.5.2). Additionally, data
processing within COIN might even be used to support a better
localization of the COIN functionality (3.2.3).
7.2.2.7. Applicability Area - Routing & Forwarding
The following research questions presented in the use cases belong to
this category:
3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.1.6, 5.1.2, 5.1.3, 5.1.4, 6.1.5,
Being a central functionality of traditional networking devices,
routing and forwarding are also prime candidates to profit from
enhanced COIN capabilities. In this context, a central question,
also raised as part of the framework in Section 7.2.2.3.3, is how
different COIN entities can be identified (3.1.4) and how the choice
for a specific instance can be signalled (3.1.5). Building upon
this, next questions are which constraints could be used to make the
forwarding/routing decisions (5.1.3), how these constraints can be
signalled in a scalable manner (3.1.3), and how quickly changing COIN
program locations can be included in these concepts, too (3.1.2).
Once specific instances are chosen, higher-level questions revolve
around "affinity". In particular, how affinity on service-level can
be provided (3.1.6), whether traffic steering should actually be
performed on this level of granularity or rather on a lower level
(5.1.4) and how invocation for arbitrary application-level protocols,
e.g., beyond HTTP, can be supported (6.1.5). Overall, a question is
what specific forwarding methods should or can be supported using
COIN (5.1.2).
7.2.2.8. Applicability Area - (Industrial) Control
The following research questions presented in the use cases belong to
this category:
3.2.4, 3.3.1, 3.3.4, 4.2.1, 4.4.1, 4.5.1
The final applicability area deals with use cases exercising some
kind of control functionality. These processes, above all, require
low latencies and might thus especially profit from COIN
functionality. Consequently, the aforementioned question of function
placement (cf. Section 7.2.2.3.2, e.g., close to one of the end-
points or deep in the network, is also a very relevant question for
this category of applications (3.3.1).
Focusing more explicitly on control processes, one idea is to deploy
different controllers with different control granularities within a
COIN system. On the one hand, it is an interesting question how
these controllers with different granularities can be derived based
on one original controller (4.2.1). On the other hand, how to
achieve synchronisation between these controllers or, more generally,
between different entities or flows/streams within the COIN system is
also a relevant problem (3.3.4). Finally, it is still to be found
out whether using COIN for such control processes indeed improves the
existing systems, e.g., in terms of safety (4.5.1) or in terms of
performance (3.2.4).
7.3. Requirements
To be added later.
8. Security Considerations 8. Security Considerations
Note: This section will need consolidation once new use cases are Note: This section will need consolidation once new use cases are
added to the draft. Current in-network computing approaches added to the draft. Current in-network computing approaches
typically work on unencrypted plain text data because today's typically work on unencrypted plain text data because today's
networking devices usually do not have crypto capabilities. As is networking devices usually do not have crypto capabilities.
already mentioned in Section 4.3.2, this above all poses problems
when business data, potentially containing business secrets, is As is already mentioned in Section 4.3.2, this above all poses
streamed into remote computing facilities and consequently leaves the problems when business data, potentially containing business secrets,
control of the company. Insecure on-premise communication within the is streamed into remote computing facilities and consequently leaves
company and on the shop-floor is also a problem as machines could be the control of the company. Insecure on-premise communication within
intruded from the outside. It is thus crucial to deploy security and the company and on the shop-floor is also a problem as machines could
authentication functionality on on-premise and outgoing communication be intruded from the outside.
although this might interfere with in-network computing approaches.
Ways to implement and combine security measures with in-network It is thus crucial to deploy security and authentication
computing are described in more detail in [I-D.fink-coin-sec-priv]. functionality on on-premise and outgoing communication although this
might interfere with in-network computing approaches. Ways to
implement and combine security measures with in-network computing are
described in more detail in [I-D.fink-coin-sec-priv].
9. IANA Considerations 9. IANA Considerations
N/A N/A
10. Conclusion 10. Conclusion
There are several domains that can profit from capabilities that are This draft presented use cases gathererd from several fields that can
provided by in-network and generally distributed compute and could profit from capabilities that are provided by in-network
capabilities. In this draft, we differentiated use cases in which and, more generally, distributed compute capabilities. We
COIN capabilities may enable new experiences, while others may expose distinguished between use cases in which COIN may (i) enable new
new or improve on existing system capabilities, while yet other use experiences, (ii) expose new features or (iii) improve on existing
cases may see COIN capabilities enable new enviroments, such as in system capabilities, and (iv) other use cases where COIN capabilities
industrial networking. enable totally new applications, for example, in industrial
networking.
Beyond the mere description and characterization of those use cases, Beyond the mere description and characterization of those use cases,
we identified opportunities arising from utilizing COIN capabilities we identified opportunities arising from utilizing COIN capabilities
as well as research questions that may need to be addressed to reap as well as research questions that may need to be addressed to reap
those opportunities. Lastly, we also outlined possible requirements those opportunities. We also outlined possible requirements for
for realizing a COIN system at some point. realizing a COIN system addressing these use cases.
Our analysis across all use cases in those dimensions of But of course this is only a snapshot of the potential COIN use
opportunities, research questions and requirements targets the cases. In fact, the decomposition of many current client server
support for future work in this space and is therefore directly applications into node by node transit could identify other
positioned as input into the initial milestones of the COIN RG. opportunities for adding computing to forwarding notably in supply-
chain, health care, intelligent cities and transportation and even
financial services (amonsts others). As these become better defined
they will be added to the list presented here. We are, however,
confident that our analysis across all use cases in those dimensions
of opportunities, research questions, and requirements has identified
commonalities that will support future work in this space. Hence,
the use cases presented are directly positioned as input into the
milestones of the COIN RG in terms of required functionalities.
11. List of Use Case Contributors 11. List of Use Case Contributors
* Dirk Trossen has contributed the following use cases: Section 3.1, * Dirk Trossen has contributed the following use cases: Section 3.1,
Section 5.1, Section 5.2, Section 6.1. Section 5.1, Section 5.2, Section 6.1.
* Marie-Jose Montpetit has contributed the XR use case * Marie-Jose Montpetit has contributed the XR use case
(Section 3.2). (Section 3.2).
* David Griffin and Miguel Rio have contributed the use case on * David Griffin and Miguel Rio have contributed the use case on
skipping to change at page 42, line 44 skipping to change at page 51, line 21
04.txt>. 04.txt>.
[FCDN] Al-Naday, M., Reed, M.J., Riihijarvi, J., Trossen, D., [FCDN] Al-Naday, M., Reed, M.J., Riihijarvi, J., Trossen, D.,
Thomos, N., and M. Al-Khalidi, "A Flexible and Efficient Thomos, N., and M. Al-Khalidi, "A Flexible and Efficient
CDN Infrastructure without DNS Redirection of Content CDN Infrastructure without DNS Redirection of Content
Reflection", <https://arxiv.org/pdf/1803.00876.pdf>. Reflection", <https://arxiv.org/pdf/1803.00876.pdf>.
[GLEBKE] Glebke, R., Henze, M., Wehrle, K., Niemietz, P., Trauth, [GLEBKE] Glebke, R., Henze, M., Wehrle, K., Niemietz, P., Trauth,
D., Mattfeld MBA, P., and T. Bergs, "A Case for Integrated D., Mattfeld MBA, P., and T. Bergs, "A Case for Integrated
Data Processing in Large-Scale Cyber-Physical Systems", Data Processing in Large-Scale Cyber-Physical Systems",
Proceedings of the 52nd Hawaii International Conference on Proceedings of the Annual Hawaii International Conference
System Sciences, DOI 10.24251/hicss.2019.871, 2019, on System Sciences, DOI 10.24251/hicss.2019.871, 2019,
<https://doi.org/10.24251/hicss.2019.871>. <https://doi.org/10.24251/hicss.2019.871>.
[GRPC] "High performance open source universal RPC framework", [GRPC] "High performance open source universal RPC framework",
<https://grpc.io/>. <https://grpc.io/>.
[I-D.draft-kutscher-coinrg-dir] [I-D.draft-kutscher-coinrg-dir]
Kutscher, D., Kaerkkaeinen, T., and J. Ott, "Directions Kutscher, D., Kaerkkaeinen, T., and J. Ott, "Directions
for Computing in the Network", Work in Progress, Internet- for Computing in the Network", Work in Progress, Internet-
Draft, draft-kutscher-coinrg-dir-02, 31 July 2020, Draft, draft-kutscher-coinrg-dir-02, 31 July 2020,
<https://www.ietf.org/archive/id/draft-kutscher-coinrg- <https://www.ietf.org/archive/id/draft-kutscher-coinrg-
skipping to change at page 44, line 47 skipping to change at page 53, line 16
Programmable Switches", ACM P4 Workshop in Europe Programmable Switches", ACM P4 Workshop in Europe
(EuroP4'20) , 2020, (EuroP4'20) , 2020,
<https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf>. <https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf>.
[Sultana] Sultana, N., Sonchack, J., Giesen, H., Pedisich, I., Han, [Sultana] Sultana, N., Sonchack, J., Giesen, H., Pedisich, I., Han,
Z., Shyamkumar, N., Burad, S., DeHon, A., and B.T. Loo, Z., Shyamkumar, N., Burad, S., DeHon, A., and B.T. Loo,
"Flightplan: Dataplane Disaggregation and Placement for P4 "Flightplan: Dataplane Disaggregation and Placement for P4
Programs", 2020, Programs", 2020,
<https://flightplan.cis.upenn.edu/flightplan.pdf>. <https://flightplan.cis.upenn.edu/flightplan.pdf>.
[TRANSPORT]
Kunze, I., Wehrle, K., and D. Trossen, "Transport Protocol
Issues of In-Network Computing Systems", Work in Progress,
Internet-Draft, draft-kunze-coinrg-transport-issues-05, 25
October 2021, <https://www.ietf.org/archive/id/draft-
kunze-coinrg-transport-issues-05.txt>.
[TS23.501] 501, 3gpp-23., "Technical Specification Group Services and [TS23.501] 501, 3gpp-23., "Technical Specification Group Services and
System Aspects; System Architecture for the 5G System; System Aspects; System Architecture for the 5G System;
Stage 2 (Rel.17)", 3GPP , 2021, Stage 2 (Rel.17)", 3GPP , 2021,
<https://www.3gpp.org/DynaReport/23501.htm>. <https://www.3gpp.org/DynaReport/23501.htm>.
[TS23.502] 502, 3gpp-23., "Technical Specification Group Services and [TS23.502] 502, 3gpp-23., "Technical Specification Group Services and
System Aspects; Procedures for the 5G System; Stage 2 System Aspects; Procedures for the 5G System; Stage 2
(Rel.17)", 3GPP , 2021, (Rel.17)", 3GPP , 2021,
<https://www.3gpp.org/DynaReport/23502.htm>. <https://www.3gpp.org/DynaReport/23502.htm>.
 End of changes. 125 change blocks. 
338 lines changed or deleted 757 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/