IOWN Data Hub to Become a Reality

(1) Specific description of use-case requirements: Identification of data types, bandwidth requirements, etc. for each use case presented in the Cyber-Physical System (CPS) and AI (artificial intelligence) Integrated Communications (AIC) use-case documents [3, 4].

(2) Identification of inherent gaps: Gap analysis based on more specific implementation models.

2.1 Fundamental problems in DCs

The current networks and DC technology have several fundamental problems in the following areas. These must be solved if we are to build IDH services that meet the use-case requirements (Fig. 1).

Fig. 1. Origins of gaps in today’s technology landscape.

(1) Inter-DC network quality

The network quality between DCs used in today’s cloud is focused on current use cases. Since packet reordering and loss occur in networks, the Transmission Control Protocol (TCP) is used more frequently than other protocols, such as the User Datagram Protocol (UDP), to ensure reliability. These networks do not provide sufficient performance for the workloads of geographically distributed databases and storage systems that are required by the use cases in the IOWN era.

(2) Intra-DC network quality

The quality of the networks used by hyperscale DCs that make up a cloud are not high enough. For example, one-way latency can exceed 1 ms, a latency sufficiently high to cause packet loss to exceed 1% during severe network congestion. The bandwidth is similarly unstable. This is essentially due to oversubscription, a scheme that allows reservation of bandwidth beyond the capacity of the network devices. Therefore, the network that connects computing resources in a DC cannot guarantee all the bandwidth allocated to individual resources.

(3) Storage performance

To ensure data persistence, data are typically synchronized across multiple servers. However, synchronization requires a large workload, rendering performance very unstable. Thus, storage systems that are connected via today’s cloud-based storage area networks tend to be slower than directly connected storage devices. For example, the response time of storage systems can exceed dozens of milliseconds, making such systems unsuitable for typical database workloads or redundant storage systems.

(4) Data-sharing performance

In cases where data are processed cooperatively across multiple servers, a certain amount of data exchange is required between servers, for example, to redistribute data. This exchange significantly reduces overall performance. To speed up such data servers, some implementations connect servers using remote direct memory access (RDMA) fabric connections. However, since the use of RDMA in production environments imposes strict requirements, such as no packet loss and no packet reordering, RDMA is used only for very limited purposes in today’s cloud environments.

(5) Accelerator usage

Accelerators, such as graphics processing units (GPUs) and field programmable gate arrays (FPGAs), have the potential to achieve high performance, cost-effectiveness, and energy efficiency at least 10 times greater than software-based processing on general-purpose central processing units (CPUs). However, such an accelerator must be deployed within each server and cannot directly access external clients for the purpose of streamlining data loading. Therefore, with current network and DC technologies, it is not possible for multiple general-purpose computing resources to share accelerator resources at high speed and with low overhead.

2.2 Today’s implementation model and inherent gaps

Considering the aforementioned issues, we must accept the following constraints if we are to use today’s technology to provide data services such as the IDH.

(1) Completion of data processing within one place

If processing efficiency could drop sharply due to poor quality of the network that connects DCs, it would be difficult to implement geographically distributed data services. Therefore, current data-processing services are designed to be implemented within a single DC or within nearby availability zones. In fact, today’s clouds are an aggregation of such services. The size of cloud DCs has become so enormous that the number of available cloud regions is very limited, 30 or so at most worldwide. This means that, regardless of where data were generated, all data must be transferred to one of the cloud DCs and all data processing must be completed there, making the system’s energy use highly inefficient.

(2) Asynchronous data replication as a foundation to build a scalable transactional distributed relational database

In building a scalable transactional relational database (RDB) system, it is a common practice to place replicated read-only data near each RDB server. Such data replication tends to be asynchronous because the network is slow. To reduce the load imposed on slow networks by data replication, often only the transaction or change logs, rather than the data, are propagated. This improves performance but requires reconstruction of table data from the log data on each server, which inevitably increases the system cost and power consumption.

