A Multipath Transmission System for Information-Centric Networking Based on Standalone Name Resolution

Abstract

Information-Centric Networking (ICN) essentially supports multipath transmission. However, current multipath schemes in ICN either necessitate major network infrastructure updates or necessitate specific network settings for terminal devices. To solve these problems, we propose MPTS-ICN, a multipath transmission system for ICN that realizes end-to-end multipath transmission. Taking the ICN architecture based on the standalone name resolution approach as a basis, MPTS-ICN is easier to implement and deploy than other ICN multipath schemes. Moreover, we have extended the original network layer protocol to support multipath data transmission in ICN. To set up concurrent transmission multipath efficiently, we propose a heuristic algorithm for the selection of multipath service nodes. Extensive experimental comparisons with existing data transmission methods show that in bandwidth-constrained scenarios, MPTS-ICN outperforms the best-route method by 83.6% and the ECMP method by 79.7% in average flow completion time.

1. Introduction

With the development of new technologies such as 5G, Internet of Things, and virtual reality, users have higher requirements for the quality of network services. Although network operators respond to the demands of high bandwidth and low latency by continuously increasing and upgrading network infrastructure, the current network resources are always scarce relative to the needs of network users. The traditional TCP/IP network routes network packets based on the shortest path between the source and destination node pairs, and other paths are only used for backup and recovery purposes when the default path fails. The experimental results in [1] show that the average link utilization of typical backbone networks is between 17% and 29%, indicating that the traditional single-path transmission mode does not make full use of network resources.

Concurrent multipath transmission technology can effectively aggregate network bandwidth resources, balance network node load, reduce data delivery completion time, and improve data transmission throughput [2,3]. To support multipath transmission, researchers have proposed a variety of multipath transmission schemes. Multipath TCP (MPTCP) [4] is one of the common methods to achieve multipath transmission. Its basic principle is to establish multiple data transmission paths between multiple network interfaces of two terminal devices. However, MPTCP requires at least one terminal device to have multiple network interfaces, which is hard to achieve in practical applications. To overcome the limitations of terminal devices, some multipath transmission protocols have been proposed [5,6]. Equal-Cost Multipath Routing (ECMP) [5] is a simple multipath routing protocol that has been integrated into many traditional routing environments. However, ECMP is only applicable to path-equivalent scenarios. To solve the problem of ECMP, Google proposed Weight-Cost Multipath Routing (WCMP) [6], which can transmit traffic on the link flexibly according to the path weight. In addition, some researchers have tried to achieve multipath transmission based on the characteristics of the overlay network [7,8]. However, these solutions are only equivalent to patching on the current network, and do not solve the fundamental problem. The traditional TCP/IP network architecture was designed to meet the point-to-point communication at the beginning, and did not consider many future application requirements. Moreover, due to the interaction of additional mechanisms used by existing networks, the realization of multipath transmission in real-world scenarios often leads to suboptimal performance and non-negligible operating costs [9]. Therefore, a new network structure is needed to solve these problems fundamentally.

In this context, ICN is believed to be a promising candidate for future Internet architectures, aiming to better reflect current and future demands than present Internet architectures [10]. The current Internet architecture is based on a host-centric communication model, while ICN advocates name-based communication. Information retrieval is based on pull and driven by the receiver in ICN. ICN implements name-based routing, forwards user requests on a single path or multipath, and inherently couples the in-network caching function. ICN is frequently a better option for multipath transmission because of the separation of identifiers and locators as well as the in-network caching function. According to the existing name resolution approaches in ICN, they can be divided into two categories: the ICN architecture based on the name routing approach and the ICN architecture based on the standalone name resolution approach [11]. The former combines name resolution and routing content requests as a process. It not only requires a major upgrade of the entire network infrastructure but also requires a redesign of the existing computer protocol stack. Due to the high deployment cost, it is currently only in the academic research stage. The latter adopts the standalone name resolution approach that separates from the routing of the content request. It has better compatibility with the existing IP architecture, and can incrementally deploy or replace existing devices in the existing network to achieve a smooth evolution of the network architecture. Therefore, this paper employs the latter ICN architecture to build a multipath transmission system.

To improve the efficiency of content distribution and reduce deployment overhead, this paper proposes a general framework of multipath transport systems applied in an ICN architecture based on the standalone name resolution approach (MPTS-ICN). The novelty of this paper lies in the use of the multipath service identifier (MPSID) to bind the network addresses of the multipath service nodes and employ the multipath service nodes as relay nodes to construct multiple paths for data transmission. In addition, a cluster-based multipath service node selection (CMSNS) method has been adopted to guarantee the independence among multiple paths, which reduces the time complexity of multipath calculation. The goal of this paper is to make full use of the characteristics of ICN and the advantages of multipath transmission to improve the efficiency and reliability of data transmission. The main contributions of our work are as follows:

• We present MPTS-ICN, which defines three kinds of logical entities, including ICN edge nodes, multipath service nodes and the name mapping and resolution system (NMRS). We store the mapping relationship between MPSID and multipath service node network addresses in NMRS. By requesting MPSID from NMRS, ICN edge nodes use multipath service nodes as relay nodes to construct multiple paths for data transmission. In addition, we propose a weighted cost data scheduling (WCDS) method to guarantee the performance of ICN multipath transmission.
• The selection of multipath service nodes is the key to constructing multiple paths in ICN. We propose CMSNS, which takes link overlap and link state into account. To reduce the overhead of path link overlapping degree calculation, the independence between paths is guaranteed based on the independence between different autonomous systems. In addition, by measuring the path link state, the optimal multipath service node in the same autonomous system is selected to establish a sub-path.
• We simulate the implementation of MPTS-ICN and other data transmission schemes based on the NS3 network simulator and compare differences in their performance in data flow completion time and throughput. In addition, we verify the impact of different node selection algorithms on our proposed multipath scheme.

