Re: Requirements [was Re: Transport level multihoming]

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

On Tue, 3 Apr 2001, xxvaf (Vince) wrote:

> IMHO, the number of such "legacy ipv6 stacks" is insignificant compared to
> the opportunity to do multihoming right. Especially if, as some now believe,
> getting this right means the difference between allowing the routing system
> to scale or watching it stop working during the next year or two. One would
> also imagine that the users of the legacy systems are also (very) early
> adopters who must know that early implementations are subject to change.

Right, these shouldn't be a factor. Compatibility with the application
interface is more important then with the actual hosts.
 
> As I believe Noel once said, there is at most one chance to make substantial
> change to the Internet network and transport protocols. One would hope that
> the changes to be made will provide more benefit than just expanding the
> locator field from 32 to 128 bits.
>
> My brief persual of SCTP suggests that it could have some promise. Two
> questions for someone with more knowledge of its details:

SCTP offers a lot more then just multihoming. I think it has a lot of
promise.
 
>     - Has any work been done to port existing protocols and applications
>       (HTTP, SMTP, FTP, TELNET, SSH, etc.) to SCTP? If not, how difficult
>       would it be to provide a TCP-compatible API? What, if any, approach
>       might be taken for UDP-based applications, such as DNS?

Yes, but I don't have any specific references. For some strange reaso,
many of the SCTP sites are down right now. Perhaps the consequence of not
being multihomed on today's Internet. :)

If the API is implimented right the change could be made transparent to
legacy applications, providing them with at least multihoming. The hardest
aspect is deciding when to use the enhanced transport and when you have to
fall back. I will have to address this.  

>     - My reading of SCTP suggests that it only supports multiple address
>       negotiation at session establishment. This would seem to make it
>       difficult for it to deal with address renumbering events, which is
>       kind of unfortunate. Has any thought been given to this?

Yes. Again, I can't provide a reference due to inaccessable sites, but
SCTP is extensible and I am fairly certian there is already a proposed
extension for dynamic address changing. This would not only facilitate
renumbering but also be useful for mobility.

SCTP: Be renumbered without dropping you slogin. There truely is a
potential for many more benifits then multihoming.

> Geoff's presentation indicates that multi-homing and consequent traffic
> engineering tricks (i.e. selective leaking of more-specifics) represents the
> biggest growth problem facing the routing system today. If multhoming at 
> the transport layer can be made to work well, it would seem to hold some
> potential as a solution. Can transport-layer multihoming solve all of the
> requirements so far listed in the multi6 draft? I dunno - an analsys of
> that might be interesting...

First we need a draft detailing a potential implimentation of transport
level multi-homing which addresses the specific issues expressed in this
forum and deployment incentives.