Subject: Re: sctp_peeloff()

From: Michael Tuexen <[email-masked]>
Date: Mon, 22 Dec 2003 16:49:13 +0100

Hi all,

see my comments below.

Best regards
Michael

On Dec 18, 2003, at 1:36 PM, Randall Stewart (cisco) wrote:

> Gabriel:
>
> Comments below...
>
> 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.
>>
>> 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. ;-)
>
>
> I agree... the mechanism sounds nice.. a lot of code I am thinking... 
> but of
> course I still have not thought it out yet :-0
>
>>
>>
>>
>> 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)?
>
> I don't know of any mechanism other than the association ID for 
> demux'ing multiple
> associations from one socket.. it was what the assoc-id field was all 
> about i.e. a
> unique system identifier for a association. You could easily put that 
> with the stream
> number into a hash table I would think..
>
> Another thing one could do is mis-use the PPID field in every send. 
> It's a 32 bit
> integer that is passed opaquely through the data transfer...  I guess 
> you could
> have the sender place an ID in this field to represent something you 
> could
> use for an index.... don't know... it actually is a mis-use of the 
> feild though. It
> is supposed to be a way for sniffers and such to recognize what type of
> protocol is being ran over the wire...
>
For multiplexing multiple protocols in one association this is not 
something
I would call 'misuse'. This could be done in SIGTRAN and we is it that 
way
in RSerPool to multiplex the ULP with ASAP.
And yes, ethereal uses this field to detect the ULP of SCTP and this is
a mechanism independent from the port numbers. Whoever that invented, it
is very helpful for ethereal and other packet analyzers.
> R
>
>>
>>
>> Gabriel
>>
>>
>
>
> -- 
> Randall R. Stewart
> ITD - Transport Technologies
> 815-477-2127(o) or 815-342-4222(c)
>
>