RE: delayed multihoming/mobility set-up

["Tony Li" <Tony.Li@procket.com>]

Catching up...

Christian,

I would agree with your timeline but would suggest one small tweak:

Once the "set of equivalent addresses" has been exchanged, then for
implementation reasons, it makes some sense to locate an alternate
set of working addresses BEFORE the transport event happens.  This
is necessary because this is an O(N^2) problem and you don't want
to have to solve it in real time.  Of course, some intelligence
in the host to choose "better" addresses could make for some
implementation differentiation too.

Tony



|  -----Original Message-----
|  From: Christian Huitema [mailto:huitema@windows.microsoft.com] 
|  Sent: Monday, December 01, 2003 9:19 AM
|  To: Masataka Ohta; dcrocker@brandenburg.com
|  Cc: Iljitsch van Beijnum; Multi6 Mailing List
|  Subject: RE: delayed multihoming/mobility set-up
|  
|  
|  > > 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
|  
|