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
- [Tsvwg] SCTP Socket API Randall Stewart
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Kacheong Poon
- [Tsvwg] Re: SCTP Socket API Sridhar Samudrala
- Re: [Tsvwg] Re: SCTP Socket API Sridhar Samudrala
- Re: [Tsvwg] Re: SCTP Socket API Randall Stewart
- Re: [Tsvwg] Re: SCTP Socket Semantics Mark Butler
- Re: [Tsvwg] Re: SCTP Socket Semantics Randall Stewart
- Re: [Tsvwg] Re: SCTP Socket API Michael Tuexen
- Re: [Tsvwg] Re: SCTP Socket API Caitlin Bestler
- Re: [Tsvwg] Re: SCTP socket semantics (buffer siz… Mark Butler
- Re: [Tsvwg] SCTP Socket API Kacheong Poon
- Re: [Tsvwg] SCTP Socket API Randall Stewart
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Mark Butler
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Randall Stewart
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Mark Butler
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Randall Stewart
- [Tsvwg] PR-SCTP truncation Mark Butler
- Re: [Tsvwg] PR-SCTP truncation Randall Stewart
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Mark Butler
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Kacheong Poon
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Brian F. G. Bidulock
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Brian F. G. Bidulock
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Michael Tuexen
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Mark Butler
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Mark Butler
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Brian F. G. Bidulock
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Mark Butler
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Brian F. G. Bidulock
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Randall Stewart
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Randall Stewart
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Mark Butler
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Mark Butler
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Brian F. G. Bidulock
- Re: [Tsvwg] SCTP protocol extensions Mark Butler
- Re: [Tsvwg] SCTP protocol extensions Brian F. G. Bidulock
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Randall Stewart
- Re: [Tsvwg] SCTP PPID field Mark Butler
- Re: [Tsvwg] SCTP PPID field Michael Tuexen
- Re: [Tsvwg] SCTP PPID field Randall Stewart
- Re: [Tsvwg] SCTP PPID field Mark Butler
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Mark Butler
- Re: [Tsvwg] SCTP Socket API - Objections to propo… Randall Stewart