RE: delayed multihoming/mobility set-up

["Christian Huitema" <huitema@windows.microsoft.com>]

> > IvB>  The reason that BGP
> > IvB> rerouting can take so long is that the RFC mandates a 90 second
> hold
> > IvB> time,
> 
> And a 90 second hold time is already too long.

... which is why I am convinced that the solution to preserving existing
communication is closest to "transport protocols" than "routing
protocols". The time scale of transport protocols is the RTT; the time
scale of routing protocols is the minute. If we wait for a routing event
to be somehow signaled to the transport stack, the connection will be
gone. The natural solution is to use a transport event, e.g. a
retransmission timer. This event can trigger an end-to-end "connection
rehoming" exchange.

My preferred time-line would be:

1) Start a communication using one of the available pairs of src/dest
addresses.
2) If the communication is determined to be worth it (i.e. last long
enough), engage in "multi-homing signaling" to obtain a "set of
equivalent addresses"
3) On a transport event such as retransmission time-out, probe alternate
pairs of src/dest addresses, and pick a "better one" if available.

I would note that a lot of the communication we have today do not meet
the "worth it" requirement. The top applications in the Internet today
are web pages, which mostly consist of a large number of very short
exchanges, and p2p file sharing, which includes its own application
level tools to deal with multi-homing. 

-- Christian Huitema