RE: RE: SCTP for multihoming

[<john.loughney@nokia.com>]

Hi Lode, 

> >First a more general issue that comes up in the SCTP-related drafts: 
> >there is no way for two hosts to find out whether the paths that exist 
> >between them share any infrastructure. Would it be useful to see if we 
> >can come up with something that allows hosts to find out? I'm thinking 
> >something in the way of the record route option.
> 
> Maybe the tools for that already exist. 

SNIP...

What I get the feeling is that Lijitsch is saying that if SCTP is used
for Multi6, such a feature may be needed.

Lode said:

> Use a TRACEROUTE on every IP address of the remote peer and try to detect
> common IP addresses along the routes.
> A IP address that show up in 2 or more traceroutes: 2 or more paths going
> through that router(not taking into account the endpoints/host naturally)
> This might look as a general tool for detecting shared infrastructure...
> If traceroute does not fit the bill , then something along the record route
> option might be usefull... Bear in mind.. This will be a optional tool.. 
> Not everybody is that interested in the routes through the network..

Of course, an optional extension to SCTP to provide this feature could
be made ...
 
> >I'm worried about the much more complex packet format (compared to TCP) 
> >that SCTP has, such as different chunks that can be in a single packet. 
> >Are there any figures available about SCTP implementation complexity 
> >and performance?

We have an implementation of SCTP that outperforms vanilla TCP (from an
old BSD varient) in terms of throughput in most simple scenarios.  However,
newer versions of TCP generally outperform SCTP.  Several papers have noted
that as packet sizes approach MTU, SCTP and TCP perform on about the same
order of magnatude.  Code size for SCTP & TCP are on the same order
of magnatitude as well.

> >I've been opposed to a strict transport layer solution because then all 
> >transport protocols need to be changed. Still, SCTP is here today so 
> >why not use it for multihoming in the situations where it suits the job 
> >at hand. Another problem with SCTP is that moving applications from TCP 
> >to SCTP means both protocols will have to run side by side for a long 
> >time. Would it make sense to modify SCTP such that it is possible for 
> >applications that expect to run TCP to be multihomed without changes, 
> >and also to be backward compatible? The latter could be done by 
> >exchanging some "I can do SCTP" options in TCP and then (try to) set up 
> >an SCTP session if the other also supports it, or even better, switch 
> >to SCTP in mid-flight.

I agree with Lode that migration / interworking scenarios should be 
developed more.  Some of this is implementation / deployment related, but
you are right that some discussion of this would be a good thing.

John