Identifier-locator network protocol (ILNP) is a host-based identifier/locator split architecture scheme (ILSA), which depends on address rewriting to support end-to-end mobility and multihoming. The address rewriting is performed by hosts using a network layer logical cache that stores state information related to the communicated hosts, which is called identifier-locator communication cache (ILCC). Since address rewriting is executed on a packet basis in ILNP, ILCC lookups are required at each packet reception and transmission. This leads to a strong correlation between the host’s network stack performance and ILCC performance. This paper presents a study of the effect of ILCC size on network stack performance. Within this paper, a direct comparison of the performance of two ILNP prototypes that differ by ILCC management mechanism is conducted. We present ILCC size measurements and study their effects on the host’s network stack performance. The results show that ILCC growth caused by correspondents increase has a significant effect on the latency of both network and transport layers. The obtained results show that controlling ILCC size through an effective policy strongly enhances ILNP network stack performance.
In the last two decades, as a result of many research efforts, there is a common recognition that Internet routing and addressing architecture is encountering challenges in scalability, multihoming, and interdomain traffic engineering [
One of the host-based ILSA schemes is ILNP. The architectural concept of ILNP replaces the present address space (IP) with two address spaces, specifically the locators and identifiers. The architectural concept of ILNP is independent of the IP version, but it adapts the same packet format, and thus, there are two variants of ILNP: ILNPv4, which is based on IPv4 packet format, and ILNPv6, which is based on IPv6 packet format [
ILNP provides an enhancement to current Internet architecture via enriching the set of used namespaces instead of adopting a clean slate namespace. It adapts the evolutionary approach, which assumes that IP will remain the namespace for the Internet. Based on that assumption, it detaches the semantics overloading of IP by splitting between the node identifier (NID), which is a nontopological name uniquely identifying a node, and the locator (Loc), which is a topologically bound name for an IP subnetwork. Therefore, in IPv6 packet headers, each 128 bit IPv6 address is separated into 64 bits for the Loc and 64 bits for NID [
As RFC6741 [
As a protocol address rewriting facility, ILCC must always provide up-to-date mapping information among Locs and NIDs. Consequently, ILCC’s lookups became a critical part of every packet reception and transmission in the ILNP protocol stack. In ILNP transmission, the network layer receives only the local and remote NIDs from the upper layer. After that, it chooses the most favorable Locs for both remote and local hosts from the ILCC. Likewise in reception, when network layer receives a packet for local delivery, it extracts two pairs of NIDs and Locs belonging to remote and local host from packet header, and afterwards, the network layer conducts a validity check on the extracted pairs and decides either to proceed in packet reception or drop it. After passing the former check, the network layer will only handle NIDs to the transport layer. More details about this process can be found in RFC6740 [
In this paper, we investigate the performance of two ILNPv6 prototypes when user datagram protocol (UDP) is used as a transport layer protocol. The first prototype is developed by the University of St. Andrews and available at [
The key contributions of this paper are as follows: We conducted a comprehensive comparison between two ILNPv6 prototypes in terms of ILCC size and packet serving and dropping rates We measured the latency introduced by both prototypes at different network stack layers We also performed a system profiling for the prototypes and analyzed the internal load distribution of each one Based on the previous results, we showed how ILCC uncontrolled growth can introduce a significant kernel latency, and how a worst-case scenario, for example, by a malicious or bugged host, can increase the latency by several milliseconds and how to avoid this worst-case latency
The rest of the paper is organized as follows: a review of related work is presented in Section
ILNP is one of the evolutionary solutions recommended by the Internet research task force (IRTF) routing research group to enhance current Internet routing architecture. It was the subject of many types of researches. For instance, Abid et al. [
While the previous work on ILNP either provides an analytical model to study the ILNP performance [
RFC6741 [
In order to overcome the problem of uncontrolled ILCC growth when hosts exchange data over UDP, we introduced in a previous work [
ILCC entries with different types of UDP socket.
Server | |||
---|---|---|---|
Connected UDP socket | Nonconnected UDP socket | ||
Client | Connected UDP socket | (i) ILCC entry required (if available resources allow) | (i) LCC entry required (if available resources allow) |
Nonconnected UDP socket | (i) ILCC entry required (if available resources allow) | (i) ILCC entry adoption must be avoided |
Later on, we will refer to the Linux kernel that runs the prototype of the University of St. Andrews as “without policy” kernel and “with policy” kernel to the kernel that runs our prototype.
The following section describes the used test environment, developed traffic generator, evaluation scenarios, and used toolset.
In the conducted experiments, data were sent over ILNPv6 in one direction between two hosts. As shown in Figure
Experiment network and topology.
Features of testbed hardware and software.
Source VM | Target VM | |
---|---|---|
CPU | Intel(R) Xeon(R) silver 4110 CPU @ 2.10 GHz (4 virtual CPUs) | Intel(R) Xeon(R) silver 4110 CPU @ 2.10 GHz (4 virtual CPUs) |
RAM | 4 GB DDR4 | 4 GB DDR4 |
Operating system | Ubuntu 18.04.1 LTS | Debian GNU/Linux 9 |
OS kernel | Linux 4.15.0–45-generic | A modified Linux kernel v4.9 or v4.4 |
Ethernet adapter | Intel 82545EM Gigabit Ethernet controller | Intel 82545EM Gigabit Ethernet controller |
Driver | vmxnet3 | vmxnet3 |
The developed traffic generator uses PF_PACKET sockets to generate specially constructed UDP over ILNPv6 packets, as this type of sockets provides a very powerful way to send data packets by directly accessing a network device [
Traffic generator architecture.
The generator has two kinds of generation processes to generate two different types of UDP datagrams. The first represents identical echo requests from a fixed source {NID, Loc} pair to an echo service running on the target. As the packet fields are constant in this case, the generation process of this kind is simple. After start-up, each process depends on a predefined packet template to initialize and fill all data structures required for the packets. Then, it enters a loop that depends on PF_PACKET sockets to send identical packets to the target for the duration specified by the master sh file. In the second type of UDP datagrams, each produced UDP packet has a randomly generated source NID. This type of UDP datagrams will be used to emulate an increase in the number of correspondents at the target. As a result, the generation processes of this kind are more complicated compared with the previous kind, and we will call them the load process. After start-up, each load process initializes and fills some data structures required for the packets. After that, it enters a loop to perform four operations: generating a random source NID, filling packets structure, calculating UDP pseudoheader checksum for ILNP using only source and destination NIDs as stated in [
Using the features listed in Table
Generated traffic volume.
During experiments, the number of load processes is changed from 0 to 10. The naming convention used in this work is as follows: the count of load processes represents the test rank. We will refer to each test with its rank and “Test” prefix. Test0 is the test with zero load process, and so on. Each test round lasts for 60 seconds.
As this work focuses on performance evaluation of ILNPv6 stack, data about the internal and external behavior of the target was gathered. To collect information about the external behavior of the ILNPv6 network stack during experiments
In transport layer test scenario, the target only runs an echo service that simply sends back to the originating source any data it receives. In this test scenario, an evaluation was conducted for the transport layer of the two ILNPv6 prototypes at two stages. In each stage, eleven tests were performed in order to fulfill the stage objective. The objective of the first stage is to measure ILCC size, delay added by the kernel, and packet serving and dropping rate, while the objective of the second stage is performing the target’s operating system profiling to obtain insight into the effect of the generated UDP traffic on ILNPv6 stack performance.
The performed eleven tests started with Test0 and ended with Test10. In Test0, only the first type of UDP packets was sent from source to target. This test was used to establish a baseline performance for each prototype. The percent of the second type of UDP datagram increased gradually from 0% in Test0 to 34% in Test10. In addition, the average number of UDP packets emitted by the source increased as tests progressed, starting with 1280 packets per second for Test0, and ending with 1940 packets per second at Test10 as shown in Figure
During the tests of the first stage,
In the second stage tests, three levels of profiling of the target were performed. The first level is system-wide to monitor the overall system load. The second is also system-wide and sheds light on load distribution between the target system’s three components: the user space, kernel space, and NIC’s driver during tests. The third level of the profiling was done within the kernel. To clarify the distribution of loads among the kernel’s functions, we divided these functions into two groups: the first includes just ILCC’s function, and the rest of kernel’s functions are located in the second group.
Using the same previous manner, the network layer tests are conducted in two stages, and each stage consists of eleven tests. These tests are carried out to demonstrate the security risk and performance deterioration resulting from adopting new ILCC entries in ILNP capable host only based on a pure network layer decision.
In the test scenario, the target is idle without any running service. When a host is in this state and receives UDP packets, as stated in RFC1122 [
The previously described traffic generator is used for network layer tests. Figure
At the first stage tests, the same toolset presented in previous section is used to monitor the internal and external behavior of the ILNPv6 network stack. During the conducted tests,
While the tests of the second stage are dedicated to perform a profiling of the target’s kernel, the profiling is done to illustrate the distribution of loads among the kernel’s functions. We divide these functions into two groups: the first includes just ILCC’s functions and the rest of the kernel’s functions are located in the second group.
All graphs represent measurements for different aspects of the target in two test scenarios. The first scenario is the transport layer scenario, and the second is the network layer scenario. Every scenario includes two stages with eleven tests in each. In each scenario, the same eleven tests were conducted in every stage. Every test in each stage was repeated ten times to obtain more accurate results and exclude marginal values. After that, the average values were obtained by aggregating the results. Based on that, the graphed measurements of each test aspect are the average values of ten iterations of the same test unless otherwise mentioned. The standard deviation is shown by error bars.
Here, we present the results obtained from collecting external and internal target behaviors during the conducted tests. The used performance metrics are as follows. ILCC size: the size of ILCC at the target during tests was measured; values close to zero are better; zero is ideal. Kernel latency: the delay added by the kernel, at both the network and transport layers, was measured at the target; lower values are better. Packets serving and dropping rates: the number of served and dropped packets at the target was measured; serving rate values close to the offered loads are better; while lower dropping rates are better, zero is ideal.
Moreover, the target system profile is presented to give insights about the effects of the generated traffic.
The following section presents ILCC size measurements for the conducted tests, as a first step towards understanding its effects on ILNP stack performance.
The kernel with policy kept a fixed ILCC size of zero entry overall tests. The reason, according to the adopted policy, is that as the data exchange between the two ends did not include any connected end, there was no need to create a record within ILCC to serve this exchange, while, in the kernel without policy, ILCC maintained a fixed size of one entry at Test0. However, in the rest of the tests, and with the presence of the second type of UDP datagrams, the ILCC size increased linearly with the number of emulated correspondents. Figure
ILCC growth over transport layer tests.
The UDP packets of the second type do not have any effect on ILCC size at the kernel with policy. This kernel preserves an empty ILCC over all conducted tests since no transport layer sockets are waiting for those packets. Consequently, the decision of the policy is not to add ILCC entries for those packets.
Although the target was idle, the kernel without policy maintained an empty ILCC at Test0. However, in the rest of the tests, and with the presence of the second type of UDP datagrams, the ILCC size increased linearly with the number of emulated correspondents despite the lacking of UDP sockets to serve those packets. Consistent with the results in the previous section, target had developed an upper threshold for ILCC size about 15 k entries. Figure
ILCC growth over network layer tests.
Each network stack has a latency impact at the host level. In ILNP stack, although ILCC is a fundamental component, the stack, as an optimization, should avoid unnecessary delays within ILCC responsibility; that is, for ILCC size and lookups cost, the ILNP network stack should carefully decide which entries to adopt in ILCC to reduce latency, while keeping the ability to fulfill its objectives. To further understand ILCC size effects on ILNP stack performance, the following section presents the latency introduced by both prototypes for the conducted tests.
Figure
Average of transport layer latency.
Figure
Average of network layer latency.
Since latency at host is strongly associated with packets serving and dropping rates, packets serving and dropping rates are presented in the following section.
As a result of increased latency at the kernel without policy, it exhibited a decreasing packet serving rate as tests processed. As shown in Figure
Average percentage of served echo requests.
Packets dropping rate was another aspect under monitoring in the evaluation. At each test, the number of dropped packets was obtained from NIC’s driver. The reason behind this drop, as reported by the NIC, was that its ring buffers were full, so there were no ready descriptors for the new packets. This indicates that, during tests, at some points, the packets’ arrival rate at NIC was greater than the rate at which the kernel reinitialized packet descriptors. This behavior was compatible with previous measures of transport layer latency and packet service rate.
Figure
Average percentage of dropped packets.
Number of dropped packets by the kernel without policy.
As the target was idle at network tests, there was no service rate to monitor, but only a drop rate. Figure
Average percentage of dropped packets.
This behavior was expected based on the previous measures of the network layer latency. As shown in the figure, the kernel with policy had no packets drop at all tests, whereas the kernel without policy exhibited the same previous behavior of dropping packets. The average percentage of dropped packets exceeded 25% starting from Test8.
Figure
Number of dropped packets by the kernel without policy.
To find out the main cause of performance degradation at the target, a profiling of the target’s kernel at several levels was performed. The results are as follows.
The following figures are presented to indicate the source of load that caused the target’s performance deterioration at the transport layer and the whole network stack, specifically when the target ran the kernel without policy. Figure
Average percentage of the target load.
In Figure
Percentage of kernel load.
The results of the third level of the target profiling are presented in Figure
In kernel ILCC function’s load.
Based on the previous results, it is clear that ILCC size has a significant impact on the performance of the transport layer and thus on all network stack. In the testbed, the impact was evident and led to poor performance at the kernel without policy. Moreover, these results are consistent with the conclusion in [
Figure
In kernel ILCC function’s load.
From these results, it is clear that although the target did not run any service, due to its adoption of new records within the ILCC based on a pure network layer decision, and not setting any restrictions on the growth of ILCC, it became vulnerable to DoS attack, taking into consideration that in our case the attack took less than 60 seconds.
Based on the previous results, it is evident that the kernel with policy outperforms the kernel without policy in terms of ILCC growth, the delay added by the kernel network stack at network layer, packet drop, and overhead resulted from the kernel’s function that deals with ILCC operations.
In this work, the effects of ILCC on the ILNPv6 stack are studied in detail at different network stack layers. We conduct a performance evaluation of two ILNPv6 prototype implementations and illustrate the way they handle different types of UDP traffic. One of the key differences between these prototypes is the policy used to manage ILCC. The first prototype was introduced by the University of St Andrews, while the other was developed by us.
In the evaluation, ILCC size, delay added by the kernel network stack at both network and transport layers, packet service and drop rates, and overhead resulting from the kernel’s function that deals with ILCC operations are measured. The results show that the St Andrews’s prototype experience uncontrolled ILCC growth as a normal result for its ILCC entries adoption policy. Consequently, this prototype suffers from a severe performance degradation in terms of network stack latency, service rate, drop rate, and system loads. Moreover, the host running this prototype is vulnerable to DoS attacks, while our prototype effectively controls ILCC size by carefully deciding which entries to adopt in ILCC, and thus, it outperforms the St Andrews’s prototype in all measured aspects.
Moreover, the results show that the introduced policy is a promising new technique to improve latency and performance for UDP traffic over ILNPv6 via avoiding unnecessary delays within ILCC responsibility. Therefore, we recommend adapting this policy within the protocol description and not leaving ILCC management as an engineering consideration up to the implementer.
However, this is the first work that presents a comprehensive performance evaluation of our prototype and its ILCC policy, and they should be subject to further studies with various scenarios and integration with other transport layer protocols. As future work, we plan to study ILCC growth effects on transmission control protocol (TCP) and host-based mobility.
No data were used to support this study.
The authors declare that they have no conflicts of interest.