Re: Transport level multihoming

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

On Tue, 3 Apr 2001, Joe Abley wrote:

> RJ,
> 
> On Tue, Apr 03, 2001 at 12:30:18PM -0400, Greg Maxwell wrote:
> > On Tue, 3 Apr 2001, RJ Atkinson wrote:
> > 
> > >         SCTP is interesting, but not sufficient.  The current
> > > multihoming practice works with existing TCP-based and UDP-based 
> > > applications, without changing them.  Changing the installed
> > > base of those applications to use SCTP instead isn't feasible
> > > in any sort of interesting timeframe -- if such migration is
> > > feasible at all.
> 
> The requirement that no changes should be required in applications
> in order to multi-home does not feature in our draft. Do you think
> it should be there?
> 
> If so, why?

My take is that multi-homing is a optional feature for Internet
connectivity, not a requirement.  Groups who find the feature important
will take the nessassary steps of getting it done.

Why should multihoming be a burden on the routing infrastructure, when 
most of whom's ultimate users are not directly multihomed, and when it
could insted be more efficently placed in the applications? Place the
burden where it scales best and with whom it benifits most.

Had SCTP been in Solaris 8, Windows 2000, and Linux 2.4 (it's already
available for Linux) and it was needed for multihoming, it would be on
EVERY SINGLE HOST on my network where I seriously care about multihoming
*already*, not years from now, it would be there today.

Had HTTP/1.1 been based on SCTP, every web-server and web-client which
cares about multihoming on my network would have it today.

The same can not be said for IPv6, because it has an administrative
overhead and most of that burden is on widgets that are currently changed
very infrequently and are sufficently specialized that many can not be
simply upgraded and must be replaced (routers). 

The world already suffers a short upgrade cycle for sofware. If SCTP is in
the box, it costs the user nothing to impliment. If users need
multihoming, they will almost all find upgrade their software to support
it a minimal cost (especially considering many already are running the 
software of the week for other reasons).

Since the primary concern here is IPv6 multihoming and considering all of 
the above, why should backwards application compatibility for multihoming
be a factor at all?