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

Re: delayed multihoming/mobility set-up

On 1-dec-03, at 18:18, Christian Huitema wrote:

... 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.

I don't necessarily agree that routing protocols by their nature can't do better than the minute timescale, but today BGP lives around that timescale and depending on routing has other downsides, such as the fact that a routing protocol has little information about which path is really better and they don't allow the use of multiple paths in a useful way. So I agree that we need to handle this end-to-end.

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"

Hm, this is problematic. Simply exchanging addresses isn't good enough, as this allows for redirection attacks. So the addresses must be validated by using them in a way that can't be spoofed by a third party. I.e., one side must contact the other using a new address and include authentication information that tells the correspondent it's still talking to the same party. If we're doing this anyway there is little need to exchange the addresses beforehand. Depending on the type of rehoming authentication used it may be necessary to set up authentication state before rehoming happens.

3) On a transport event such as retransmission time-out, probe alternate
pairs of src/dest addresses, and pick a "better one" if available.

Agree.

Question: do we want to do this on a per transport session basis, or do we move an address and all transports running over it in one go when a rehoming event occurs?

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.

Even though it's probably not worth the trouble to protect the individual TCP sessions towards a web server (but protecting large downloads over HTTP would be very useful), it would still be good to have fairly seamless failover to another address when a web address fails. I'm sure Amazon or Ebay wouldn't want to run the risk of losing customers because of reachability issues by depending on web browsers to do the right thing. But this assumes the protection is active at the IP address level rather than the transport protocol level.