Re: Transport level multihoming

[Brian E Carpenter <brian@hursley.ibm.com>]

Daniel,

If I could avoid the conclusion that we are forced into transport level
gymnastics, I would be delighted. But remember that the scaling arguments
are several orders of magnitude worse than in the 802.5 case (potentially
many millions of entries in a flat routing table, as opposed to a few thousand
for LAN bridging tables.)

   Brian

Daniel Senie wrote:
> 
> 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