The rest of this paper is organized as follows: In Section 2, we review the multipath transmission schemes in IP networks and ICN networks and analyze their shortcomings. In Section 3, the architecture of MPTS-ICN is described and its advantages are analyzed. In Section 4, we study the selection algorithm of multipath service nodes. In Section 5, we simulate the performance verification of MPTS-ICN and the multipath service node selection algorithm, then analyze the results. In Section 6, we provide a summary and concluding remarks, and introduce future research work.

2. Related Work

2.1. Multipath Transmission in IP Networks

The multi-homing scenario is one of the most commonly used methods to achieve multipath transmission. Stream Control Transmission Protocol (SCTP) and Transmission Control Protocol (TCP) are basic protocols widely used in multi-homing scenarios. At present, MPTCP and Concurrent Multipath Transfer for SCTP (CMT-SCTP) are the focus of the Internet Engineering Task Force (IETF) and academia [4]. MPTCP is an extension of TCP that does not affect the underlying TCP components. The basic design idea of MPTCP is to divide the transmitted traffic into more sub-flows. Each sub-flow establishes a separate end-to-end session and then aggregates into a single flow at the receiving end. This mechanism is transparent to the upper application. The upper application can add or delete the interface address to the address pool via Application Programming Interface (API), but it cannot directly manage MPTCP. SCTP is designed by Signaling Transport (SIGTRAN) organization to transmit signaling messages over IP networks. It is an end-to-end transmission protocol for data streams, and multi-homing represents one of the important characteristics of SCTP. Iyengar et al. proposed CMT-SCTP to realize multipath transfer between multi-homed hosts by using the multi-homed characteristic of SCTP. CMT-SCTP can carry out the concurrent multipath transmission on the established multiple paths or select other paths for data transmission in time when one path fails. However, multi-homing multipath requires at least one terminal device to have multiple network interfaces, which is difficult to meet in practical applications. Moreover, the multi-homed implementation cannot accurately understand the status of the underlying network and is susceptible to path differences, resulting in a decline in transmission performance.

On the Internet, researchers have proposed many multipath routing protocols for multipath transmission. ECMP [5] is a simple multipath routing protocol and has been integrated into many traditional routing environments. ECMP has typically deployed on routers and routes packets over multiple paths with the same weight, using a simple polling strategy to allocate traffic. However, in the actual network, the link state information such as bandwidth, delay and packet loss rate of each path is not the same, so equating the path weight cannot make good use of bandwidth, especially when there is a large path difference. To solve the problem of ECMP, Google proposed WCMP [6], which can be very flexible in accordance with the path weight in proportion to the transfer of traffic on the link, reducing the flow bandwidth changes to 1/25. However, the calculation method of multi-path routing is more complex than single-path routing. For example, in Open Shortest Path First (OSPF), the time complexity of a single shortest path with N network nodes is O(NlogN), while the time complexity of a k-shortest multipath calculation is O(KN + NlogN) [12]. Compared with single-path routing, multipath routing increases computational complexity and requires additional storage. More importantly, the increase in routing complexity leads to a decrease in scalability.

2.2. Multipath Transmission in ICN

ICN essentially supports multipath transfer. Adopting multipath in ICN increases resiliency and reduces data-transmission time. However, the combination of ICN and multipath transmission presents new challenges in balancing performance maximization and network cost minimization. ICN multipath transmission schemes need to take into account the variable delay and in-network cache [13]. Detti et al. proposed a general analysis model to evaluate the impact of multipath forwarding strategies on ICN content delivery performance [14]. According to this model, a good forwarding strategy should maximize user throughput and minimize overall network cost. Carofiglio et al. [15] formulated the multipath forwarding and congestion control problem in ICN as a global optimization problem with nonlinear objectives and linear constraints, then solved it. Nguyen et al. developed a unified problem of ICN caching and multipath forwarding as a network optimization problem to maximize user satisfaction [16].

In the ICN architecture based on the name routing approach, such as Content-Centric Networking (CCN) [17], Named Data Network (NDN) [18] and Publish Subscribe Internet Technology (Pursuit) [19], the realization of multipath transmission depends on the flexible forwarding plane of ICN. The authors in [20] proposed a probabilistic ant-routing mechanism for CCN nodes to achieve multipath transmission. He et al. proposed a multipath publish/subscribe model called MPS in ICN, which has a shorter data transmission time and more reliable connections between publishers and subscribers [21]. In the MPS model, the authors use a new component called the connection manager to implement the multipath transfer protocol (MPT) and establish multipath communication between subscribers and publishers. The authors in [22] proposed a fully distributed cooperative multipath data transmission solution CODA based on NDN architecture. CODA extends the standard interest model in NDN to support data transmission along multiple paths and designs a traffic scheduling model to transmit data cooperatively and a transmission control scheme for efficient path selection. Through the analysis of the acceptance rate in ICN, Ren et al. designed DMF based on NDN architecture [23], a new dynamic multipath forwarding strategy based on each packet. Compared with the existing forwarding strategy, DMF further analyzes and divides the transmission process, then adopts different metrics for different stages of the forwarding strategy, which can dynamically adapt to the change in available path capacity to maximize the reception rate at consumers. Wang et al. proposed a distributed stochastic optimization framework for multi-path control of ICN-IoT for resource constraints and scalability in the IoT [24]. Subflow-level multi-path interest control scheme (SMIC) [25] is an ICN multi-path transport layer mechanism proposed by Song et al. that aims to enhance the performance of content delivery on multiple paths while achieving the throughput fairness of single-path runoff.

