Re: Transport level multihoming

[Ramakrishna Gummadi <ramki@cs.berkeley.edu>]

> Doesn't similar constraints apply to any transport level solution ?
> I am not sure how a transport solution works when one of the
> upstream ISP's link fails. Isn't this one of the requirements ?

I don't think that an end-host level solution without address
translation can work effectively
in a decentralized multi-tier multihoming scenario because the end-hosts'
addresses have to be added/deleted/modified whenever a provider
adds/deletes/changes its providers. Address translation has to be used,
but this will be rendered less effective in the
transport level multihoming case because end-hosts will now have to be
aware of the final routable addresses so that they can advertise them in
the payload, assuming we don't want to change every app at the other
end-point to make it aware of multiple addresses.

A tunneling (or any network-layer)+translation based solution would not
have this problem.

Another problem with the transport-level multihoming is that
the number of failure modes that can be tolerated in a multi-tier
multihoming are decreased. For
example, consider the scenario where a site is dually-multihomed, while
each of the providers are triply multihomed to three different providers
each. The question is---how many addresses do the hosts in the site have?
If it is two, then it means that the site can not tolerate failures in four of
the providers twice removed from it. If it is six, then it means we are
exposing the site to addressing issues not related to it.

A tunneling+translation solution solves this problem cleanly by using only
two (or
as many addresses as there are providers) provider-independent addresses
to the site. The site's immediate providers would independently translate
the addresses to meet their own load-balancing needs without leaking the
site's prefixes. When a failure between the provider and its higher-up
is detected, by creating two tunnels between itself and the higher up via
the two working ISPs, a provider can ensure connection survivability and
can even load-balance failed traffic among the working providers. The
tunnels are only one "level" deep, and are transparent to all others,
including the original site.


thanks,
ramki





>
> thanks
> -mohan
>
> > Date: Tue, 07 Aug 2001 17:01:51 -0500
> > From: Brian E Carpenter <brian@hursley.ibm.com>
> > X-Accept-Language: en,fr
> > MIME-Version: 1.0
> > To: Greg Maxwell <gmaxwell@martin.fl.us>
> > CC: Ben Black <ben@layer8.net>, Randy Bush <randy@psg.com>, Peter Tattam
> <peter@jazz-1.trumpet.com.au>, multi6@ops.ietf.org
> > Subject: Re: Transport level multihoming
> > Content-Transfer-Encoding: 7bit
> >
> > 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.
> >
> >    Brian
> >
>
>
>