[RRG] Mobile robustness via layer 7, or multiple tunnels to TTRs

[Robin Whittle <rw@firstpr.com.au>]

Hi Brian,

In "Re: [RRG] Mobility frequency" you wrote:

> I think we should also remember Layer 7 mobility. There are many
> application suites that recover in one way or another from a low
> frequency of Layer 3 disconnects and re-addressing events, using
> Layer 7 identities to restore a connection and to maintain
> application state. This is so much established practice that it
> really gives us license to offer best-effort mobility at Layer 3.
>
> That doesn't mean we shouldn't strive for fast handover etc.,
> but ultimately it's the applications' job to survive connectivity
> problems.

I agree.

Any application which actually copes with a radio mobile situation
has to cope with the radio link being physically flaky or
inoperative, with no notice or predictability.

In an offlist discussion, Bill Herrin suggested that an ideal mobile
arrangement wouldn't close down application communication sessions
when it lost connectivity.

Currently, I think if the physical link goes down, the operating
system's concept of the IP address which was bound to that link is
instantly deleted, causing any applications which use it to
terminate their session with the correspondent host.  This makes
some sense when connectivity is via Ethernet cables and IP addresses
are assigned dynamically, or when a fixed IP address is used and
applications are regarded as best closed down if the cable is unplugged.

However, in a world where a map-encap scheme such as Ivip enables a
device to have its own IP addresses, or subnet of address space,
semi-permanently, then operating systems could be tweaked to regard
loss of all physical links to ETRs as a temporary inconvenience.
The IP address would still exist - its just that no packets would
arrive from the outside world for it, and probably any packets sent
out from it would be dropped.

(In this discussion TTR means Translating Tunnel Router - which
behaves as an ETR and has a two-way encrypted link from the mobile
node, also accepting outgoing packets from the mobile node and
forwarding them to the rest of the Internet.)

Then, from the application's point of view, there's no visible
difference between:

  100% packet loss in both directions, followed later by
  normal connectivity.

  Loss of all radio links (or the one used for the currently
  mapped ETR) for a few seconds or for hours or days.

  The currently used ETR/TTR becomes unusable - due to it being
  unreachable from the Net, or the radio link the mobile node
  used to make the 2-way tunnel to it goes down.  Either the
  ETR becomes usable again, the mobility monitoring system switches
  the mapping to another ETR/TTR which the mobile node has an
  operating tunnel to, or at some later time the mobile node
  fires up another radio link, finds another ETR/TTR and the
  mapping is changed to that one instead.

In all cases the mobile node's operating system is gaining and
relinquishing care-of addresses in the various networks it connects
to, and creating 2-way tunnels from these to ETRs/TTRs which are
ideally closest to each point where the mobile node connects to each
ISP network.  Meanwhile, the mobile node's tunnel software is
connecting these tunnels to the local IP address (or prefix) which
the operating system knows it has indefinitely.

Maybe, one day, an Ivip-like system could achieve a latency as low
as a second or two between the user command and all the ITRs in the
world changing their tunnelling.  5 seconds seems a more realistic
initial goal.

(Using LISP's approach of the ITRs testing reachability and
tunnelling to an alternative ETR wouldn't be any faster, unless
there was an oppressive number of probes, or acknowledgement packets
by which the ITR could detect loss of connectivity moment-to-moment.)


[Plan A - not as good as Plan B]

An application which really wants to achieve continued real-time
connectivity in a setting such as this, with Ivip, would need two or
more micronets each mapped to a separate ETR/TTR, with the mobile
node having a tunnel to each of these via a different radio link,
and therefore a different network and care-of address.

Then, the application software at the correspondent host could do a
brute force communication style of sending packets to the two or
more IP addresses of the mobile node in the two or more micronets,
such that full communication would continue as long as just one of
them was working at any one time.

Thinking about this . . .   it doesn't have to be the application at
the other end which does this.

[Plan B]

There could be a single TTR which the end-user's single micronet is
mapped to.  The micronet could be as small as a single IPv4 address.

The TTR would typically be outside each radio network, and hopefully
geographically close to all the radio networks the mobile node has
connections with.  The mobile node has multiple care-of addresses
and 2-way tunnels from each of these to the one TTR.  The TTR
decapsulates packets and sends the same packet out on every one of
these tunnels to the mobile node, so the tunnelling software (which
can have its own private protocols etc. not necessarily part of
Ivip, as it chooses the TTRs to tunnel to, probably with outside
help) can recognise the arrival of duplicates and feed only one to
the stable, IP address where it goes to the application.

Similarly, every time an application in the mobile node emits a
packet, the tunnelling software sends it out on the two or more
tunnels, and the TTR is smart enough to use the first copy which
arrives and ignore the rest - forwarding that packet to its
destination in the Internet.

This form of multi-radio-link parallel redundancy would be extremely
robust to drop-outs and lost radio sessions - and would be
completely transparent to the TCP/IP stack and applications in both
the mobile node and the correspondent node.  So the only host
changes are some pretty fancy add-in software in the mobile node to
make these care-of addresses and do the tunnelling - and perhaps the
OS being configured not to terminate the node's IP address even if
all the tunnels go down.

[Plan C]

Another option would be the mobile node establishing two or more
tunnels to separate TTRs, and the mapping of the micronet being set
to tunnel packets to one of these TTRs.  To ensure robust
communications, this "master TTR" sets up 2-way encrypted tunnels
with the other one or more TTRs, sending every packet received from
an ITR directly to the mobile node, and indirectly via the one or
more other TTRs.  Likewise, the mobile node sends each outgoing
packet on every 2-way tunnel it has to a TTR, and the slaves send
these packets to the master.  Brute force parallel redundancy could
 then be achieved with TTRs which are all close to, or within, the
various ISP networks of the various physical links - WiFi, 3G,
Ethernet cable etc.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg