idnits 2.17.1 draft-kunze-coin-industrial-use-cases-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 November 2020) is 1270 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-sarathchandra-coin-appcentres-03 == Outdated reference: A later version (-03) exists of draft-fink-coin-sec-priv-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COINRG I. Kunze 3 Internet-Draft K. Wehrle 4 Intended status: Informational RWTH Aachen University 5 Expires: 6 May 2021 D. Trossen 6 Huawei Technologies Duesseldorf GmbH 7 2 November 2020 9 Use Cases for In-Network Computing 10 draft-kunze-coin-industrial-use-cases-04 12 Abstract 14 Computing in the Network (COIN) comes with the prospect of deploying 15 functionality on networking devices, such as switches and network 16 interface cards. While such functionality can be beneficial in 17 several contexts, it has to be carefully placed into the context of 18 the general Internet communication. This document discusses some use 19 cases to demonstrate how real applications can benefit from COIN and 20 to showcase essential requirements that have to be fulfilled by COIN 21 applications. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 6 May 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Industrial Use Cases . . . . . . . . . . . . . . . . . . . . 3 59 3.1. IIoT Network Scenario . . . . . . . . . . . . . . . . . . 4 60 3.2. In-Network Control / Time-sensitive applications . . . . 5 61 3.2.1. Characterization and Requirements . . . . . . . . . . 5 62 3.2.2. Approaches . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Large Volume Applications/ Traffic Filtering . . . . . . 7 64 3.3.1. Characterization and Requirements . . . . . . . . . . 7 65 3.3.2. Approaches . . . . . . . . . . . . . . . . . . . . . 8 66 3.4. Industrial Safety (Dead Man's Switch) . . . . . . . . . . 9 67 3.4.1. Characterization and Requirements . . . . . . . . . . 10 68 3.4.2. Approaches . . . . . . . . . . . . . . . . . . . . . 10 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 5. Immersive Devices . . . . . . . . . . . . . . . . . . . . . . 11 71 5.1. Mobile Application Offloading . . . . . . . . . . . . . . 11 72 5.2. Edge AR/VR . . . . . . . . . . . . . . . . . . . . . . . 11 73 6. Infrastructure Services . . . . . . . . . . . . . . . . . . . 11 74 6.1. Distributed AI . . . . . . . . . . . . . . . . . . . . . 11 75 6.2. Content Delivery Networks . . . . . . . . . . . . . . . . 11 76 6.3. CFaaS . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 7. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10. Informative References . . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 The Internet bases on a best-effort network with limited guarantees 86 regarding the timely and successful transmission of packets. 87 Functionality is generally provided by the end-hosts while the 88 network is kept simple and only intended to forward the packets. 89 This design-choice is suitable for general Internet-based 90 applications and has helped in the rapid growth of the Internet. 91 However, there are several domains which, e.g., demand a number of 92 strict performance guarantees that cannot be provided over regular 93 best-effort networks. In this context, flexibly distributing the 94 computation tasks across the network can help to achieve the 95 guarantees and increase the overall performance. 97 The different domains, however, have different requirements and it is 98 unclear whether there can be a common solution to all COIN scenarios 99 or if solutions have to be tailored to each scenario. 101 This document first presents applications and requirements of some 102 domains to illustrate the importance of COIN for realizing advanced 103 applications. Based on these discussion, the draft then creates a 104 taxonomy of COIN scenarios with the goal of guiding future work. 106 2. Terminology 108 Programmable network devices (PNDs): Network devices, such as network 109 interface cards and switches, which are programmable, e.g., using P4 111 3. Industrial Use Cases 113 The industrial domain is characterized by diverse sets of 114 requirements which often cannot be provided over regular best-effort 115 networks. Consequently, there is a large number of specialized 116 applications and protocols designed to give the required strict 117 performance guarantees, e.g., regarding real-time capabilities. 118 Time-Sensitive-Networking [TSN] as an enhancement to the standard 119 Ethernet, e.g., tries to achieve these requirements on the link layer 120 by statically reserving shares of the bandwidth. In the Industrial 121 Internet of Things (IIoT), however, more and more parts of the 122 industrial production domain are interconnected. This increases the 123 complexity of the industrial networks, makes them more dynamic, and 124 creates more diverse sets of requirements. In these scenarios, 125 solutions on the link layer alone are not sufficient. 127 The challenge is to develop concepts that can satisfy the dynamic 128 performance requirements of modern industrial networks. COIN 129 presents a promising starting point because it allows to flexibly 130 distribute computation tasks across the network which can help to 131 manage dynamic changes. As specifying general requirements for the 132 industrial production domain is difficult due to the mentioned 133 diversity, this document next characterizes and analyzes three 134 distinct scenarios to showcase potential requirements for the 135 industrial production domain, thereby illustrating how COIN can be 136 helpful. 138 3.1. IIoT Network Scenario 140 Common components of the IIoT can be divided into three categories as 141 illustrated in Figure 1. Following 142 [I-D.mcbride-edge-data-discovery-overview], EDGE DEVICES, such as 143 sensors and actuators, constitute the boundary between the physical 144 and digital world. They communicate the current state of the 145 physical world to the digital world by transmitting sensor data or 146 let the digital world interact with the physical world by executing 147 actions after receiving (simple) control information. The processing 148 of the sensor data and the creation of the control information is 149 done on COMPUTING DEVICES. They range from small-powered controllers 150 close to the EDGE DEVICES, to more powerful edge or remote clouds in 151 larger distances. The connection between the EDGE and COMPUTING 152 DEVICES is established by NETWORKING DEVICES. In the industrial 153 domain, they range from standard devices, e.g., typical Ethernet 154 switches, which can interconnect all Ethernet-capable hosts, to 155 proprietary equipment with proprietary protocols only supporting 156 hosts of specific vendors. 158 -------- 159 |Sensor| ------------| ~~~~~~~~~~~~ ------------ 160 -------- ------------- { Internet } --- |Remote Cloud| 161 . |Access Point|--- ~~~~~~~~~~~~ ------------ 162 -------- ------------- | | 163 |Sensor| ----| | | | 164 -------- | | -------- | 165 . | | |Switch| ---------------------- 166 . | | -------- | 167 . | | ------------ | 168 ---------- | |----------------- | Controller | | 169 |Actuator| ------------ ------------ | 170 ---------- | -------- ------------ 171 . |----|Switch|---------------------------| Edge Cloud | 172 ---------- -------- ------------ 173 |Actuator| ---------| 174 ---------- 176 |-----------| |------------------| |-------------------| 177 EDGE DEVICES NETWORKING DEVICES COMPUTING DEVICES 179 Figure 1: Industrial networks show a high level of heterogeneity. 181 3.2. In-Network Control / Time-sensitive applications 183 The control of physical processes and components of a production line 184 is essential for the growing automation of production and ideally 185 allows for a consistent quality level. Traditionally, the control 186 has been exercised by control software running on programmable logic 187 controllers (PLCs) located directly next to the controlled process or 188 component. This approach is best-suited for settings with a simple 189 model that is focused on a single or few controlled components. 191 Modern production lines and shop floors are characterized by an 192 increasing amount of involved devices and sensors, a growing level of 193 dependency between the different components, and more complex control 194 models. A centralized control is desirable to manage the large 195 amount of available information which often has to be pre-processed 196 or aggregated with other information before it can be used. PLCs are 197 not designed for this array of tasks and computations could 198 theoretically be moved to more powerful devices. These devices are 199 no longer close to the controlled objects and induce additional 200 latency. 202 It is worthwhile to investigate whether the outsourcing of control 203 functionality to distant computation platforms is viable because 204 these platforms have a high level of flexibility and scalability. In 205 the following, we describe the requirements and characteristics of 206 the control setting in more detail. 208 3.2.1. Characterization and Requirements 210 A control process consists of two main components as illustrated in 211 Figure 2: a system under control and a controller. In feedback 212 control, the current state of the system is monitored, e.g., using 213 sensors and the controller influences the system based on the 214 difference between the current and the reference state to keep it 215 close to this reference state. 217 reference 218 state ------------ -------- Output 219 ----------> | Controller | ---> | System | ----------> 220 ^ ------------ -------- | 221 | | 222 | observed state | 223 | --------- | 224 -------------------| Sensors | <----- 225 --------- 227 Figure 2: Simple feedback control model. 229 Apart from the control model, the quality of the control primarily 230 depends on the timely reception of the sensor feedback, because the 231 controller can only react if it is notified of changes in the system 232 state. Depending on the dynamics of the controlled system, the 233 control can be subject to tight latency constraints, often in the 234 single-digit millisecond range. While low latencies are essential, 235 there is an even greater need for stable and deterministic levels of 236 latency, because controllers can generally cope with different levels 237 of latency, if they are designed for them, but they are significantly 238 challenged by dynamically changing or unstable latencies. The 239 unpredictable latency of the Internet exemplifies this problem if 240 off-premise cloud platforms are included. 242 The main requirements for the industrial control scenario are low and 243 stable latencies to ensure that processes can work continuously and 244 that no machines are damaged. 246 3.2.2. Approaches 248 Control models, in general, can become involved but there is a 249 variety of control algorithms that are composed of simple 250 computations such as matrix multiplication. These are supported by 251 some PNDs and it is thus possible to compose simplified 252 approximations of the more complex algorithms and deploy them in the 253 network. While the simplified versions induce a more inaccurate 254 control, they allow for a quicker response and might be sufficient to 255 operate a basic tight control loop while the overall control can 256 still be exercised from the cloud. The problem, however, is that 257 networking devices typically only allow for integer precision 258 computation while floating-point precision is needed by most control 259 algorithms. Additionally, computational capabilities vary for 260 different available PNDs. Yet, early approaches like [RUETH] and 261 [VESTIN] have already shown the general applicability of such ideas, 262 but there are still a lot of open research questions not limited to 263 the following: 265 * How can one derive the simplified versions of the overall 266 controller? 268 - How complex can they become? 270 - How can one take the limited computational precision of 271 networking devices into account when making them? 273 * How does one distribute the simplified versions in the network? 275 * How does the overall controller interact with the simplified 276 versions? 278 3.3. Large Volume Applications/ Traffic Filtering 280 In the IIoT, processes and machines can be monitored more effectively 281 resulting in more available information. This data can be used to 282 deploy machine learning (ML) techniques and consequently help to find 283 previously unknown correlations between different components of the 284 production which in turn helps to improve the overall production 285 system. Newly gained knowledge can be shared between different sites 286 of the same company or even between different companies [PENNEKAMP]. 288 Traditional company infrastructure is neither equipped for the 289 management and storage of such large amounts of data nor for the 290 computationally expensive training of ML approaches. Similar to the 291 considerations in Section 3.2, off-premise cloud platforms offer 292 cost-effective solutions with a high degree of flexibility and 293 scalability. While the unpredictable latency of the Internet is only 294 a subordinate problem for this use case, moving all data to off- 295 premise locations primarily poses infrastructural challenges which 296 are presented in more detail in the following. 298 3.3.1. Characterization and Requirements 300 Processes in the industrial domain are monitored by distributed 301 sensors which range from simple binary (e.g., light barriers) to 302 sophisticated sensors measuring the system with varying degrees of 303 resolution. Sensors can further serve different purposes, as some 304 might be used for time-critical process control while others are only 305 used as redundant fallback platforms. Overall, there is a high level 306 of heterogeneity which makes managing the sensor output a challenging 307 task. 309 Depending on the deployed sensors and the complexity of the observed 310 system, the resulting overall data volume can easily be in the range 311 of several Gbit/s [GLEBKE]. Using off-premise clouds for managing 312 the data requires uploading or streaming the growing volume of sensor 313 data using the companies' Internet access which is typically limited 314 to a few hundred of Mbit/s. While large networking companies can 315 simply upgrade their infrastructure, most industrial companies rely 316 on traditional ISPs for their Internet access. Higher access speeds 317 are hence tied to higher costs and, above all, subject to the supply 318 of the ISPs and consequently not always available. A major challenge 319 is thus to devise a methodology that is able to handle such amounts 320 of data over limited access links. 322 Another aspect is that business data leaving the premise and control 323 of the company further comes with security concerns, as sensitive 324 information or valuable business secrets might be contained in it. 325 Typical security measures such as encrypting the data make in-network 326 computing techniques hardly applicable as they typically work on 327 unencrypted data. Adding security to in-network computing 328 approaches, either by adding functionality for handling encrypted 329 data or devising general security measures, is thus an auspicious 330 field for research which we describe in more detail in Section 4. 332 3.3.2. Approaches 334 There are at least two concepts which might be suitable for reducing 335 the amount of transmitted data in a meaningful way: 337 1. filtering out redundant or unnecessary data 339 2. aggregating data by applying pre-processing steps within the 340 network 342 Both concepts require detailed knowledge about the monitoring 343 infrastructure at the factories and the purpose of the transmitted 344 data. 346 3.3.2.1. Traffic Filters 348 Sensors are often set up redundantly, i.e., part of the collected 349 data might also be redundant. Moreover, they are often hard to 350 configure or not configurable at all which is why their resolution or 351 sampling frequency is often larger than required. Consequently, it 352 is likely that more data is transmitted than is needed or desired. A 353 trivial idea for reducing the amount of data is to filter out 354 redundant or undesired data before it leaves the premise using simple 355 traffic filters that are deployed in the on-premise network. There 356 are different approaches to how this topic can be tackled. A first 357 step would be to scale down the available sensor data to the data 358 rate that is needed. For example, if a sensor transmits with a 359 frequency of 5 kHz, but the control entity only needs 1 kHz, only 360 every fifth packet containing sensor data is let through. 361 Alternatively, sensor data could be filtered down to a lower 362 frequency while the sensor value is in an uninteresting range, but 363 let through with higher resolution once the sensor value range 364 becomes interesting. It is important that end-hosts are informed 365 about the filtering so that they can distinguish between data loss 366 and data filtered out on purpose. 368 In this context, the following research questions can be of interest: 370 * How can traffic filters be designed? 372 * How can traffic filters be coordinated and deployed? 373 * How can traffic filters be changed dynamically? 375 * How can traffic filtering be signaled to the end-hosts? 377 3.3.2.2. In-Network (Pre-)Processing 379 There are manifold computations that can be performed on the sensor 380 data in the cloud. Some of them are very complex or need the 381 complete sensor data during the computation, but there are also 382 simpler operations which can be done on subsets of the overall 383 dataset or earlier on the communication path as soon as all data is 384 available. One example is finding the maximum of all sensor values 385 which can either be done iteratively at each intermediate hop or at 386 the first hop, where all data is available. 388 Using expert knowledge about the exact computation steps and the 389 concrete transmission path of the sensor data, simple computation 390 steps can be deployed in the on-premise network to reduce the overall 391 data volume and potentially speed up the processing time in the 392 cloud. 394 Related work has already shown that in-network aggregation can help 395 to improve the performance of distributed ML applications [SAPIO]. 396 Investigating the applicability of stream data processing techniques 397 to programmable networking devices is also interesting, because 398 sensor data is usually streamed. In this context, the following 399 research questions can be of interest: 401 * Which (pre-)processing steps can be deployed in the network? 403 - How complex can they become? 405 * How can applications incorporate the (pre-)processing steps? 407 * How can the programming of the techniques be streamlined? 409 3.4. Industrial Safety (Dead Man's Switch) 411 Despite increasing automation in production processes, human workers 412 are still often necessary. Consequently, safety measures have a high 413 priority to ensure that no human life is endangered. In traditional 414 factories, the regions of contact between humans and machines are 415 well-defined and interactions are simple. Simple safety measures 416 like emergency switches at the working positions are enough to 417 provide a decent level of safety. 419 Modern factories are characterized by increasingly dynamic and 420 complex environments with new interaction scenarios between humans 421 and robots. Robots can either directly assist humans or perform 422 tasks autonomously. The intersect between the human working area and 423 the robots grows and it is harder for human workers to fully observe 424 the complete environment. 426 Additional safety measures are essential to prevent accidents and 427 support humans in observing the environment. The increased 428 availability of sensor data and the detailed monitoring of the 429 factories can help to build additional safety measures if the 430 corresponding data is collected early at the correct position. 432 3.4.1. Characterization and Requirements 434 Industrial safety measures are typically hardware solutions because 435 they have to pass rigorous testing before they are certified and 436 deployment-ready. Standard measures include safety switches and 437 light barriers. Additionally, the working area can be explicitly 438 divided into 'contact' and 'safe' areas, indicating when workers have 439 to watch out for interactions with machinery. 441 These measures are static solutions, potentially relying on 442 specialized hardware, and are challenged by the increased dynamics of 443 modern factories where the factory configuration can be changed on 444 demand. Software solutions offer higher flexibility as they can 445 dynamically respect new information gathered by the sensor systems, 446 but in most cases they cannot give guaranteed safety. Yet, it is 447 worthwhile to investigate whether such solutions can introduce 448 additional safety measures. 450 3.4.2. Approaches 452 Software-based solutions can take advantage of the large amount of 453 available sensor data. Different safety indicators within the 454 production hall can be combined within the network so that 455 programmable networking devices can give early responses if a 456 potential safety breach is detected. A rather simple possibility 457 could be to track the positions of human workers and robots. 458 Whenever a robot gets too close to a human in a non-working area or 459 if a human enters a defined safety zone, robots are stopped to 460 prevent injuries. More advanced concepts could also include image 461 data or combine arbitrary sensor data. 463 In this context, the following research questions can be of interest: 465 * Which additional safety measures can be provided? 466 - Do these measures actually improve safety? 468 * Which sensor information can be combined and how? 470 4. Security Considerations 472 Note: This section will need consolidation once new use cases are 473 added to the draft. Current in-network computing approaches 474 typically work on unencrypted plain text data because today's 475 networking devices usually do not have crypto capabilities. As is 476 already mentioned in Section 3.3.1, this above all poses problems 477 when business data, potentially containing business secrets, is 478 streamed into remote computing facilities and consequently leaves the 479 control of the company. Insecure on-premise communication within the 480 company and on the shop-floor is also a problem as machines could be 481 intruded from the outside. It is thus crucial to deploy security and 482 authentication functionality on on-premise and outgoing communication 483 although this might interfere with in-network computing approaches. 484 Ways to implement and combine security measures with in-network 485 computing are described in more detail in [I-D.fink-coin-sec-priv]. 487 5. Immersive Devices 489 5.1. Mobile Application Offloading 491 NOTE: Will be moved here from 492 [I-D.draft-sarathchandra-coin-appcentres-03] 494 5.2. Edge AR/VR 496 NOTE: Could be transfered from (expired) 497 [I-D.draft-montpetit-coin-xr-03] 499 Additional potential sources: [I-D.draft-geng-rtgwg-cfn-req-00] 501 6. Infrastructure Services 503 6.1. Distributed AI 505 NOTE: Will be moved here from 506 [I-D.draft-sarathchandra-coin-appcentres-03] 508 6.2. Content Delivery Networks 510 NOTE: Will be moved here from 511 [I-D.draft-sarathchandra-coin-appcentres-03] 513 6.3. CFaaS 515 NOTE: Will be moved here from 516 [I-D.draft-sarathchandra-coin-appcentres-03] 518 7. Taxonomy 520 NOTE: The taxonomy is intended to generalize characteristics of the 521 different presented use cases and work on it will start once more use 522 cases are added to the draft. 524 8. IANA Considerations 526 N/A 528 9. Conclusion 530 There are several domains that can profit from COIN. 532 Industrial scenarios have unique sets of requirements mostly focusing 533 around tight latency constraints with high required bandwidths. 535 NOTE: Further aspects will be added once more use cases are added to 536 the draft. 538 10. Informative References 540 [GLEBKE] Glebke, R., Henze, M., Wehrle, K., Niemietz, P., Trauth, 541 D., Mattfeld MBA, P., and T. Bergs, "A Case for Integrated 542 Data Processing in Large-Scale Cyber-Physical Systems", 543 Proceedings of the 52nd Hawaii International Conference on 544 System Sciences, DOI 10.24251/hicss.2019.871, 2019, 545 . 547 [I-D.draft-geng-rtgwg-cfn-req-00] 548 Geng, L. and P. Willis, "Compute First Networking (CFN) 549 Scenarios and Requirements", Work in Progress, Internet- 550 Draft, draft-geng-rtgwg-cfn-req-00, 4 November 2019, 551 . 554 [I-D.draft-montpetit-coin-xr-03] 555 Montpetit, M., "In Network Computing Enablers for Extended 556 Reality", Work in Progress, Internet-Draft, draft- 557 montpetit-coin-xr-03, 8 July 2019, . 560 [I-D.draft-sarathchandra-coin-appcentres-03] 561 Trossen, D., Sarathchandra, C., and M. Boniface, "In- 562 Network Computing for App-Centric Micro-Services", Work in 563 Progress, Internet-Draft, draft-sarathchandra-coin- 564 appcentres-03, 23 October 2020, . 568 [I-D.fink-coin-sec-priv] 569 Fink, I. and K. Wehrle, "Enhancing Security and Privacy 570 with In-Network Computing", Work in Progress, Internet- 571 Draft, draft-fink-coin-sec-priv-01, 8 September 2020, 572 . 575 [I-D.mcbride-edge-data-discovery-overview] 576 McBride, M., Kutscher, D., Schooler, E., Bernardos, C., 577 Lopez, D., and X. Foy, "Edge Data Discovery for COIN", 578 Work in Progress, Internet-Draft, draft-mcbride-edge-data- 579 discovery-overview-05, 1 November 2020, 580 . 583 [PENNEKAMP] 584 Pennekamp, J., Henze, M., Schmidt, S., Niemietz, P., Fey, 585 M., Trauth, D., Bergs, T., Brecher, C., and K. Wehrle, 586 "Dataflow Challenges in an Internet of Production: A 587 Security & Privacy Perspective", Proceedings of the ACM 588 Workshop on Cyber-Physical Systems Security & Privacy - 589 CPS-SPC'19, DOI 10.1145/3338499.3357357, 2019, 590 . 592 [RUETH] Rueth, J., Glebke, R., Wehrle, K., Causevic, V., and S. 593 Hirche, "Towards In-Network Industrial Feedback Control", 594 Proceedings of the 2018 Morning Workshop on In-Network 595 Computing - NetCompute '18, DOI 10.1145/3229591.3229592, 596 2018, . 598 [SAPIO] Sapio, A., "Scaling Distributed Machine Learning with In- 599 Network Aggregation", 2019, 600 . 602 [TSN] IEEE, ., "Time-Sensitive Networking (TSN) Task Group", 603 2019, . 605 [VESTIN] Vestin, J., Kassler, A., and J. Akerberg, "FastReact: In- 606 Network Control and Caching for Industrial Control 607 Networks using Programmable Data Planes", 2018 IEEE 23rd 608 International Conference on Emerging Technologies and 609 Factory Automation (ETFA), DOI 10.1109/etfa.2018.8502456, 610 September 2018, 611 . 613 Authors' Addresses 615 Ike Kunze 616 RWTH Aachen University 617 Ahornstr. 55 618 D-52074 Aachen 619 Germany 621 Email: kunze@comsys.rwth-aachen.de 623 Klaus Wehrle 624 RWTH Aachen University 625 Ahornstr. 55 626 D-52074 Aachen 627 Germany 629 Email: wehrle@comsys.rwth-aachen.de 631 Dirk Trossen 632 Huawei Technologies Duesseldorf GmbH 633 Riesstr. 25C 634 D-80992 Munich 635 Germany 637 Email: Dirk.Trossen@Huawei.com