[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Transport level multihoming



On Tue, Apr 03, 2001 at 01:03:48PM -0400, Greg Maxwell wrote:
> 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?

So, is that a "no"? It looks like a "no" but I thought I'd check :)


Joe