| Internet-Draft | COIN Use Case Analysis | July 2023 |
| Hong, et al. | Expires 11 January 2024 | [Page] |
Computing in the Network (COIN) has the potential to enable a wide variety of use cases. The diversity in use cases makes challenges in defining general considerations. This document analyzes the use cases described in its companion document and potentially explores additional settings, to identify general aspects of interest across all use cases. The insights gained from this analysis will guide future COIN discussions.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 January 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The Internet was designed as a best-effort packet network that offers limited guarantees regarding the timely and successful transmission of packets. Data manipulation, computation, and more complex protocol functionalities are generally provided by the end-hosts, while network nodes are kept simple and only offer a "store and forward" packet facility. This design choice has shown suitable for a wide variety of applications and has helped in the rapid growth of the Internet.¶
COIN(Computing in the Network) fundamentally changes these observations by proposing to add meaningful compute functionalities within the network and thus between the end-hosts. However, building solutions for COIN-related problems is non-trivial, as there is currently no consensus on what exactly COIN is. In this context, the companion document [USECASES] provides a variety of use cases representing meaningful applications of COIN. While the document [USECASES] proposes a taxonomy to structure the descriptions of the different use cases, it does not provide further considerations; for example, it does not analyze the similarities of the different use cases and does not draw general conclusions.¶
This document fills that gap by performing an analysis of the use cases described in [USECASES] as well as additional ones. In the following, Section 2 presents general terminology that is maintained in [TERMINOLOGY]. Section 3 then describes the taxonomy used in [USECASES] for describing the use cases. The rest of the document then provides the actual analysis, dividing the overall analysis into a few, more focused, smaller analyses.¶
This document uses the terminology outlined in [TERMINOLOGY].¶
With the expansion of the Internet, there are more and more fields that require more than best-effort forwarding including strict performance guarantees or closed-loop integration to manage data flows. In this context, allowing for a tighter integration of computing and networking resources, enabling a more flexible distribution of computation tasks across the network, e.g., beyond 'just' endpoints, may help to achieve the desired guarantees and behaviors as well as increase overall performance. The vision of 'in-network computing' and the provisioning of such capabilities that capitalize on joint computation and communication resource usage throughout the network is core to the efforts in the COIN RG; we refer to those capabilities as 'COIN capabilities' in the remainder of the document.¶
Such vision of 'in-network computing' can be best outlined along four dimensions of use cases, namely those that (i) provide new user experiences through the utilization of COIN capabilities (referred to as 'COIN experiences'), (ii) enable new COIN systems, e.g., through new interactions between communication and compute providers, (iii) improve on already existing COIN capabilities and (iv) enable new COIN capabilities. Sections 3 through 6 capture those categories of use cases and provide the main 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 some individual examples within each of the above categories, the objective is to outline opportunities and propose possible research questions for consideration by the wider community when pushing forward the 'in-network computing' vision. Furthermore, the individual use case descriptions aim to provide insights into the evolving solution space of collected COIN capabilities, thereby identifying possible requirements. As a result, we present the following taxonomy, which is used to describe each of the use cases:¶
The goal of this analysis is to identify aspects that are relevant across all use cases, thereby contributing to the shaping the research agenda of COINRG. For this purpose, this section will condense the opportunities, research questions, as well as requirements of the different presented use cases and analyze these for similarities across the use cases.¶
Through this, we intend to identify cross-cutting opportunities, research questions as well as requirements (for COIN system solutions) that can provide valuable insights for both the future work of COINRG and the broader research community.¶
When referring to specific research questions (RQ) or requirements (Req), we use the corresponding identifiers from [USECASES].¶
To be added later.¶
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 1.¶
+--------------------------------------------------------------+ + 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 + +--------------------------------------------------------------+
Three categories deal with concretizing fundamental building blocks of COIN and COIN itself.¶
In addition to these categories, there are use-case-specific research questions that are heavily influenced by the specific constraints and objectives of the respective use cases. These questions fall into the "applicability areas" category and can be further refined into the following subgroups:¶
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.1, 6.1.3¶
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.¶
The first aspect of this is where/on which devices COIN programs will/should be executed (RQ 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" (RQ 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" (RQ 3.1.8).¶
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 (RQ 3.3.6).¶
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 (RQ 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 (RQ 6.1.3) and what new patterns might be supported (RQ 6.1.1). 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.¶
The final topic addressed in this part deals with the deployment vision for COIN programs (RQ 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.¶
The following research questions presented in the use cases belong to this category:¶
3.1.7, 3.1.8, 3.2.3, 4.2.6, 5.1.1, 5.1.2, 5.1.6, 5.3.1, 6.1.2, 6.1.3,¶
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.¶
Picking up on the topics discussed in Section 4.2.2.1.1 and Section 4.2.2.1.2, this category deals with how such technologies might be realized in PNDs and with which functionality should even be realized (RQ 3.1.8).¶
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 (RQ 3.1.7). Similarly, how (L2) multicast can be used for COIN (vice versa) (RQ 5.1.1), which (new) forwarding capabilities might be required within PNDs to support the concepts (RQ 5.1.2), and how scalability limits of existing multicast capabilities might be overcome using COIN (RQ 5.1.6).¶
In this context, it is also interesting how these technologies can be used to address quickly changing receiver sets (RQ 6.1.2), especially in the context of collective communication (RQ 6.1.3).¶
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. Similarly, if data is pre-processed by COIN, how can end-hosts be signaled the new semantics of the received data (RQ 4.2.6).¶
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 (RQ 5.3.1).¶
Finally, the increasing diversity of devices within COIN raises interesting questions of how the capabilities of the different devices can be combined and optimized (RQ 3.2.3).¶
The following research questions presented in the use cases belong to this category:¶
3.1.1, 3.2.4, 3.3.1, 3.3.2, 3.3.3, 3.3.5, 4.1.1, 4.1.2, 4.2.4, 4.2.5, 4.2.6, 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.¶
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 (RQ 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 (RQ 4.1.1).¶
In particular, it is an open question of how "service-level" frameworks can be combined with "app-level" packaging methods (RQ 3.1.1) or whether virtual network models can help facilitate the composition of COIN programs (RQ 5.3.5). This topic also again includes the considerations regarding multi-tenancy support (RQ 5.3.3, cf. Section 4.2.2.1.4) as such function distribution might necessitate deploying functions of several entities on a single device.¶
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 (RQ 3.3.5, c.f. Section 4.2.2.1.1) and their position with regards to the communicating entities (RQ 3.3.1), and it could also be specified in terms of the "distance" from the "direct" network path (RQ 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 (RQ 3.3.3). Here, the main question is how tenant-specific requirements can actually be conveyed (RQ 5.2.1).¶
Once the position for deployment is fixed, a next problem that arises is how the functions can actually be deployed (RQ 4.2.4). Here, first relevant questions are how COIN programs/program instances can be identified (RQ 3.1.4) and how preferences for specific COIN program instances can be noted (RQ 3.1.5). It is then interesting to define how different COIN program can be coordinated (RQ 4.2.4), especially if there are program dependencies (RQ 4.1.2, cf. Section 4.2.2.3.1).¶
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 (RQ 4.2.5) or to include new resources, especially if service-specific constraints or tenant requirements change (RQ 5.2.2). It will be interesting to see if COIN frameworks can actually support the sometimes required dynamic changes (RQ 3.2.4). In this context, providing availability and accountability of resources can also be an important aspect.¶
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 4.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 (RQ 4.2.6). 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" (RQ 5.3.1) in an explicit and general manner might be a crucial aspect to investigate.¶
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 (RQ 3.2.4).¶
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 (RQ 5.3.4). We acknowledge that these issues are not yet discussed in detail in this document.¶
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] and [TRANSPORT-PAPER].¶
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) (RQ 3.1.2).¶
The following research questions presented in the use cases belong to this category:¶
4.2.2, 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 (RQ 4.2.2). Similarly, providing sensible constraints to route between compute and network capabilities (when both kinds of capabilities are included) is also important (RQ 5.1.3). Many of these considerations boil down to a question of trade-off, e.g, between storage and frequent updates (RQ 5.1.5), and how (new) COIN capabilities can be sensibly used for novel application design (RQ 5.1.1).¶
The following research questions presented in the use cases belong to this category:¶
3.2.4, 4.2.3, 4.3.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 (RQ 4.2.3) and which parts of packet information can be used for these processing steps, e.g., payload vs. header information (RQ 4.3.2). Additionally, data processing within COIN might even be used to support a better localization of the COIN functionality (RQ 3.2.4).¶
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.4,¶
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 4.2.2.3.3, is how different COIN entities can be identified (RQ 3.1.4) and how the choice for a specific instance can be signalled (RQ 3.1.5). Building upon this, next questions are which constraints could be used to make the forwarding/routing decisions (RQ 5.1.3), how these constraints can be signalled in a scalable manner (RQ 3.1.3), and how quickly changing COIN program locations can be included in these concepts, too (RQ 3.1.2).¶
Once specific instances are chosen, higher-level questions revolve around "affinity". In particular, how affinity on service-level can be provided (RQ 3.1.6), whether traffic steering should actually be performed on this level of granularity or rather on a lower level (RQ 5.1.4) and how invocation for arbitrary application-level protocols, e.g., beyond HTTP, can be supported (RQ 6.1.4). Overall, a question is what specific forwarding methods should or can be supported using COIN (RQ 5.1.2).¶
The following research questions presented in the use cases belong to this category:¶
3.2.5, 3.3.1, 3.3.4, 4.1.1, 4.2.3, 4.3.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 4.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 (RQ 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 (RQ 4.1.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 (RQ 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 (RQ 4.3.1) or in terms of performance (RQ 3.2.5).¶
To be added later.¶
This draft analyzes the COIN use cases described in [USECASES].¶