However, multipath schemes of the name-based routing ICN architectures do not help users when they need to obtain data from a specific server. Moreover, name-based routing ICN architectures typically employ hierarchical and aggregated names, and name resolution is combined with message routing. This means that it requires a major upgrade of the entire network’s infrastructure and a redesign of the existing computer protocol stack. Due to the huge costs associated, it is almost impossible to update existing network devices to support ICN multipath transmission. The ICN architecture based on the standalone name resolution approach ,such as Data-Oriented Network Architecture (DONA) [26], Mobilityfirst [27], Network of Information (Netinf) [28], SD-ICN [29] and On-Site, Elastic, Autonomous Network (SEANet) [30], can be compatible with the existing network and its underlying routing supports the routing method of the existing network, which can facilitate the smooth evolution of the network architecture. Therefore, some researchers try to combine the ICN architecture based on the standalone name resolution approach with multi-homing technology to realize multipath transmission in ICN [31,32]. The authors in [31] proposed a network-assisted ICN multipath transmission scheme based on Mobilityfirst, which requires that terminal devices have multiple network interfaces, and registered the globally unique identifier (GUID) mapping to multiple network addresses with the global name resolution service (GNRS). Based on the IP-compatible ICN architecture, the author in [32] used MPTCP in the transport layer to support multipath transmission in ICN. However, as mentioned above, this approach requires that at least one terminal device has multiple network interfaces and corresponding network settings at the terminal.

Combined with the above research work, we design a general framework of multipath transmission system to realize multipath data transmission in ICN. Compared with the existing ICN multipath scheme, our scheme is easy to implement and deploy since it has no specific requirements for the network settings of terminal devices and does not require modification of the existing network devices.

3. Design Overview

3.1. System Architecture

According to different name resolution approaches, there are two types of ICN architectures: the ICN architecture based on the name routing approach and the ICN architecture based on the standalone name resolution approach. In an ICN architecture with the standalone Name Mapping and Resolution System (NMRS), the name resolution process is separate from the information routing process, making it more compatible with existing network infrastructure (primarily IP infrastructure). Therefore, the multipath transmission system proposed in this paper is based on the ICN architecture with the standalone NMRS. Identification is an important part of the ICN network architecture. In this paper, a flat naming method is used to identify all network element entities (devices or data chunks) in the ICN network using a unique and unchanged Entity-ID (EID). The mapping relationship between the identifiers of these network element entities and their network address (NA) is managed and maintained through NMRS. Because there are a large number of IP facilities, the IP address is used for NA. Named Data Chunk (NDC) is the basic unit of ICN network data transmission. In the IP-compatible ICN architecture, the size of the data chunk can be set to be greater than 1 MB [33].

During data transmission, the ICN router on the transmission path can cache the forwarded data packets. When an ICN router caches a complete NDC, the NDC will be identified by a unique data chunk EID. After that, the ICN router cached the NDC registered the mapping relationship between the IP of the node and the EID of the NDC to NMRS, becoming a new content source. Consumers obtain the corresponding NDC from the network through the data chunk EID. In order to obtain the NDC, the consumer first queries NMRS for the replica node NA list corresponding to the data chunk EID and selects an optimal replica NA from it. After that, consumers complete the acquisition of the corresponding data chunk by using the NA of the optimal copy. Due to some security reasons, consumer devices usually cannot directly obtain the NA of the nodes in the network from NMRS, so the corresponding work is usually completed by the ICN edge nodes [34].

Compared with IP routers, ICN routers usually have greater flexibility and can better realize the dynamic forwarding of data packets. The ID/NA coordination and reconstruction function integrated into the ICN router can process the address field in the data packet during the data packet forwarding process [30], for example, change the destination address according to the EID query result or remove some of the carried addresses from the address field, and then reconstruct the data packet with the modified address through the data packet reconstruction function to form a new packet, finally forward based on the address forwarding mechanism. The ID/NA coordination and reconstruction function of the ICN router provides convenience for multipath construction.

Based on the above description, the ICN architecture with standalone NMRS can effectively support the construction of the multipath transmission system and is compatible with existing IP facilities. Figure 1 shows the structure of MPTS-ICN. MPTS-ICN is mainly composed of three logical entities: edge nodes, multipath service nodes, and standalone NMRS. NMRS and multipath service nodes jointly provide data relay services for users.

NMRS is the core component of the MPTS-ICN architecture, which maintains and manages the mapping relationship between the MPSID and the multipath service node NAs. NMRS usually includes the Global Name Mapping and Resolution System (GNMRS) and the Local Name Mapping and Resolution System (LNMRS) [30]. GNMRS is a general global information service system, which is generally deployed in the cloud to ensure the full storage of the whole network identifier-address mapping correlation and the accessibility of content. LNMRS is a distributed autonomous service system based on a hierarchical structure of service levels. It is distributed at the edge of the network and can ensure low latency for analytical services. Therefore, NMRS does not have a significant impact on the performance of multipath transmission systems.

The multipath service node provides users with the executive function of a data relay service. In the process of data transmission, the multipath service node can identify ICN data packets with multipath preference fields and change the destination address according to the destination EID query result in the ICN data packet. Then, the multipath service node reroutes and forwards the packet according to the new destination address. This paper uses a single-hop relay scheme because some studies have shown that using a single relay can provide performance close to that of using multiple relays [35,36]. Therefore, the destination address changed by the multipath service node is the network address of the receiver. A large number of multipath service nodes provide more path choices for data transmission between different source and destination nodes. Multipath service nodes can be deployed in various ways, such as in key locations of the network through system configuration based on network topology information. Or, based on the self-decision ability of ICN nodes, nodes with low link bandwidth utilization and high data packet forwarding ability can register themselves to NMRS as multipath service nodes.

The edge node is a logical entity that performs data sending and receiving along multiple paths. Edge nodes query the set of multipath service nodes corresponding to MPSID from NMRS, and establish a multipath forwarding information table locally according to the node selection strategy. In the process of data transmission, edge nodes can identify ICN data packets with multipath preference fields, and distribute data packets to different multipath service nodes according to the multipath forwarding information table stored locally and scheduling strategy to realize multipath transmission of data.

