Subject: SCTP for multihoming

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 23 Feb 2004 22:00:19 +0100

Lode and others,

I've been reading the SCTP for multihoming draft. Here's my feedback.

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.

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?

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.

And I still think the heartbeats are both evil and most of the time 
unnecessary.

BTW, it would be awesome to have HTTP over SCTP where each of the 
elements that make up a web page is loaded over a different stream so 
there is no head of line blocking but the session establishment 
overhead (both in unnecessary repeating data and in round trip times) 
that exists today is mitigated.

Now that we're firmly in science fiction territory (Tony Hain once 
suggest we form an "Internet Fantasy Task Force", maybe not such a bad 
idea...) it occurs to me that SCTP could be wrapped around UDP for 
long-lived UDP associations and subsequently add multihoming to UDP and 
UDP-based transport protocols such as RTP. At least, if the stream 
setup mechanism can be changed to support "one packet streams" 
efficiently. What do you think?

---

From: <[email-masked]>
Date: Tue, 24 Feb 2004 15:02:41 +0200

Hi Lode, 

> 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 ...
 
> >Are there any figures available about SCTP implementation complexity 

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.

> >an SCTP session if the other also supports it, or even better, switch 

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