Subject: Re: [Tsvwg] Adding recv_msg() from specified stream

From: Florian Niederbacher <[email-masked]>
Date: Wed, 05 Nov 2008 22:22:46 +0100

Michael Tüxen schrieb:
> On Nov 5, 2008, at 8:42 PM, Florian Niederbacher wrote:
>
>> Hello,
>> at the moment there is no way to specify from which SCTP stream to 
>> read? If data is ready on any stream, then you have to read it.
>> The intention is to avoid that data could be blocked on a stream with 
>> no one to read it, which eventually could fill up system buffers, and 
>> result in a HOL- blocking.
>> There are the extended sndrcv info field to figure out form which 
>> stream you are reading next. But is not so comfortable.
>>
>> But what are the reasons not to have different buffers in Kernel 
>> space for each stream? I guess it could be useful to define a 
>> function interface e.g. recv_msg_from_stream().
> It is not just define a function. I think current implementation put 
> messages which can
> be delivered in a socket buffer and the user reads from that buffer.
> So it would mean that you change a lot more than just providing 
> another function...
Yes I agree it's not only a little modification to SCTP, many things 
depend on it. I just want to know what are the arguments for the 
definition of this (in my opinion) not so well chosen buffer-structure 
and recv- modality. I think every SCTP stream should have it's own 
buffer, were messages can be read from. Reasoning follows...
>
>>
>> Otherwise every software developer has to always to implement the own 
>> receiving functionality (reading and buffering). My opinion is, that 
>> a better way is offering an implemented method in the SCTP socket 
>> API. What are your
> Why does every developer need to implement this?
>
> The selection of the stream is a sender side issue and (from my point 
> of view) the receiver
> should actually not care on which particular stream a message is 
> received. By selecting the
> stream the sender just makes sure that messages which have to be 
> delivered in sequence
> are delivered in sequence.
I see your usage of streams is to do with them a sequence ordering of 
data-blocks(messages).

Maybe I have another point of view regarding the usage of the SCTP streams.
I would like using streams to do parallel data transfers on one SCTP 
association with more streams. Every process  takes one stream, but all 
process use the same SCTP association. The processes works independent 
from each other and therefore they should read only from a predefined 
stream. The problem is now that a process can get blocked because 
another stream-message is the next which has to be read from another 
process. Without a recv_msg_from_stream() a very complex interprocess 
communication to avoid a possible HOL- blocking is necessary. This 
should be avoided.
Many network-applications uses parallel TCP connections. I think the 
usage of one SCTP association with parallel streams instead of parallel 
TCP connections, would help to get SCTP more popular and the network 
would also benefit. The result should be a better congestion control 
behavior, less connection setup and tear down traffic, ...

>> suggestions?
>> Best regards
>> Florian Niederbacher

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 5 Nov 2008 23:17:41 +0100

On Nov 5, 2008, at 10:22 PM, Florian Niederbacher wrote:

>>> The intention is to avoid that data could be blocked on a stream  
>>> with no one to read it, which eventually could fill up system  
>>> buffers, and result in a HOL- blocking.
>> It is not just define a function. I think current implementation  
>> put messages which can
> definition of this (in my opinion) not so well chosen buffer- 
> structure and recv- modality. I think every SCTP stream should have  
> it's own buffer, were messages can be read from. Reasoning follows...
If every stream should have its own buffer, then you need also a per- 
stream flow control.
This means a receiver window per stream. You are not only talking  
about changing the implementations
out there in a substantial way, but also the protocol on the wire...
>
>>
>>>
>>> Otherwise every software developer has to always to implement the  
>>> own receiving functionality (reading and buffering). My opinion  
>>> is, that a better way is offering an implemented method in the  
>>> SCTP socket API. What are your
>> The selection of the stream is a sender side issue and (from my  
>> point of view) the receiver
> I see your usage of streams is to do with them a sequence ordering  
> of data-blocks(messages).
>
> association with more streams. Every process  takes one stream, but  
> all process use the same SCTP association. The processes works  
> independent from each other and therefore they should read only from  
> a predefined stream. The problem is now that a process can get  
> blocked because another stream-message is the next which has to be  
> read from another process. Without a recv_msg_from_stream() a very  
> complex interprocess communication to avoid a possible HOL- blocking  
> is necessary. This should be avoided.
> usage of one SCTP association with parallel streams instead of  
> parallel TCP connections, would help to get SCTP more popular and  
> the network would also benefit. The result should be a better  
> congestion control behavior, less connection setup and tear down  
> traffic, ...
OK. Understood. But this usage is not the one SCTP was designed for  
(you asked for the reason why it is
how it is). The idea was of one sender and one receiver (think about  
process if you want) and trying
to minimize the head of line blocking.
For your usage, having a socket per stream would even be more  
comfortable. You would have
the socket buffer per stream, you could control the receive buffer  
size per stream, you could
call select() or poll() per stream and so on. But you would need a  
different protocol on the
wire. I'm not saying that it can not be done, but it wasn't...