The designed multipath transmission process is as follows:

• Based on historical transmission information, ICN nodes with low-link bandwidth utilization and high data-packet forwarding capability can register the mapping of MPSID and NA to NMRS and become multipath service nodes. Similarly, when the processing capacity of the multipath service node is not enough to support multipath transmission, the mapping of MPSID to the local node NA is canceled to NMRS and becomes an ordinary ICN node. In addition, the deployment of multipath service nodes can also be through the ICN network control plane function, according to the network topology information to select the node at the key location of the topology to NMRS registration as a multipath service node.
• The ICN edge nodes that support multipath services periodically query NMRS for the mapping of MPSID and multipath service node NAs to obtain a list of multipath service node NAs. According to the node selection strategy, the edge node selects multiple appropriate candidate nodes from the NAs’ list of multipath service nodes and establishes or updates the multipath forwarding information table locally.
• MPTS-ICN adopts a pull-based data communication mode. Compared with the push-based communication mode, the pull-based communication mode can support built-in multicast delivery, receiver-oriented congestion control and consumer mobility [37]. Consumers with multipath service requirements use the ID-based multipath transmission protocol described in detail below to send multiple NDC request packets to producers, and consumers set the preference field of the request packet as multipath preference.
• After the producer receives the NDC request message with the multipath preference field, the preference field of the corresponding NDC data message is set to multipath preference and forwarded to the ICN edge node supporting multipath service.
• ICN edge nodes supporting multipath services can identify NDC data packets with multipath preference fields, and obtain the index of multipath service nodes according to the data scheduling strategy (e.g., Round-Robin) and the source ID field of NDC data packets. The edge nodes obtain the value of the selected index from the local multipath forwarding information tables as the multiple service node NA, and changethe destination IP of the NDC data packet to the IP of the multipath service node and re-encapsulates it as a new packet through the ID/NA collaboration and refactoring function [30]. Edge nodes forward NDC data packets to corresponding multipath service nodes according to the destination IP.
• The multipath service nodes can identify NDC data packets with multipath preference fields and obtain the consumer NA from the NMRS query through the destination ID field of the NDC data packet. The multipath service node changes the destination IP of the NDC data packet to the consumer IP through ID/NA coordination and refactoring. The multipath service node forwards the NDC data packet to the consumer according to the destination IP.
• In the process of multipath transmission, consumers can increase or decrease the number of NDCs requested simultaneously according to their throughput. When all the NDC required by the consumer is transmitted, the multipath transmission process ends.

3.2. ID-Based Multipath Transmission Protocol

The multipath transmission protocol in the MPTS-ICN architecture uses IP addresses for routing, so all messages are encapsulated as IP packets. The identifier is an important part of the ICN network. In order to be able to process the identifier in the network, the ID-related fields are added to the data packet header during the data packet design. The ID-related fields are located above the IP layer and belong to the network layer. The IP layer protocol mainly includes the IPv4 protocol and the IPv6 protocol. An unallocated value (e.g., 0 × 99) can be set for the “Protocol” field of IPv4 or the “Next Header” field of IPv6 to indicate that the IP header is followed by the ID header. Compared with IPv4, IPv6 has a larger address space and a smaller routing table, enhanced multicast support support for convection, and added support for automatic configuration and higher security. In this paper, the Identifier Protocol (IDP) is proposed based on IPv6 extension; Figure 2 shows the IDP protocol layer layout. IDP defines a set of rules and regulations to specify how to operate the IP address field of the packet according to the ID of the network layer under the separation of ICN identity and location [37]. In the network layer, the ID header is the last header of the extension header defined in ipv6.

The ID header mainly includes the Next Header field, source ID type field, destination ID type field, source ID field, destination ID field, and so on. The Next Header field is used to specify which transport protocol the transport layer uses for the next processing of the data message. Transport layer protocols can be TCP (protocol field value 6), UDP (protocol field value 17), or custom ICN transport layer protocols (e.g., SeaDP [37]). Since the flat naming method is used to identify various entities (e.g., devices, data chunks, services, etc.) in the network, it is necessary to classify the IDs to adapt to different transmission scenarios. In the ID header, two fields are used to identify the source ID type and the destination ID type, respectively. In order to support multipath services at the network layer, we add a preference field to the ID header to identify multipath data packets. At the same time, we extend the function of IDP so that ICN routers can process multipath data packets. The design of the IDP protocol transforms the transmission mode of the network from IP-to-IP to ID-to-ID, so it can better support the realization of mobility and the network as a service. Ordinary IP routers cannot identify the ID header, the data packets will be forwarded in accordance with the IP layer protocol. ICN routers that support the IDP protocol can perform corresponding actions based on the defined rules and protocols according to the ID header field, such as deleting some carried addresses from the IP address field, changing the destination address, or performing in-network caching at the ICN router.

For multipath transmission services, there are two main types of data packets: multipath content request packets and multipath content data packets. In this article, we use different types of IDs to handle multipath transfer services, as shown in Figure 3. First, the edge node queries the NAs of multipath service nodes through the service ID. In this paper, we use MPSID and send the MPSID query message to NMRS. After receiving the MPSID query message, NMRS queries the locally stored ID-NA mapping table, encapsulates the query result as an MPSID reply message and sends it to the edge node. Edge nodes establish a multipath forwarding information table according to query results and node selection strategy. At the beginning of data transmission, consumers use the consumer device ID as the source ID, the producer device ID as the destination ID, and the transport layer message contains the requested data chunk ID list to request multiple NDCs from the producer. Producers send NDC data packets to consumers using the data chunk ID as the source ID and the consumer device ID as the destination ID. According to the source ID field of the NDC data packet, the edge node of the producer changes the destination IP of the NDC data packet to the multipath service node IP at the index position of the local multipath forwarding information table through the IDP protocol and forwards it. The multipath service node can identify NDC data packets with multipath preference and query the consumer’s IP to NMRS through the destination ID field of NDC data packets. Based on the query results, the multipath service node changes the destination IP of the NDC data packet to the consumer’s IP and forwards it.