(3) Sharded data processing to build a scalable key-value store, message broker, and/or analytical distributed RDB

Sharding is a technology for reducing response time and improving scalability by grouping related data together and distributing it across multiple databases. It is used to build scalable systems, such as a key-value store (KVS). However, it does not eliminate data transfer needed for data relocation and server-to-server communication. Rather, the volume of such data transfer and communication may increase in advanced digital transformation (DX) services that need to handle data from many different angles. Since sharded systems require a certain amount of data transfer between scale-out and scale-in operations, data services in the cloud today experience constraints on dynamically changing scalability.

(4) Usage of a cache layer

The constraints imposed by low-speed networks and storage systems often make it necessary to manage data on a process-by-process basis and rely heavily on asynchronous distributed processing. To streamline such implementations, various cached data management services are provided in today’s cloud. However, such services increase end-to-end latency and cause the same data to be copied unnecessarily multiple times in the cloud, which is undesirable in terms of cost and energy consumption.

(5) Accelerator in use only in a laboratory

One possible approach to solving the aforementioned problems is to use accelerators, such as GPUs and FPGAs, to speed up queries and other data processing in distributed RDBs. Software has been developed and validated for such purposes, but in actual practice, the use of such software rarely improves and often diminishes performance and cost-effectiveness. This is mainly due to the need to preload data at the startup of the accelerator.

The IDH must be designed to address the fundamental and inherent challenges of today’s cloud system and must be further developed to adapt to use cases of the wide-area and real-time CPSs that will be increasingly demanded in the future. To this end, it is necessary to verify the IDH iteratively in actual use cases and reflect the results to refine the required functions and design methodology of the IDH.

3.1 The IDH PoC Reference

This PoC Reference has been formulated to validate the IDH architecture that meets the stringent requirements of various DX services. Smart factory, smart grid, and metaverse have been selected as use-case examples and five PoC scenarios have been defined.

To build a metaverse service, for example, it is typically necessary to collect information about the participants, represent them as avatars in the virtual space, and allow the avatars to interact with each other. Thus, provision of a high-quality metaverse service requires the following.

• Collect motion data from up to millions of participants and reflect them in the movements of their avatars in cycles of dozens of milliseconds.
• Move avatars in the virtual space, which contains many virtual buildings and other structural elements, and enable them to communicate with each other.
• Render virtual space scenery from each avatar’s perspective with motion-to-photon latency of less than dozens of milliseconds.

To demonstrate the IDH architecture for supporting such use cases, the PoC Reference defines a test environment that reflects the geographically distributed deployment of assumed IDH services and identifies the items that PoC projects should validate (Fig. 2).

Fig. 2. Geo-distributed IDH adoption model and IDH PoC scenario mapping.

In this model, a subgroup of front-end servers of the IDH architecture is deployed at a regional edge center to provide low-latency services to connected Internet of Things (IoT) devices. The data service servers and storage servers, which are part of the IDH architecture, are deployed at remote DCs or the central cloud to support data persistence and usage.

On the basis of this model, the PoC Reference defines the following five PoC scenarios:

• Scenario 1: Frontend-to-Data Service PUT Communication Acceleration with Open APN
• Scenario 2: Data Service-to-Frontend GET Communication Acceleration with Open APN
• Scenario 3: Data Service-to-Data Service Communication Acceleration with Open APN
• Scenario 4: Elastic High-speed Shareable Storage with DCI
• Scenario 5: New frontend implementation supporting low-latency responses and efficient geo-distributed processing

For each scenario, the PoC Reference describes an overview, required functions, variable conditions, and expected benchmarks to enable the readers to proceed with their PoC projects (Table 2).

Table 2. Benchmark requirements for each scenario.

IOWN Global Forum member companies are currently conducting PoC projects for their respective scenarios on the basis of this PoC Reference. Thus, the IDH is making steady progress toward its social implementation.