Subject: Re: sctp_peeloff()

From: Gabriel Kaelin <[email-masked]>
Date: Wed, 17 Dec 2003 19:17:39 -0500

Michael Tuexen wrote:
> let us see if people want this feature in the API.

I'm not an implementer of SCTP, but I'm currently studying the applicability of 
SCTP to the Coda file system. To be able to peel off streams sounds interesting 
from a performance point of view, because Coda clients and servers run in user 
space:

There is a lot of meta data being transported, but also files. Files don't need 
the application level attention during transfer, therefore it would be nice if 
everything could happen in kernel space, e.g. by using sendfile(). However, this 
requires a dedicated socket, so to peel one stream temporarily off would really 
be nice.

In this case I can't see a risk of getting stuck in rwnd issues. Well, this is a 
selfish point of view, but maybe you agree, that this is a good application of 
this stream peeling off.
Besides, the whole discussion about giving more responsibility to the 
application layer is the fundamental question about mechanism vs. policy, isn't 
it? Me personally, I'm for mechanism, it usually has a longer life than policy. ;-)

There is another point, I was just thinking about. I want to use the stream 
index to demultiplex and I was just confused because Michael wrote about 
(mis)using the stream ID.
Anyway, because there can be several associations, I actually need to 
demultiplex based on association and stream. Now, how can this be done in an 
efficient manner? The best way I could think of, was to use a hash table with 
the association ID or a separate ID that is transferred in user data. It would 
be really efficient, if I could save a pointer in an association that would 
point me directly to a corresponding data structure.
Or is there already any mechanism that supports demultiplexing from 
associations? Do you instead have to peel off associations (which does not 
really solve the problem entirely, though)?

Gabriel