Re: Multihoming by IP Layer Address Rewriting (MILAR)

[Mattias Pettersson <mattias.pettersson@era.ericsson.se>]

Iljitsch van Beijnum wrote:
> 
> On Mon, 17 Sep 2001, Mattias Pettersson wrote:
> 
> > > - what happens when an address suddenly fails and is no longer reachable?
> 
> > > - what happens if TCP tries to set up a connection but the address it
> > >   chooses doesn't respond (and there is another address that works
> > >   available)?
> 
> > As long as there are multiple addresses available the sending node is
> > free to select any of them as destination address.
> 
> > I guess an ICMP error message or an upper layer lack of progress signal
> > would cause a bad address to either be removed or lowered in priority.
> > Similar ideas are used in Mobile IPv6 today. That would apply to both of
> > your questions.
> 
> Yes, but what does the user experience? I can do round robin DNS for two
> IP numbers for a website and since you can still connect 50% of the time
> when one address fails, this could be considered a solution. Users
> won't like it, though.
> 
> Having a connection setup attempt fail so it has to be retried at the
> application level is not good enough.

I agree that the user can't accept that. But what do other proposals do
(we are talking about connection setup)?

Send TCP SYN to multiple peer addresses? The peer would ignore multiple
attempts. I think that was mentioned before.

We need mechanisms that will provide the first address of the peer that
has a high probability of being reachable. I don't know if DNS can
reflect that fast enough. The draft mentions SIP, and such mechanisms
that are based on registering are good if the peer knows which of its
addresses are reachable and which are not.

The draft assumes that we can't read too much stability into the IP
addresses of a node. Addresses come and go. As long as you have a
session established between two nodes then they can inform each other of
address changes. On the other hand, when trying to establish a
connection to a node we need fast location management, and that may be
something new but not within the scope of this draft.

/Mattias