Subject: [Tsvwg] Re: [SCTP] Uses of zero length DATA

From: Mark Butler <[email-masked]>
Date: Sat, 22 Jul 2006 03:14:58 -0600

ash kat wrote:

>
> I do not see any use of sending DATA chunk without any user data. that 
> is why i am in favour of sending this Error ["no user data"] and 
> restricting the sending of DATA chunk without any user data.
>  
> If you can suggest some benefits/uses of the DATA chunk with "no user 
> data" then please specify.
>
I am not Brian, but here are my comments anyway:

There are dozens of applications where the ability to send zero length 
records in an ordered sequence of other records is very useful.  A 
typical application is pipelined RPC with ordered asynchronous reads to 
response buffers, such as what ES-API anticipates.

First you allocate response buffers, one or more per RPC request.  Then 
you submit asynchronous read requests to the kernel or whatever, 
indicating with a flag that they need to be mapped to incoming records 
in sender (TSN) order.

You then send a series of RPC requests on an outbound stream, in series, 
without waiting for a response between messages, in pipelined fashion, 
typically one SCTP record ("message") per request.  The thread that 
processes those requests then returns a series of one or more records 
for each request.  At a minimum you have a status code response, and 
then usually a series of one or more returned values - some of them 
potentially very big (megabytes for some applications).

Now in order to pipeline requests, the order must be (logically) 
preserved, so you must return a result for all the buffers the 
requesting application has registered.  It happens to be very convenient 
to return empty strings as empty strings.  It also happens to be very 
convenient not to overwrite existing data when there is an error.  If 
one is forced to use non zero length messages, this doesn't work, and 
now your supercomputing application has to go parsing delimiters and 
other pointless errata, greatly reducing the cross sectional bandwidth 
of your cluster, and complicating the programming needed to develop MPI 
type applications, etc.

In short, arbitrarily handicapping a network protocol for no good reason 
is a bad thing to do.  There are several ways to deal with zero length 
messages using the existing socket API.  Checking MSG_EOR on a zero 
length read is probably the easiest.

 - Mark B.