Re: Transport level multihoming

[Daniel Senie <dts@senie.com>]

At 06:01 PM 8/7/01, Brian E Carpenter wrote:
>Greg Maxwell wrote:
> >
> > On Tue, 7 Aug 2001, Brian E Carpenter wrote:
> >
> > [snip]
> > > On the other hand we know that major restructuring of applications 
> isn't going
> > > to happen - that's the real world. So if we have to do work in the 
> transport
> > > layer, the transport layer is going to have to hide most of it below some
> > > sort of socket API. I can't see any reason in principle why that API
> > > would have to expose a bunch of addresses, even if it turns out that
> > > multi6 requires more than one. A "primary" address per host would be 
> enough
> > > to expose to the middleware.
> >
> > If the primary address is functional at connection setup time, then, yes
> > it could learn the other transports from the remote end. However, what do
> > you do if the primary is down? The only solutions I can think of either
> > require the applications to rotate the address passed to the API, or
> > require the transport to consult DNS (what an ugly kludge and layering
> > violation THAT would be!).
>
>There is *always* an abstraction layer above which a single handle identifies
>the other party in a session (and probably no handle at all identifies
>"this" end of the session). So whatever layer is the highest layer to
>be aware of N addresses, there is always a layer above that (conceptually
>at least) that has a single handle for that set of N addresses.
>
>All I am saying is that this abstraction layer may just as well be a socket
>API, and that single handle may just as well be one of the N addresses - and
>if you do it that way, you minimise the impact on existing apps layer logic.
>
>It's probably sloppy to write as I did of a "primary" address being the
>handle; it's just an arbitrary choice among the N addresses available.
>It's the one that gethostbyname (equivalent) chooses to return to you;
>it might conceal a bunch of others from you below the socket API,
>and use them as needed for multihoming or whatever other cookery it
>needs to do.

What you suggest could work, though the management of that new abstraction 
layer brings with it some level of trouble. Assuming some clean, fast and 
reliable mechanism is in place for that, and all applications use the API 
that automagically uses this capability, the application writers will be 
blissfully unaware. Diagnostic utilities could bypass that facility and 
learn what's actually going on. Interesting complications await for 
firewall vendors, as a single application may wind up with connections 
going out multiple links from a site if that's what the underlying 
multihoming stuff decides to do, but that's probably OK. Failover could be 
a bit messier, but I think the app writers are getting used to having to do 
reconnects on occasion.

Somehow, though all of this I get the same icky feeling I got with the 
design of IBM's source routing for 802.5 Token Ring. Seems like the answer 
then was the end stations had more processing power, so pushing all the 
info out to them was the way to go. Bridges were going to be hopelessly 
overworked, and so could handle nothing more than reading a few bits on the 
way by (man, this is starting to sound like MPLS). Well, along came 
intelligent Ethernet bridges which learned, and Token Ring Source Routing 
looked pretty bad. It was difficult for people to support and debug, made a 
total mess of the code in the end stations, and really didn't scale well.

I get nervous when folks call for Transport-level multihoming, it comes 
across as either:

"The routers in the core will never be able to handle the problem." (Refer 
to arguments for MPLS to save the core from overload, since they won't be 
able to forward at gigabit speeds, and look at present day hardware. Every 
time we claim hardware won't ever scale to do a thing, we appear to get it 
wrong).

or

"We can't come up with a good way to work out this problem, so let's push 
it up a level and it'll be someone else's problem".

I'm not ready to rule out transport-level as a bad idea, nor rule it in as 
a good idea, but it does give me a bad feeling of deja-vu.
-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com