In the above approach, the NDC message sent by the producer reaches the consumer through multiple paths. In the process of multipath transmission, the ID field of the NDC data packet remains unchanged, and the destination IP of the data packet is modified by the edge node and the multipath service node to realize the rerouting. During rerouting, sub-traffic between producers and consumers is transmitted in two stages. Firstly, the producer-side edge node orients each sub-flow to the multipath service node on its sub-path. Subsequently, each multipath service node forwards the received sub-traffic to the final consumer end. In physical networks, traffic is first routed from the producer to the multipath service node according to the shortest path-based protocol (e.g., OSPF), and then from the multipath service node to the consumer.

4. Multipath Service Node Selection Algorithm

4.1. Motivation

In the MPTS-ICN architecture, selecting the appropriate multipath service node is key to building multipath transmission. The multipath service node forms a mapping relationship between the node NA and MPSID in NMRS to provide alternative paths for the edge node multipath service. The edge node obtains the available multipath service node set M by querying the address list corresponding to MPSID from NMRS. Since the number of multipath service nodes obtained by NMRS is much higher than that required by edge nodes, and the maintenance of multipath service node information also requires additional overhead, edge nodes need to filter the nodes in the multipath service node set M according to certain strategies. Here, we set the size of the multipath service node set M returned by NMRS to m, and the size of the multipath service node set K required by the edge node to k, and then the multipath service node selection of the edge node has $C_m^k$ possibilities. The setting of the k value is the key. A k value that is too low cannot meet the performance requirements of multipath transmission, while an overly large k value is unrealistic and inefficient. Related research work [35] shows that the appropriate value of k is 3 or 4. In this paper, the selection of multipath service nodes mainly considers two factors: path link overlap and path link state.

Path link overlap directly affects the bandwidth aggregation of multipath transmission and the tolerance for link anomalies. For bandwidth aggregation, two paths with low link overlap can aggregate more bandwidth resources. If there is an intersecting link between the two paths, the two paths will share the bandwidth resources of the link, resulting in less bandwidth aggregation between the two paths. For link anomaly tolerance, the two paths with low link overlap can improve the transmission fault tolerance between paths. When the shared link of the two paths is congested, the two paths will be congested at the same time. The path link coincidence degree depends on the number of coincident nodes and the length of the path. The link coincidence degree between two paths is calculated as shown in Equation (1). $Par{h}_i$ and $Pat{h}_j$ represent paths i and j. A path is a sequence of nodes. $L{O}_{ij}$ represents the number of nodes that overlap between two paths, $L_i$ represents the number of nodes in path i, and $L_j$ represents the number of nodes in path j.

$$OverlapRatio(Pat{h}_i,Pat{h}_j)=\frac{2\times L{O}_{ij}}{L_i+L_j}$$

(1)

If only the path link overlap factor is considered, the multipath service node set K selected by the edge node satisfies the Equation (2).

$$K=\underset{C_m^k}{min}arg\sum _{i=1}^k\sum _{j=i+1}^{k}OverlapRatio(Pat{h}_i,Pat{h}_j)$$

(2)

Path link state determines the upper limit of multipath transmission resource aggregation. The factors that determine the path link state mainly include bandwidth, delay, and packet loss rate. According to the bandwidth, delay and packet loss rate in Equation (3), the link state of the path is calculated. $\alpha$ represents the influence factor of bandwidth on path link state, and $\beta$ represents the influence factor of round-trip delay on path link state. In the actual system, $\alpha$ and $\beta$ need to be optimized. $p_i$ represents the packet loss rate of path i, which reflects the congestion degree of path. Since packet-loss recovery takes a long time, the sigmoid function is used to characterize its importance, as defined in Equation (4). $p_0$ is the average packet loss rate, according to experience, it generally takes $p_0$ = 0.03. The importance of the packet-loss rate in the path link state can be altered by adjusting the $\gamma$ value in the sigmoid function. If the packet-loss rate factor is not considered, the packet-loss rate for each path can be set to 0.

$$PathStatus\left(Pat{h}_i\right)=(\alpha \times Bandwidt{h}_i+\beta /RT{T}_i)\times sigmoid(p_i-p_0)$$

(3)

$$sigmoid\left(x\right)=1/(1+e^{\gamma \times x})$$

(4)

4.2. Node Selection Algorithm

Researchers have proposed many solutions to the problem of intermediate node selection for multipath relay transmission [35,38,39]. Gummadi et al. proposed the Random-K method to solve the problem of how to select the intermediate one-hop nodes [35]. Random-K randomly selects K nodes from the set of candidate nodes, and selects the node that responds first as the intermediate node. Random selection algorithm is relatively simple, but it is difficult to guarantee the quality of the path. Liao et al. included node centrality and path difference in the consideration of node selection, and proposed an incremental heuristic algorithm to obtain the relay node set [38]. This method requires global topology information and calculation of node betweenness centrality, which has large overhead and scalability problems. Guan et al. used some geometric mechanisms to select intermediate nodes in the view based on spatial coordinates, and used the link offset angle to characterize the correlation between relay links [39]. This method only considers the impact of path overlap on multipath transmission performance without considering the link state factor.

In the multipath transmission scenario, high link overlap between sub-paths or poor link state of sub-paths will lead to low data transmission performance. It is not enough to select nodes only by path link overlap or path state, especially in application scenarios with high throughput requirements. Therefore, we consider the independence between sub-paths and the link state of the path as the criteria for node selection.

