Re: delayed multihoming/mobility set-up

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 14-nov-03, at 0:10, Pekka Savola wrote:

>   Is it necessary to ensure connection survivability prior to the 
> connection
>   establishment?

>   Or, is it necessary to ensure connection survivability in parallel 
> with
>   the connection establishment?

>   Or even, is it OK to just ensure connection survivability only for
>   "long-lived" sessions (e.g., those which have lasted for longer than 
> 5
>   minutes), using some definition.

Ideally, it should be possible to take an identifier, connect to it and 
the connection establishes as long as there is a single working 
source/destination locator pair. However, if we want to build this, we 
need an identfier->locator (and probably also locator->identifier) 
mapping infrastructure. At present, nobody seems too thrilled about 
either using the DNS for this or building something from scratch. This 
approach also has the downside that it's all or nothing: both sides 
must implement it and the mapping infrastructure must be in place 
before it can work.

The alternative is making improvements to what we have now. One thing 
that needs to be solved regardless of what else happens is the whole 
source address/exit ISP selection and ingress filtering problem. 
Another problem that we can solve on just one end (which makes it 
infinitely easier to do) is establishing a connection in the presence 
of unreachable destination addresses. This is hardly rocket science, as 
very old versions of telnet and FTP already cycle through all IP 
addresses associated with a FQDN until they find a live one. Many IPv6 
applications do this quite well today (ie, not requiring a very long 
TCP connect timeout before trying another address). And on systems that 
provide a connectbyname() function call this entire problem can be 
solved in the OS rather than in individual applications.

The only thing that we can't possibly solve without involving both ends 
is connection survivability. Now obviously we can go back to our ideal 
solution as listed above, or we can add some stuff to existing 
protocols that makes it possible to repair reachability problems in a 
backward compatible manner. The huge advantage here is that there is no 
need to determine the type of connection that can be set up beforehand: 
just connect and see what happens.

The next step is setting up the multihoming mechanisms. Rather than 
exchanging addresses in-band, I think we should limit ourselves to just 
announcing an authentication token. This can easily be done with 
minimal overhead in a destination option in one of the first packets. 
Then the session (including non-TCP "sessions") can proceed as they 
would normally in the absense of multihoming mechanisms.

Only when the connection gets stuck because of a a reachability problem 
(and the session would normally time out), the multihoming stuff kicks 
in. If the session was set up using the DNS, the initiator or client 
knows the locator addresses for the other side so it is able to find a 
working source/destination locator set. If additional locators aren't 
available, then it is still possible to repair most failures by 
sticking to the destination locator but jumping to a new source 
locator. Obviously, there would have to be some serious negotiating as 
the other side doesn't know the packets with the new source addresses 
belong to the existing session. This is where the authentication token 
comes in, in order to prove that the "new" correspondent is the same as 
the previously known one.

To answer your initial question whether it is necessary to protect not 
yet established sessions using multihoming mechanisms: in the above 
universe this wouldn't be required as the application or OS on the 
initiating side knows how to connect to a correspondent with 
unreachable locators without employing end-to-end multihoming 
mechanisms. But it's probably useful to provide this functionality 
anyway if possible to accommodate applications that don't do this 
themselves or use system calls that allow the OS to do it.

One additional caveat if we go this route: since the additional 
locators aren't available until there is a reachability problem, smart 
upper layer protocols don't get to do their thing. I think this can be 
solved by adding additional mechanisms that ty in to the core session 
survivability mechanisms by allowing the ULP to request adding new 
locators to the mix. The multihoming layer then negotiates with the 
other side and then reports back to the ULP whether it can use the 
requested locators. After that, the ULP can bypass the rewriting that 
would normally be done by the mh layer and use its own magic. Note that 
the way this is done today in SCTP where the ULP negotiates the 
additional addresses itself is probably insecure.