Subject: Re: sctp_peeloff()

From: Michael Tuexen <[email-masked]>
Date: Tue, 9 Dec 2003 20:27:07 +0100

Randy,

you are right, that was what I was thinking about. It came
to my mind when i was thinking about receiver procedure of
stream scheduling. This is a method to overcome the limitation
of not having an rwnd per stream. This can then be handled completely
by the sender and does not require any change of the protocol.

However, it seems not to be a good idea to write emails having during a
lab session...

Best regards
Michael

On Dec 9, 2003, at 7:09 PM, 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..
>
> R
>
> 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
>>>
>>
>>
>
>
>