Subject: Re: sctp_peeloff()

From: Kacheong Poon <[email-masked]>
Date: Wed, 10 Dec 2003 02:07:05 -0800

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]