Many existing network service providers have deployed different bearer networks in the same geographical area to provide data communication services for users, making the bearer network rich in link resources. Autonomous systems (AS) arethe basic unit of the bearer network, different AS will cover the same geographical area. In these geographical regions, different ASes are relatively independent, and data can only be exchanged at the network exchange exit, so that different AS internal paths have a lower degree of intersection. Therefore, when multipath transmission is required between two geographical regions, if there are multiple ASs covering these two regions, the low link overlap between sub-paths can be guaranteed by selecting multipath service nodes within different ASs. Since there may be multiple multipath service nodes in the same AS, the sub-paths constructed by these nodes often have high link overlap. Therefore, for multipath service nodes belonging to the same AS, we calculate the path link state between the edge node and each multipath service node through Equation (3), and select the optimal node.

As mentioned above, we propose a cluster-based multipath service node selection method, CMSNS. Edge nodes that support multipath services obtain multipath service node sets through NMRS when they are online. In order to ensure a low path link overlap, each multipath service node registers its device information to NMRS according to TAG, and the TAG value is AS number. In order to make full use of low-load links and ensure a lower path link overlap, edge nodes perform a path state-aware node selection algorithm aggregated according to TAG. The edge nodes first classify the multipath service node set according to the TAG value, then detect the path state information of the multipath service nodes in each classification, and select the optimal node to join the candidate node set. The node selection algorithm executed by edge nodes takes the set of multipath service nodes returned by NMRS as input and the set of optimal candidate nodes as output. The symbols used in the algorithm are shown in

Table 1. The meaning of symbols.

Symbol	Meaning	Symbol	Meaning
M	List of multipath service node sets	$p_0$	Average packet loss rate
K	List of optimal candidate node sets	$\gamma$	Influence factors of packet loss rate on path state
$\alpha$	Influence factors of bandwidth on path state	KTag	Tag value list of nodes in K
$\beta$	Influence factor of round-trip delay on path state

and the execution steps of Algorithm 1 are as follows:

Step 1: Initialization: $\alpha =2,\beta =2500,p_0=0.03,\gamma =200,K=\{⌀\},$$KTag=\{⌀\},$$M=\left\{m\right\}$;

Step 2: For each multipath service node m in M, the edge node sends the Path State Detection Information to m to obtain the bandwidth, round-trip delay, packet loss rate and other information of the path between the edge node and m, then gose to Step 3.

Step 3: According to Equation (3), the link state of each path is calculated, and the nodes in M are sorted according to the path link state.

Step 4: First, the node with the best path link state is selected from M, and whether the node is in the same AS as the existing nodes in K is judged according to the TAG value. If the node is not in the same AS as the existing nodes in K, it joins K; otherwise, try the next node.

Step 5: Check whether all m in M has been accessed. If satisfied, go to Step 6; otherwise, return to Step 2.

Step 6: Output the optimal candidate set K with the best path state and the lowest link overlap.

Algorithm 1 Multipath Service Node Selection Algorithm.

Input:  List of multipath service node set M Output:  List of candidate node set K 1: Initialization: $\alpha =2,\beta =2500,p_0=0.03,\gamma =200,K=\{⌀\},KTag=\{⌀\}$ 2: for each i in M do 3:    Send Link Detection Message to m and get $RT{T}_m,Bandwidt{h}_m,p_m$ 4:    Calculate $Pathstatus\left(Pat{h}_m\right)\leftarrow Eq.\left(3\right)$ 5: end for 6: $soretedList\leftarrow sort\left(M\right)byPathstatus$ 7: for each i in sortedList do 8:    if i.Tag not in KTag then 9:      K.add(i) 10:    KTag.add(i.Tag) 11:    end if 12: end for 13: Return K

The main overhead of the multipath transmission system proposed in this paper is determined by the complexity of the multipath service node selection algorithm. Assume that the number of multipath service nodes is M and the number of paths is k. The complexity of the incremental heuristic method in [38] is O (k × M × d), where d is the diameter of the network. O (k × d) comes from the calculation of overlap. The method proposed in this paper uses the independence between autonomous systems to ensure the independence between paths and does not need to calculate the path overlap, so the time complexity is O(M). This shows that our method is simple and scalable.

5. Simulation Results and Analysis

In this section, we used the NS3 network simulator to evaluate the MPTS-ICN performance.

5.1. Simulation Design

We simulate a simple network consisting of two ICN edge nodes (one for the source and one for the destination), a name resolution system, and multiple multipath service nodes. They are connected by links, where the network metrics can be arbitrarily set according to different simulation requirements. Adjustable network indicators include delay, bandwidth, packet loss rate, etc. The topology we use is a multipath topology, as shown in Figure 4. The topology of Figure 4 represents the infrastructure of the future Internet, and there are multiple completely disjoint paths between Internet service providers (ISPs). To further evaluate the performance of our proposed node selection algorithm, we use the topology shown in Figure 5, which contains three different AS domains. By default, the link capacity of the two topologies is 10 Mbps, and the link delay is 10 ms.Then the corresponding network indicators are changed as needed.

5.2. Simulation Analysis

We focus on the impact of MPTS-ICN on throughput and transmission time in ID-based data chunk transmission.

5.2.1. Effect of Path Bandwidth Capacity

