Subject: Re: sctp_peeloff()

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 16 Dec 2003 06:20:24 -0600

Kacheong:

One minor correction...

Kacheong Poon wrote:

> Michael Tuexen wrote:
>
>> Assume the you have 1 stream from A to B and 10 from B to A.
>> Now you get a socket for receiving data on stream 5 at A. On
>> what stream do you send data?
>
>
> There is only one stream from A to B, so use that stream.
> It is really a decision made by the app on how to arrange
> the use of streams, and thus stream-socket...
>
>> My point is not that the app does the wrong thing, but possibly it
>> depends on the scheduling of the threads. Something which is out of 
>> scope
>> of the transport...
>
>
> It seems that system scheduling has very little to do
> with the issue, unless the app itself tries to use
> specific OS scheduling service to arrange different
> scheduling for itself.  The worst case scenario you've
> given is that a stream-socket will continue to read from
> a specific stream, while other streams are "stuck"
> therefore casuing a SCTP protocol issue as the TSN does
> not move ahead. 

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 :->

R

>
>
> Normally, this has nothing to do with system scheduling
> as the scheduler should do the right thing.  The only
> problem is that the app deliberately does not read.  This
> is outside the control of the system.  If the app itself
> tries to manipulate the scheduling, it'd better do the
> right thing.
>
>> If you can make sure that the app will receive data on ALL streams 
>> without
>> delay, you have no problem. But how can you do this?
>
>
> Only the app itself can make sure that it continues to
> read.  The system cannot force an app to read.  But this
> is fine and has nothing to do with the interface.  The
> interface just makes sure that an app can receive from all
> streams, whether the app chooses to read it is not the
> interface's problem.  The stream-socket does not prevent
> an app from receiving from all streams.
>

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-4222(c)