Making use of SADR at the higher layers

[Juliusz Chroboczek <[e-mail]>]

I have been told that my comments after Jen's talk yesterday were not
clear to everyone, so please let me expand on them.

My summary of Jen's talk is:

    With the right network layer mechanisms, IPv6+SADR allows you to do
    everything you do with IPv4+NAT.

I fully agree with that statement (although not necessarily with the exact
details of the mechanisms).  However, I think a stronger statement stands:

  With the right network layer mechanisms, IPv6+SADR allows you to do
  everything you do with IPv4+NAT.  You can do even better if you
  additionally do some work at the higher layers.

A way to look at it is that SADR splits the multihoming problem into two
simpler problems: routing (done by the network) and selecting among the
available paths (done by the end hosts).  We've pretty much solved the
first problem, the second is an open research project.  Jen's approach
picks paths at the network layer, which is necessary for SADR-unaware
applications.  SADR-aware applications, however, can do their own picking,
which has the potential to improve the user experience.

I am fairly intimately familiar with two examples of such mechanisms that
have been fairly widely deployed: MP-TCP and the Vuze ML-DHT plugin for
BitTorrent.  I'll also say a few words about MP-Mosh, which was implemented
by my student Matthieu Boutier but not upstreamed yet.


1. MP-TCP

MP-TCP is an IETF standards track extension to TCP that aims to use all
available paths for data transfer; it can do both fallback and load-balancing.
Making good use of MP-TCP with IPv4+NAT is somewhat involved -- it requires
either using multiple interfaces on the host, or doing dirty hacks with
"virtual interfaces" and multiple IPv4 leases.  In an IPv6+SADR network,
MP-TCP works out of the box -- it probes all available source-dest pairs,
and performs fallback or load-balancing as necessary.

Our experiences with MP-TCP in an IPv6+SADR network are described in
Section VII.B of

  Matthieu Boutier and Juliusz Chroboczek.  Source-specific routing.  IFIP
  Networking 2015.
  https://arxiv.org/pdf/1403.0445.pdf

Don't bother reading, though -- we just say that it works out of the box,
way beter than we expected.


2. The Vuze BitTorrent ML-DHT plugin

Vuze is one of the major implementations of BitTorrent.  Vuze's ML-DHT
plugin implements "trackerless torrents" using a DHT.  Unlike the other
implementations of the BitTorrent DHT, ML-DHT runs an instance of the DHT
on every GUA assigned to the local host; the result is that, in an SADR
network, the BitTorrent traffic gets load-balanced across all available
paths.  This work was done by an individual who goes by the nickname
The8475, and as far as I know hasn't been written down anywhere.


3. MP-Mosh

Mosh is a remote shell implementation due to Keith Winstein (of congestion
control fame).  Unlike ssh, mosh doesn't transmit a command stream over
TCP, but instead uses a synchronisation mechanism that is layered directly
over UDP.  It has support for client-side roaming, but not server-side
roaming.

MP-Mosh is a modification to Mosh that uses all available paths
simultaneously, with the goal of allowing server-side roaming and
double-stack operation, while reducing latency.  In an IPv6+SADR network,
it will probe all available paths and send traffic over the one with the
lowest latency.

Our work with MP-Mosh hasn't been published yet, but you will find an
early draft on:

    https://arxiv.org/pdf/1502.02402.pdf


I can thing of other applications that will want to use upper-layer
mechanisms to optimise their traffic in IPv6+SADR networks.  The obvious
candidates are video streaming and video conferencing, and more generally
anything where increased throughput, reduced latency, higher reliability
are desired and you control both the client and the server.

-- Juliusz