Re: delayed multihoming/mobility set-up

[Brian E Carpenter <brc@zurich.ibm.com>]

One of our current objectives is to start architectural breakdown
and analysis. It seems to me there is an architectural boundary
right in this thread - something to do with separating the detection
of an address dropout (the address in use is suddenly no good)
from fixing it (fast recovery a la SCTP if we care, or waiting for
network layer and routing to select a new address if we are not
in a hurry).

   Brian

Spencer Dawkins wrote:
> 
> Just a couple of notes here...
> 
> Spencer
> 
> ----- Original Message -----
> From: "Iljitsch van Beijnum" <iljitsch@muada.com>
> To: "Christian Huitema" <huitema@windows.microsoft.com>
> Cc: "Multi6 Mailing List" <multi6@ops.ietf.org>
> Sent: Tuesday, December 02, 2003 4:13 AM
> Subject: Re: delayed multihoming/mobility set-up
> 
> > On 1-dec-03, at 18:18, Christian Huitema wrote:
> >
> > > 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
> 
> Well, the GPRS RTT on networks I've measured *is* around one second,
> so if we didn't have to wait until our WLAN address lost its
> connectivity to exchange addresses, that could be lovely...
> 
> > 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?
> 
> Well, someone got up in Minneapolis and said, "don't bother rehoming
> my e-mail connection, because I would rather keep retrieving e-mail
> over my WWAN connection than interrupt retrievals every time I lost my
> WLAN connection". If these seems desireable, it's probably
> per-transport-session; if not, it's probably per-address, unless we
> want to go down the ToS/CoS path.
> 
> >
> > > 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.
> 
> Christian's opinion is true for per-object HTTP connections, a little
> less true for persistent HTTP connections, little less true for
> persistent HTTP connections to a proxy, and a little less true for
> persistent HTTP connections when the browser is using pipelining. It's
> a pity that we can't include some notion of "this is a large object"
> in HTML, of course.
> 
> Spencer

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK