# Mobility-Multihoming Duality
## 6 Results of Evaluation
### Transport Layer Multipath Connectivity  
As noted in Section 2, multipath transport does not provide multihomed connectivity, but this is the way applications access multihoming when it is available. So, it is important to understand the action and behaviour of transport protocols. For our experiments, we see that a \"normal\" TCP (i.e., in this case a TCP CUBIC [52], as implemented in the Linux kernel) can be used successfully over an ILNP without the need for it to be mobile-aware or multihoming-aware. However, a multipath TCP (MP-TCP) is mature and is deployed, so we present here a brief comparison of our approach with MP-TCP. It was not possible to conduct a complete comparison for the following reasons:  
1. MP-TCP is a TCP only solution--comparison can only be made with TCP scenarios with ILNP. 2. MP-TCP is a transport layer solution that assumes that multihoming is in place, while ILNP operates at the network layer to provide multihoming. 3. MP-TCP does not implement mobility--multihoming duality--mobility is not the focus of the design, though it is possible to have mobile capability with MP-TCP [25]. 4. For our particular empirical evaluation (see below), the MP-TCP implementation available did not allow for the scheduler to change. MP-TCP's default scheduler was used, while ILNP used our DRR scheduler. The scenario and testbed was the same as for our ILNP evaluation with the configuration below, including some changes that were needed for the MP-TCP implementation:  
* Operating System: Debian Buster (Debian 10) was used, as its default kernel is version 4.19, to match the requirement for the v0.95.2 MP-TCP kernel. * MP-TCP kernel: v0.95.2 (available from github) [[https://github.com/multipath-tcp/mptcp/releases/tag/v0.95.2](https://github.com/multipath-tcp/mptcp/releases/tag/v0.95.2)]([https://github.com/multipath-tcp/mptcp/releases/tag/v0.95.2](https://github.com/multipath-tcp/mptcp/releases/tag/v0.95.2)) (accessed on 1 September 2024). * Path-manager: Set to 'fullmesh'. * Scheduler: Set to 'default'. This is the default scheduler setting recommended. This selects paths based on an RTT and congestion-window. * Routing: As required, a routing table was created for each interface. Existing scripts available on [[https://multipath-tcp.org](https://multipath-tcp.org)]([https://multipath-tcp.org](https://multipath-tcp.org)) (accessed on 1 September 2024) did not support IPv6, so a new script was written to achieve the same routing table configuration. * iproute2: A custom iproute2 was installed to disable an interface from being used by MP-TCP. The script was updated to make use of this in a similar manner to how ILNP has a sysctl configuration path to disable an interface. * iperf2: The same version of the iperf2 program was used for the ILNP evaluation. As for the ILNP evaluation, the MN moved from single connectivity to three-way connectivity gradually, then returned to single connectivity, and data from 20 runs were collected. This is in direct analogy to the procedure described for our measurements for TCP and UDP in Section 5.3. Both of the median throughputs recorded were 10.4 Mbps, as shown in Figure 15, which is as might be expected. If we consider a more detailed examination, due to the MP-TCP scheduler and its behaviour, the throughput distribution across the paths was very different to that of TCP with ILNP. Consider how Figure 15(a),b show the throughput values of a typical 120-second run as received at the MN and the CN for the MP-TCP. Clearly, the behaviour of the MP-TCP scheduler led to a 'bursty' traffic pattern across the network connections. Although the aggregate throughput is consistent, the 'bursty' behaviour of the transmission in MP-TCP could cause issues in the traffic management of the networks that the respective interfaces are connected to. Compare this to the smooth transitions with ILNP in Figures 11 and 12.