Subject: Re: sctp_peeloff()

From: Michael Tuexen <[email-masked]>
Date: Mon, 22 Dec 2003 17:14:00 +0100

See my comments below.

Best regards
Michael
On Dec 17, 2003, at 6:43 AM, <[email-masked]> wrote:

>
>
>
> "Randall Stewart (cisco)" <[email-masked]> said:
>
>> I think you describe the above a bit off.. what will happen
>> when a stream gets "stuck" is you would then reach a point
>> where the stream would hold all of the rwnd. TSN's can move
>> forward up until that point.. at which time the stack should
>> clamp the rwnd at 0 and drop all inbound data until
>> the "stuck" stream reads...
>>
>> I just want us all to be clear on what SHOULD occur :->
>
> Great! That was what my understanding is. So the worst case
> is, if user stopped receiving from stream 1, then datas for
> stream 1 will start "eating" rwnd, until some point that
> total rwnd are all used up for stream 1's data, then other
> streams get "blocked".
>
> But again, I'd argu that's the application's problem. Looks
> to me it is the same satuation that an applicaiton just
> stop do ANY receive, eventually all stream data will "blocked".
> No ?
>
The point is who does the scheduling. Asume that I'm using different
threads for different streams than the thread scheduling comes into
the game. Something the application writer has not under control...
So one has to think about what happens if the message processing time
on one stream is 10 times the one on the other stream. How will the
streams be scheduled?
> Or, if we starting support stream specific receive, can we
> put a cap on how much rwnd a stream is allowed to take over?
>
This is talking about oer stream flow control. Having separate buffers
AND a per stream flow control works. But this is not part of the 
protocol
and we do not want to change it.
> -Xiaodan Tang
> QSSL