Re: Transport multihoming

[Greg Maxwell <gmaxwell@martin.fl.us>]

On Thu, 24 Oct 2002, Iljitsch van Beijnum wrote:

> Greg, Peter,
>
> As I see it, the reason to have the multihoming functionality inside one
> or more transport protocols is that the transport layer has end-to-end
> knowledge that makes it possible to make better multihoming decisions.
>
> Would it be possible to have a modified TCP talk to a non-modified TCP
> through some kind of "mudem" (multihomer/demultihomer), without loss of
> the core multihoming functionality, and without the "mudem" having to
> keep long-term state?
>
> This would create a much more attractive deployment path as people can
> choose to either upgrade hosts or put them behind a box to provide the
> multihoming functionality.
>
> It also makes it possible to move the multihoming decision making to a
> place where it can be better controlled if this is desired.

I could imagine a TCP extension that could interoperate with a translation
device that could handle adding the functionality of the extension to all
the non-supported hosts behind it.

			  /[network]\                    /[old host]
[enhanced host] - [router]           [router] - [magic] - [old host]
	      [magic]/    \[network]/
[old host] - /

The magic host would have to see all the traffic (no wraparound paths),
and I'd have to put a lot of thought into figuring out if it could be done
without tracking state in the magic host (initial though is, no, not
without an unreasonable amount of overhead).

This would represent a layering violation, but no worse then nat.

There are a few complications.. If one link was down, and the
locator service (DNS) was not TLM (transport layer multihoming) aware,
there would be complications in forming an initial connection.