Subject: RE: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 )

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 6 Apr 2006 09:02:26 -0700

Thomas Narten wrote:
> Tim Shepard <[email-masked]> writes:
> 
>>>> is supposed to be accomplished?  Are we going to be running
>>>> dual-stack for a number of years or decades while the transition
>>>> is underway? 
>>> 
>>> I guess I don't quite follow this.  You make it sound as if there is
>>> some grand plan or some great need to move all apps from TCP to
>>> SCTP. 
> 
>> I don't mean to say that there is.   I'm asking if there is.  (AFAIK,
>> there is not.)
> 
> IMO, there is no good reason to have such a transition. Let's
> be honest here. SCTP has some interesting (and useful
> features), but they are largely of interest only to
> specialized applications (that is, they are irrelevant to 95%
> of the applications that run on top of TCP today). Why on
> earth would they want to run on top of SCTP, much less "migrate" to
> SCTP? 
> 
> In the case of SCTP's "multihoming facilities", for example,
> they are AFAIK, primitive, and we have little real experience
> with them. Indeed, I viewed them (when I reviewed the
> original specs) as largely hooks for potential future work,
> but that the details needed to be sorted out.
> 
> I'll probably get flamed for saying that. So, let me ask
> those that disagree to provide pointers to documents and
> research showing experience with those multihoming
> capabilities and what we have learned from them.
> 

SCTP provides multi-homing, multi-streaming and message
boundaries. All of which are very relevant to many applications.
RDMA and iSCSI are both applications that should have been
developed over SCTP. It's defined for RDMA, but not deployed,
and not defined for iSCSI.

The reason is that customers are not confident that they
can deploy SCTP at the endpoints and have proper support
from all network elements, and network management. People
promoting new technologies only want to sell one new concept
at a time, therefore they stick to TCP.

The point is that any new solution that doesn't address the
problem of compatability with a network that doesn't instantly
update itself to be RFC-compliant doesn't do any good. If all
networks adapted themselves instantly to RFCs then we would
already be using SCTP to solve these problems.

So I don't see any point in considering TCP enhancements unless
they pass the test of being transparent to existing network
elements. If they aren't transparent they'll just add one more
spec to the list of things networks don't do despite there
being an RFC.

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mark Butler <[email-masked]>
Date: Fri, 14 Apr 2006 20:13:25 -0600

I don't think there should be a wholesale TCP->SCTP migration effort, 
but there isn't any reason why SCTP can't provide TCP style byte stream 
delivery service with additional benefits. (Or DCCP style connection 
oriented unreliable message delivery service for that matter).

 The primary obstacle to doing this is that socket APIs are being 
defined on a transport protocol specific basis. That is an unusually 
counterproductive practice.  Wouldn't it be much better to define a 
single socket API with proper service types that can be used on any 
supporting transport protocol?  That was the original intent was it not?

For example POSIX defines SOCK_STREAM as a byte oriented delivery 
service, but for various reasons SCTP adopted SOCK_STREAM to request a 
one-to-one message oriented delivery service, instead of something like 
SOCK_RDM.  And then we have SOCK_DCCP, a definition that pretty much 
disregards the whole idea of distinguishing the socket service type from 
the underlying transport protocol.

Historical issues aside, SCTP is easily tweakable to support all the 
common socket service types, including: connection oriented byte stream, 
connection oriented reliable/partially reliable/unreliable message 
delivery, connectionless reliable/partially reliable/unreliable message 
delivery, with two subvariants for each of the message oriented service 
types - atomic (SOCK_DGRAM style) read/write semantics, and partial 
message (SOCK_SEQPACKET style) read/write semantics.

The problem is that standardization in this area is non-existent, which 
means if you want to port a program from one transport protocol to 
another, much more care must be taken than simply changing IPPROTO_x to 
IPPROTO_y.

Besides the base socket service type issues, there are several socket 
options that should be shared between transport protocols that are not.  
SCTP_NODELAY and TCP_NODELAY have essentially identical semantics for 
example.  DCCP has a new option for service code that might be useful 
for future extensions to TCP and SCTP, but it is defined as a DCCP 
specific socket option.  SCTP has a pretty generic multihoming 
interface, but it is defined as a set of sctp_xxx library calls.

It there were a transport protocol independent socket API standard, the 
uptake and testing of new transport protocols would be much improved.  
Instead of adding an unmaintainable flurry of #ifdefs, common 
applications could switch transport protocols as easily as they now 
switch port numbers.

Any comments on this idea?

 - Mark B.