Re: Transport multihoming

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

On Fri, 25 Oct 2002, Greg Maxwell wrote:

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

Restoring the destination address should be simple, if we require that a
secondary destination address is recognizable as such: this would be a
simple prefix replacement. However, it becomes more complicated when the
source address changes. A translation box can't be configured with this
information. So either we require the source to always include the
original source address (so now we're tunnelling) or the magic box has
to keep source remapping state. However, it should be possible to
rebuild this state if the source includes the primary source address
whenever it feels this is appropriate, for instance, in retransmissions,
or when the magic box asks for this information because it isn't in the
cache.

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

I'm not sure it would... If we define this functionality to be in IP and
provide suitable new interfaces for TCP and other transport protocols to
interact with it, we should be fine. If those darn implementers then
decide it's easier to implement the whole thing in one go in TCP, well,
that's not our fault. I think being able to take advantage of the
end-to-end information that TCP has is worth a few minor infractions.

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

True. The simple solution would be to require the application to try
alternate addresses. (Note that a host would then have four addresses:

1. primary address in prefix A, listed in DNS
2. secondary address in prefix B, dynamically discovered
3. primary address in prefix B, listed in DNS
4. secondary address in prefix A, dynamically discovered

With just two addresses it would be impossible to easily determine when
addresses should be translated. The client must be smart enough to try
all addresses listed in the DNS, the magic box can't do this on behalf
of the client unless the translation state is already cached.

The other solution is that discovery of the alternate addresses happens
out of band. This is what Michel's MHAP does. This has the advantage the
primary address doesn't have to be reachable which in turn makes these
addresses portable. Unfortunately, this out of band discovery is a tough
nut to crack.