Subject: Re: sctp_peeloff()

From: Kacheong Poon <[email-masked]>
Date: Thu, 11 Dec 2003 08:22:48 -0800

Michael Tuexen wrote:

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

I guess the point of having a socket for individual stream
is not related to what SCTP the protocol tries to do.  It
is more about how SCTP apps want to use the API.  So it
seems to me that the dicussion should be focused on whether
app programmers like to have such as interface.  Then the
second question is what kind of caveats this interface may
have.  Also note that the stream-socket can both send and
receive.  We should also consider the usefulness of having
stream-socket for sending.

The point you raised is that if the app does not behave,
one stream can block the other in receive.  This is a caveat.

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

Note that flow control is not the question here.  The new
API is not an attempt to change the protocol.  It is not
about an app tries to do flow control on a per stream basis.

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

 From the app's point of view, having different sockets for
different streams allow them to separate task handling easier.
It has nothing to do with how SCTP assigns TSNs.  The way an
app will see this is that it just needs to setup one association
but can have multiple data streams controlled individually.  This
is "like" opening multiple TCP connections.  Now whether SCTP can
provide identical semantics is another issue, we know that it
cannot because of the issue rasied.  But is it good enough so that
a well bahaved app can make use of it.  This is the question we
need to ask and answer.

What you described above is really in the SCTP protocol level.
What the stream scheduling I mentioned was about how an app could
schedule different threads in handling send/receive of different
streams.  I think they are separate issues.

-- 

						K. Poon.
						[email-masked]