Subject: Re: sctp_peeloff()

From: Michael Tuexen <[email-masked]>
Date: Wed, 10 Dec 2003 21:56:07 +0100

Dear all,

the idea on which streams are based on is to minimize
the HOL problem. For the receiver it should not be important
on which stream a message was received, it is only
important that the receiver receives the messages in an
order appropriate for the upper layer.

That is the reason why there is no per stream flow control.
If you need this you can setup separate associations.

Regarding stream scheduling:
The point is that the receiver always provides the packet
with the lowest TSN to the user. This opens the rwnd.
The scheduling takes place at the sender. The sender can
assign the TSN at a very late point and can therefore
provide a fair usage of the association between the streams.
the fairness depends on the scheduling function. This is
useful (some think necessary) for usage in the SS7 environment.
I'm working on a paper describing that stuff.

Best regards
Michael

On Dec 10, 2003, at 11:07 AM, Kacheong Poon wrote:

> Randall Stewart (cisco) wrote:
>> Michael:
>> Interesting point... but is not the problem NOT
>> that the cum-TSN cannot be forwarded... you can
>> always ack the data even though the receiving stream
>> is holding off reading.. but the issue is more how
>> does one manage the rwnd in this situation... I think
>> this is where you are going... If socket a-stream-1 stops
>> reading and socket a-stream-2 is reading.. then it is possible
>> that a-stream-1 will hold all of the rwnd and thus block the
>> association... Since we have no way to apportion the rwnd per
>> stream this is a problem..
>
> This can be an issue.  If an app chooses to peel off a
> stream, it has to be careful in handling the individual
> stream-socket to avoid blocking of other streams.  But
> this also opens up the socket interface for people to play
> with streams scheduling.
>
> Any idea on how to make it safer?
>
>
>
>> Michael Tuexen wrote:
>>> Hi all,
>>>
>>> i think having a fd for a stream is a real problem. If the
>>> user 'decides' not to read from a particular stream because
>>> there is a separate thread/process for it which is blocked
>>> the receiver can not forward the cumulative TSN and therefore
>>> blocks the whole association.
>>>
>>> The receiver should always return in the receive call the
>>> (part of) a DATA chunk with lowest TSN.
>>>
>>> Best regards
>>> Michael
>>>
>>> On Dec 9, 2003, at 12:36 PM, Randall Stewart (cisco) wrote:
>>>
>>>> Kacheong Poon wrote:
>>>>
>>>>> I'd like to gather opinions about making sctp_peeloff()
>>>>> work in one-one style SCTP socket.  The semantics is
>>>>> creating a new socket for a particular stream of an
>>>>> association. The stream number will be passed in the
>>>>> place of the assoc_id in the current sctp_peeloff().
>>>>>
>>>>> Do people think that their apps can benefit from this?
>>>>> Thanks.
>>>>>
>>>> Hmm... There does seem to be some interest (at least
>>>> I have been contacted privately several times) on making
>>>> it so that you can read from a particular stream...
>>>>
>>>> I don't think I would be opposed to this... it will be a bit
>>>> of code for me, but has you have said .. its just code... and
>>>> it may well be quite useful...
>>>>
>>>> Let's see what other developers think... I could go for it :->
>>>>
>>>> R
>>>>
>>>
>>>
>
>
> -- 
>
> 						K. Poon.
> 						[email-masked]
>
>