In phase II, B2 modeled MAKI components as meshes of processing elements. The inclusion of in-network processing (INP) enabled processing elements to be (re)placed on the most suitable network resources, e.g., near end systems or servers. Important results concerned scheduling concepts that achieve significantly improved utilization of network resources. VirtualStack also succeeded in further developing advanced concepts of virtualization and software-defined communication systems into an end-to-end approach. Static or dynamic pre-configuration of MAKI multi-mechanism stacks thereby enable fast transitions and coexistence; coupling of MAKI multi-mechanisms with legacy applications as well as hardware acceleration is enabled.
In phase III, B2 intends to focus on applications with mission-cruical requirements, while improving execution flexibility and performance for other types of applications. To this end, three general conceptual guidelines for phase III research are established as follows.
(A) Flexible applications (FlexApps). As a guiding hypothesis, it is assumed that tomorrow, as today, many networks will not be able to meet the requirements of applications – especially of a mission-cruical nature – with the desired quality at all times. Therefore, developers shall be provided with means to specify multiple alternative variants of applications that can be selected and switched at runtime with the goal of providing binding guarantees; nevertheless, best possible functionality shall be provided and context dependency shall be taken into account. The alternatives provided in FlexApps and their exchanges obviously resemble mechanisms and transitions; B2 thus lays the foundation for extending the MAKI principle to (mission-cruical and other) applications.
(B) Quality of Results vs. Quality of Service (QoR vs. QoS). In order for B2 runtime support to appropriately select among FlexApp variants, a pair of composite values (<QoR>, <QoS>) must be specified for each variant. QoR (Quality of Result) specifies the quality that a variant assures to the environment, while QoS reflects the required quality of service of the underlying communication system and runtime environment. For example, an automotive driver assistance FlexApp with camera-based object detection could exist in two variants: one that uses only the GPU nodes of a non-transitory vehicle network and one that incorporates edge computing; the second could require QoS guarantees that are only achieved in inner cities, if necessary, but allow for smaller safety distances. The inclusion of the vehicular network highlights the need for cooperative transitions.
(C) Microservice-based runtime support. From the experience and results of phase II’s project C7, we deduce that the extremely lightweight and modular concept of microservices is in principle particularly suitable for highly flexible and scalable distributed execution. Resource utilization close to end systems (e.g., using edge computing) enables latency, reliability, and bandwidth guarantees. However, an important disadvantage compared to traditional cloud computing is the significantly lower elasticity: compute and storage resources are inherently limited in edge computing, whereas they can be idealized as infinite in cloud computing. C7 took significant steps towards exploiting the aforementioned advantages while significantly mitigating the disadvantage, mainly through novel scalability and caching approaches. As the lowest core of runtime support, new concepts are therefore planned for a microservice-based runtime environment that fits the overall concept of B2.
In summary, the following four major efforts are required in phase III in particular: i) New microservice-based concepts are to be developed to achieve better batching and mobility support and to mitigate microservice-inherent problems, e.g., with respect to stateful microservices and data flow dependencies. ii) New approaches are also required to make existing results such as VirtualStack microservice-enabled. iii) Optimization and scheduling methods must be designed for FlexApp variants on a QoR/QoS basis, variant transitions must be dovetailed as transitions with those of the communication system and the runtime environment, i.e., the two previously mentioned efforts. iv) The additional workload for application developers in view of multiple (FlexApp) variants and necessary QoR/QoS specifications must be reduced. This requires new concepts for interactive quality measurement and FlexApp specification as well as (with subproject A2) programming language support.