This experiment aims to explore the impact of bandwidth capacity and bandwidth differences on multiple paths that can be used for data transmission. The bandwidth of the data transmission path is determined by the minimum bandwidth of all links on the path. Let Sr denote the bandwidth requirement of the data receiving end, where we set 50 Mbps, and $b_i$ denote the bandwidth of the ith subpath. $\alpha =b_1/Sr$, which represents the ratio of the default path bandwidth to the data receiver bandwidth requirement. As $\alpha$ increases, the default path has more bandwidth resources. For example, when $\alpha =2$, the default path bandwidth resource is twice the data source bandwidth requirement. In this experiment, we set the range of $\alpha$ values as [0.3, 1.5]. The bandwidth of the i-th subpath is $1/i^{\beta }$ of the default path bandwidth, where $0<=\beta <=1$ denotes the skew factor. When $\beta =0$, indicates that all subpaths have the same bandwidth. With the increase of $\beta$, the bandwidth distribution between multiple sub-paths of data source and data receiver is more skewed. When $\beta =1$, the bandwidth ratio of the four sub-paths is 12:6:4:3. In this experiment, except for bandwidth, other network indicators are the same in all sub-paths. In this experiment, the data chunk size requested by the data receiver is 2M, and the number of requests is 10.

Figure 6 shows the change curve of data transmission completion time with $\alpha$ and k. In this experiment, the value of the skewness factor $\beta$ is 0, 0.5, 1. From Figure 6a, we can see that in the range [0.3, 1.5] of $\alpha$, the data transfer completion time decreases as k increases. This shows that using multiple paths for concurrent data transmission can effectively provide bandwidth aggregation. At the same time, we note that the decrease in the data transfer completion time slows down as $\alpha$ increases, especially when $\alpha >1$. This shows that multipath transmission has a good effect in bandwidth-constrained scenarios, but not in bandwidth-unconstrained scenarios. On the other hand, we note that the decrease rate of data transmission completion time decreases with the increase of k, which indicates that a smaller k value (k = 2 or 3) can obtain most of the performance gains of multipath transmission and reduce the overhead of path maintenance.

From Figure 6b, we can see that when $\beta =0.5$, the above results still hold, indicating that multipathing works well regardless of whether the subpath bandwidth distribution is uniform or not. However, in Figure 6c, we can see that multipath transmission does not have a good effect. This is because in this experiment, the scheduling strategy we adopted is a Round-Robin strategy. When the path bandwidth difference is too large, the completion time of data transmission at the data receiver will be limited to the sub-path with the lowest bandwidth resource. In the next section, we will discuss the impact of data scheduling strategies on multipath transmission performance.

5.2.2. Effect of Data Scheduling Strategies

This experiment aims to explore the impact of data scheduling strategies on multipath transmission performance. Here, we also use the topology of Figure 4. In this experiment, we set the data receiving rate of the data receiver not to exceed 50 Mbits/s, and the number of available paths k = 4. The four paths are PATH1 (C1-R1-R3-R7-R2-S1), PATH2 (C1-R1-R4-R8-R2-S1), PATH3 (C1-R1-R5-R9-R2-S1) and PATH4 (C1-R1-R6-R10-R2-S1). To simulate the difference in path bandwidth, we set the bandwidth ratio of the four sub-paths to 4:3:2:1. Except for the difference in path bandwidth, other network metrics of the 4 sub-paths are the same. This experiment attempts a variety of data scheduling strategies, the first is random selection strategy, followed Round-Robin strategy. The random selection strategy will randomly select one from the multipath forwarding information table stored locally by the edge node, and the Round-Robin strategy will select one by one. In addition, in order to give full play to the advantages of multipath, we have designed a new multipath data scheduling strategy WCDS, which can allocate data chunks according to the weight of the path. The weight value of the path is calculated by Equation (3).

This experiment will analyze three data scheduling strategies from two aspects of data transmission completion time and throughput. It can be seen from Figure 7 that when the path bandwidth difference between sub-paths is large, the random selection strategy and the Round-Robin strategy are not as good as our proposed strategy of allocating data chunks according to path weights. This is because, in the scenario of path bandwidth differences, the completion time of data transmission based on random and Round-Robin strategies is limited to the completion time of data transmission on sub-paths with the lowest path bandwidth. However, our proposed strategy can allocate the number of data chunks according to the weight of the path, which leads to the completion time of data transmission being only related to the overall size of the data and the total bandwidth of the four sub-paths, not limited to a specific sub-path. In addition, we note that as the number of data chunks transmitted increases, our proposed strategy has a shorter transmission completion time. This shows that our proposed strategy can achieve better results in the scenario of big data transmission.

Figure 8 shows the throughput difference between the three data scheduling strategies in the scenario of transmitting 10 data chunks, each data chunk size is 2 M. From Figure 8a,b, we note that the throughput at the data receiver decreases over time. This is because in the scenario of path bandwidth difference, the sub-path with higher bandwidth resources takes the lead in completing the data chunk transmission task assigned to the path. However, at the same time, the sub-path with lower bandwidth resources still has more data chunks to transmit, resulting in a decrease in the throughput of the data receiver. As the throughput decreases, the data transmission completion time at the data receiver gradually increases. From Figure 8c, we can see that our proposed strategy can maintain high throughput for a long time. This is because our proposed strategy can allocate the number of data chunks according to the weight of the path, which leads to the completion time of data transmission no longer being limited to the bandwidth resources of a specific path but the total bandwidth resources of all sub-paths.

5.2.3. Effect of Node Selection Algorithm

This experiment aims to explore the impact of different node selection algorithms on multipath transmission performance. Here, we use the topology of Figure 5. In Figure 5, we use the Agis topology, Sprint topology, and Ans topology in the The Internet Topology Zoo [40] dataset as the internal topologies of AS101, AS102, and AS103, as shown in Figure 9. In Figure 9, the green node represents the access node, and the yellow node represents the exit node. Each AS has only one access node and one exit node. We set the link bandwidth of the AS internal topology to 10 Mbps, the delay is set to 10 ms, the access bandwidth of the data receiver and the data sender is set to 30 Mbps, and the delay is set to 1 ms. In this experiment, we randomly select 3 nodes in each AS to form a multipath service node set, and the number of paths selected by edge nodes is k = 3.

