Subject: Re: sctp_peeloff()

From: Michael Tuexen <[email-masked]>
Date: Mon, 22 Dec 2003 17:07:47 +0100

Dear all,
see my comments below.
Best regards
Michael

On Dec 18, 2003, at 1:17 AM, Gabriel Kaelin wrote:

> 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.
>
So you want the complete file to be transfered without the user space 
involved and
only when the file is completely copied to get it one user land 
interaction? So this
would go fast in the kernel. But your user land client/server may not 
be able
to handle the other traffic then, because it is not scheduled. So the 
rwnd will
close. It is not decoupled. You would need a per stream flow control or 
separate  streams.

Another problem I see is the following. At the moment you get one user 
message per receive call. I'm assuming that this semantic will stay the 
same. This would mean that
you have a lot of context switches unless you use the fragmentation 
feature of SCTP
which will also bring in the HOL problem, what you do not want. Sou you 
would also
need a receive_multiple_messages call...

> 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.
In my perspective, the SID is only used to ensure in-sequence delivery, 
and this is
done in a way that the sender choses a SID only to minimize the HOL. 
There should
be no need at the receiving end to look at the SID. You can demultiplex 
several
upper layer protocols by using the PPID. But if you have to demultiplex 
inside one
layer you should use your own field in your layer. This makes your 
protocol work even
if the SCTP negotiates only one stream per direction.
> 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
>