[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: delayed multihoming/mobility set-up



>> And a 90 second hold time is already too long.

CH> ... which is why I am convinced that the solution to preserving existing
CH> communication is closest to "transport protocols" than "routing
CH> protocols".

Many scenarios do not require the fast switchover that is being
discussed here.  For them, the IP-Endpoint (shim) module works fine,
for mobility an for multihoming that is used for fall-back
reliability.

For highly responsive fail-over, multiple locator-pairs must already
be fully functioning before they are needed.  Otherwise, the concern
about being overly responsive sets in, with the usual, attendant
problem of thrashing the choice of path.  For this scenario, I too
believe that transport is the place to put the mechanism, because
transport is where the congestion response information is assessed.

However the Endpoint module still has quite a bit of utility.  First,
it is useful for unmodifie transport modules, such as classic TCP.
Second, it can support the common Address Locator Pool.  That's the
idea behind SLAP.


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

CH> I would note that a lot of the communication we have today do not meet
CH> the "worth it" requirement.

Yes.  This was an interesting point that came out of the discussion
the Pekka S.  and I had, that he reported.

What I had not appreciated was that the asyncrhonous control exchange
that MAST does permits exactly this sort of long deferral of the
control exchange, meaning that it often will not be done at all.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>