In order to evaluate the performance of our proposed node selection algorithm, we compare it with three other algorithms: Random Selection Algorithm (RSM) [35,41], Node Degree Based Selection (SND) [38] and LB-OOMR [38]. The RSM algorithm randomly selects k nodes from the candidate node set. The SND algorithm greedily selects k nodes with more edges. The LB-OOMR algorithm is based on the betweenness centrality of the candidate nodes, and selects the k nodes with the highest betweenness centrality from the candidate nodes. Figure 10 shows the throughput changes under different selection algorithms. From Figure 10, we note that our proposed algorithm has higher throughput, followed by RSM algorithm and LB-OOMR algorithm, while SND algorithm has lower throughput. This is because our proposed algorithm takes into account the path link overlap factor, through the independence between AS to protect the independence between paths. The SND algorithm has more k nodes in the same AS domain, resulting in mutual influence between sub-paths, resulting in a decrease in throughput.

Figure 11 shows the packet loss rates of each sub-path and the average packet loss rates under different node selection algorithms. From Figure 11, we notice that Path2 and Path3 of RSM algorithm, SND algorithm and LB-OOMR algorithm have higher packet loss rates, increasing in the average packet loss rates. This is because the two sub-paths are in the same AS domain, and there are overlapping links between the two paths. On the overlapping link, the two sub-paths compete for the common bandwidth resources, increasing in the packet loss rates on their respective paths. However, our proposed algorithm can guarantee the independence between sub-paths, so there is no case where multiple sub-paths compete for the same link resource. This experiment shows that compared with RSM, SND and LB-OOMR, our proposed algorithm can give full play to the advantages of multipath.

5.2.4. Comparison with Existing Data Transmission Schemes

We compare our multipath transmission scheme with the common data transmission schemes, Single-TCP and ECMP. In this experiment, we simulate the transmission scenarios of four data streams (C1-S1, C2-S2, C3-S3, C4-S4). The network topology is shown in Figure 4. The access bandwidth of the data receiver and the data sender is set to 50 Mbps, and the delay is set to 1 ms. The link bandwidth is set to 10 Mbps and the delay is set to 10 ms. In this experiment, 10 M data is first sent from S1 to C1. Then a data stream is started every 5 s. The Single-TCP scheme adopts the TCP implementation scheme of the NS3 network simulator, and the ECMP scheme adopts the scheme implemented in the Reference [42]. The granularity of data transmission is packet granularity. In our multipath transmission scheme, the data receiver requests the same size of data from the data sender, and the granularity of data transmission is chunk granularity.

Figure 12 shows the throughput changes of Single-TCP, ECMP and our proposed schemes and the completion time of each flow. Single-TCP has a long flow completion time and large transmission jitter. This is because, in the Single-TCP scheme, four flows choose the same path, resulting in network congestion, thereby reducing the sending rate. The ECMP scheme has a shorter flow completion time than the Single-TCP scheme. This is because, in addition to the default path, the ECMP scheme re-selects another path, thereby reducing the interaction between flows. However, in the ECMP scheme, three flows also chose the same path, failing to take full advantage of multipath. In our scheme, the peak traffic per flow can reach 40 Mbps, while Single-TCP and ECMP can only reach 10 Mbps. This is because each flow of Single-TCP and ECMP can only select one path, whereas our scheme can use more paths and split the data flow, thereby reducing the data flow completion time.

Figure 13 shows each flow completion time and the average flow completion time in Single-TCP, ECMP, and our proposed scheme. We can see that our proposed scheme has a shorter flow completion time and an average flow completion time than Single-TCP and ECMP. This is because our scheme can provide multipath resources for each flow, while in Single-TCP and ECMP schemes, only one path can be selected for each flow. Therefore, our scheme can give full play to the advantages of multipath and is independent of specific flows.

As seen from

Table 2. Flow completion time under different methods.

Method	Flow1	Flow2	Flow3	Flow4	Average
Single-TCP	19 s	27 s	26 s	28 s	25 s
ECMP	19 s	26 s	22 s	14 s	20.25 s
MPTS-ICN	4.1 s	4.1 s	4.1 s	4.1 s	4.1 s

, MPTS-ICN has the shortest flow completion time, and Single-TCP has the longest flow completion time. Furthermore, MPTS-ICN outperforms Single-TCP method by 83.6% and the ECMP method by 79.7% in average flow completion time.

6. Conclusions

This paper presents the design and evaluation of MPTS-ICN, which achieves multipath data transmission through single-hop network node relay and significantly enhances content delivery in ICN. In our proposed scheme, ICN edge nodes split the traffic and reroute it to the destination along multiple one-hop disjoint paths established using a set of multipath service nodes. Compared with other multipath transmission methods, our proposed scheme has no specific requirements for the network settings of terminal devices and does not require modification of the existing network devices. Therefore, it is easy to implement and deploy. In order to distinguish between ordinary data packets and multipath data packets, we extend the original network layer protocol to support multipath data transmission in ICN networks. In addition, we select multipath service nodes based on the link overlap of paths and the link state of paths and assign data chunks based on the weight of paths to ensure the performance of multipath transmission. The experimental results show that our proposed scheme outperforms the best-route method by 83.6% and the ECMP method by 79.7% in average flow completion time. Therefore, MPTS-ICN is more efficient compared with existing data transmission methods in terms of bandwidth usage and transfer time.

In the design of the multipath service node selection algorithm, this paper only considers the independence between autonomous systems to ensure the independence between paths. However, there are also rich link resources available within the autonomous system, and there may not be multiple autonomous systems in some geographical areas. Therefore, using the rich link resources within the autonomous system is one of our future research directions. In addition, the data scheduling strategy employed in this paper is currently only based on the weight of the path to allocate ICN data chunks, which cannot adapt to the dynamic changes of the path state. In future work, we will redesign the data scheduling strategy to adapt to the dynamic changes of the path state.