Re: [Tsvwg] SCTP Socket API - Objections to proposed extensions

"Brian F. G. Bidulock" <bidulock@openss7.org> Sat, 07 January 2006 05:47 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev6vU-00052U-8e; Sat, 07 Jan 2006 00:47:40 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ev6vR-00052P-F8 for tsvwg@megatron.ietf.org; Sat, 07 Jan 2006 00:47:37 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16757 for <tsvwg@ietf.org>; Sat, 7 Jan 2006 00:46:21 -0500 (EST)
Received: from gw.openss7.com ([142.179.199.224] ident=[HE9s52uYH3njuVIXPh2xLYRXgqDkfN1X]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ev71T-0000Ep-2R for tsvwg@ietf.org; Sat, 07 Jan 2006 00:53:51 -0500
Received: from ns.pigworks.openss7.net (IDENT:SO5s+FKo23NhSFE96Lbv5xazPICH4Wkb@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id k075lRw19082; Fri, 6 Jan 2006 22:47:27 -0700
Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id k075lLJ30825; Fri, 6 Jan 2006 22:47:21 -0700
Date: Fri, 06 Jan 2006 22:47:21 -0700
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Mark Butler <butlerm@middle.net>
Subject: Re: [Tsvwg] SCTP Socket API - Objections to proposed extensions
Message-ID: <20060106224721.A30197@openss7.org>
Mail-Followup-To: Mark Butler <butlerm@middle.net>, TSWG <tsvwg@ietf.org>, Kacheong Poon <kacheong.poon@sun.com>
References: <43AA9BE2.7070901@stewart.chicago.il.us> <43BA5F40.1070705@sun.com> <43BAE9C1.7000209@middle.net> <43BD475A.90304@sun.com> <43BD9A98.5010200@middle.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <43BD9A98.5010200@middle.net>; from butlerm@middle.net on Thu, Jan 05, 2006 at 03:15:52PM -0700
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8
Cc: Kacheong Poon <kacheong.poon@sun.com>, TSWG <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bidulock@openss7.org
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Sender: tsvwg-bounces@ietf.org
Errors-To: tsvwg-bounces@ietf.org

Mark,

Mark Butler wrote:                               (Thu, 05 Jan 2006 15:15:52)
> Kacheong Poon wrote:
> >There are other minor points in saying that the current
> >API is not usable by many apps.  For example, sendfile()
> >cannot be used efficiently.  But it seems to me that it is
> >because of app architecture design, not because of the
> >API itself.  Otherwise, I can't see how there can be many
> >SCTP apps running in production environment using the draft
> >API at this very moment.
> >  
> >
> Are there any non-telephony SCTP applications in wide distribution? I 
> don't think so.

Yes there are non-telephony SCTP applications in wide distribution.

A couple of examples: SCTP has been used by the SCIOP for RT-CORBA.  TAO
has supported it for some time.  It is interesting that CORBA was first
specified by the OMG using UDP, then TCP, and finally SCTP.  NFS also
went from UDP to TCP and will likely land on SCTP.

Another is iSCSI and, of course, DDP.

SCTP is also a natural replacement for Ethernet bonding on cPCI
backplanes.  That is, instead of Ethernet bonding two rails together,
SCTP is used to achieve redundancy across both rails while permitting
twice the failure scenario throughput.  CGL specified this and I think
the SAF too.

Of course BICC, SIP, TI-SCCP, MEGACO/H.248, H.225/H.323, and SIGTRAN UAs
are existing implementations of SCTP, however, any application that does
not wish to experience degraded performance in a noisy environment and
is currently using TCP (such as the RT CORBA was and NFS is) will
benefit and eventually move to SCTP.

Then there is Randall's SCTP web server...

> SCTP is a natural replacement for UDP, but there is no SOCK_DGRAM.

Well, no, it is not a natural replacement for UDP.  UDP is a
connectionless datagram protocol.  SCTP is a connection oriented
protocol.

> It is a natural replacement for TCP, but there are no partial writes
> or early delivery.

Well, no, not a natural replacement.  SCTP preserves (well, is capable
of preserving) record boundaries and TCP cannot.  Partial writes to SCTP
are simple when emulating TCP: the implementation can simply close the
SSN at the end of the partial write (because record boundaries are to be
ignored).  Multiple stream interleaving is not an issue, because when
emulating TCP, the implementation uses only one one stream (that is all
that TCP has).  That is, under a SOCK_STREAM type of socket, it is
possible for an SCTP implementation to exactly mimic the TCP Sockets API
(right down to TCP_MAXSEG, TCP_NODELAY, TCP_KEEPALIVE, being, of course,
the only required standard TCP options).

> It can't be used to multi-stream large messages because there is no
> interleaving.

Well, neither can TCP.

> These are primarily API, not protocol limitations.

SCTP's inability to multi-stream large messages is not a limitation of
the API, it is a limitation of the protocol.

I think you are finally back to where I was with SCCP and the SIGTRAN
SUA.  We had the choice of either letting SCTP do all segmentation and
reassembly of messages for SUA, or putting SCCP's segmentation and
reassembly into SUA on top of SCTP.  That latter was necessary because
of SCTP's inability to interleave large messages.  Therefore, the
application (SUA) fragments and reassembles messages across the SCTP
association.

It is something that SCTP forces on the API and application, but let's
be clear: it is a protocol limitation.

If SCTP had included a segment number in the DATA chunk header, instead
of just a beginning and ending flag, there would be not problem
interleaving any messages.

Strangely, it looks like we are doomed to this limitation because the
editors of the protocol will not change it.

> 
> Even where traditional semantics are not strictly necessary, most 
> applications have to work in environments where SCTP support is not 
> available or where SCTP is blocked or hindered by firewalls.  An 
> application that supports SCTP must generally also support either TCP or 
> UDP.  If it is difficult to use the same code base for both protocols, 
> an application developer is likely to dispense with SCTP support completely.

Well, no, that is really not the case either.  When some application or
protocol is adapted to SCTP, is it because SCTP provides some capability
that is lacking in TCP (such as multi-homing, multi-streaming, unordered
and ordered delivery, quick association setup and tear-down, better
attack resilience).  Of all these, taking advantage of multi-streaming,
in particular, requires changes in the application and the API.  An
application cannot take advantage of multi-streaming without specifying
on send what stream to which to place a message.  Also on the receive
side, the application might need to know (or specify) what stream it
came from (or is to be read from).

> 
> The main issue is should SCTP be a general purpose transport protocol or 
> not?  I can understand the sentiment to stay focused on supporting small 
> messages well, and letting adaptation layers handle larger ones.  I 
> would like to see those adaptation layers in-kernel, but that is beside 
> the point.

Well, it is a general purpose transport protocol.  One that has clear
and specific advantages over other available protocols, but also has its
own limitations, artificial or otherwise.

Get real: any application that is passing records across TCP is already
performing its own segmentation and reassembly, and, of course, even has
to detect its own record boundaries.  The same application running over
UDP cannot exceed a rather restrictive maximum message size.  Does this
mean that UDP and TCP are not general purpose transport protocols in
your view?

If the application uses UDP it is already restricting message size to a
maximum.  If the application uses TCP it already segments and
reassembles large records, and must detect record boundaries within the
data stream.  Doing either is certainly not a limitation for SCTP in
comparison to UDP or TCP.

OTOH, ISO protocols do not require application segmentation, reassembly
or record boundary detection and yet support partial writes and reads.
Therefore, SCTP is only limited when compared to ISO protocols, but then
so are TCP and UDP.

--brian

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg