# Mobility-Multihoming Duality
## 7 Discussion
### Route Selection at the Host  
The IP route metric-based mechanism normally provides immediate change to the route. This is without requiring modifications to the flow lookup process in the outgoing packet processing mechanisms within the packet processing path of the OS kernel. The flow lookup process is executed from distinct processing code paths for UDP and TCP. However,  
Figure 16: MP-TCP typical behaviour on the same testbed as for the ILNP evaluation. The distribution of the throughput is uneven, and changes to throughput on the individual interfaces are ‘bursty’. The vertical line shows the protocol level signalling (MP-TCP-specific multipath control plane protocol) to add or remove connectivity received at the respective IPv6 addresses. (**a**) Throughput facet plot of MP-TCP flow received at the MN. The top three plots show the throughput received at the addresses of the respective three interfaces at the MN, and the bottom plot shows the aggregate throughput. (**b**) Throughput facet plot of MP-TCP flow received at the CN. The top three plots show the throughputs received from the addresses of the respective three interfaces at the MN, and the bottom plot shows the aggregate throughput.  
such a mechanism does not allow multipath transport for a multihomed host to select paths on a per-packet basis.  
First, the route metric-based mechanism is less fine-grained and inflexible--as soon as a lower-metric route is added, the entire host's outgoing route handling changes. However, it is not possible to control the precise timing of this change, and it has no relation to the individual packets in the packet processing path.  
In order for ILNP to select a source L64 for multipath transport, the outgoing interface must correspond to the L64 selected by ILNP on a per-packet basis. However, the two distinct transport layer packet processing mechanisms select the outgoing interface at the early phase of their packet processing. This phase of packet processing had to be modified in order for ILNP to gain the ability to select the outgoing interface and the route such that the selected source L64 value would be reflected accordingly. The packet processing path involves a route lookup when the UDP and TCP packet headers are being constructed before they are passed onto the IP layer packet processing mechanisms. This is to ensure that the pseudo-header source address (and Checksum calculations) match the actual source address and the outgoing interface. In the context of a conventional IP, the actual source address and the respective outgoing interface do not change; therefore, they are cached after the initial lookup. However, that is not the case with ILNP, especially in the context of multihoming, where the packets in a flow may leave from different interfaces depending on the binding between local L64 values and interfaces.  
To enable multipath transport, specifically to allow ILNP to select the correct outgoing interface for each packet, the ILNP code needs full control of the route selection mechanism. In order to realise this, both the UDP and TCP packet processing mechanisms were modified to correctly set the outgoing route and the respective interface. Specifically, by preventing the caching of routes and triggering route lookup for every packet, ILNP gained the ability to control each packet accordingly.  
Note that this is all because of the inherent \"single-homed\" assumptions that are in IP implementations, even though IPv6 should support multihoming.