Subject: Re: sctp_peeloff()

From: Michael Tuexen <[email-masked]>
Date: Thu, 11 Dec 2003 13:32:17 +0100

Caitlin,

I see what you mean, but SCTP was not designed to do
this, that seems be to the reason why does not fit now.

What you really would need is a receiver buffer management
on a per stream base. This comes down to a flow control on a per
stream base. This would allow what you want to do:
call receive on one stream providing 20MB for a large file
and call receive on another stream with 1KB for a short message
and do on. But I do know how well this fits in OSes were you
still need to copy from kernel to userland. On most OSes
you have the partial delivery API to handle large user messages.

But my main point is: for supporting different receive buffers
for different streams you also need different flow controls for
different streams. Do you agree with this statement?
Then there is the next problem: Can we extend SCTP (or even do we
need to extend) to provide a per stream flow control. Some guys
thought about this already and the result was, that it is not
possible to do as an extension. Of course, SCTP could have been
designed to provide that feature. But it was not done that way.

Best regards
Michael

On Dec 10, 2003, at 11:45 PM, Caitlin Bestler wrote:

>
> On Dec 10, 2003, at 2:56 PM, Michael Tuexen wrote:
>
>> Dear all,
>>
>> 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 disagree. Each stream can have a very distinct application
> specific meaning. It might be an MPEG Elementary Stream,
> one file transfer in an HTTP or FTP session, an audio
> stream as opposed to a video stream (non-MPEG), etc.
>
> In all of these cases, having to receive the message
> into a holding buffer and *then* put it into the "proper"
> buffer would be extra work for the application.
>
> In many cases successive messages on a given stream will
> be expected to be placed in successive buffers on the
> receiver, for example. If I have been asked to transfer
> a 20 MB file on one stream I do not want to have to read
> it all into my own memory just so I can send it as a single
> message. However the receive may well have a single 20 MB
> buffer waiting for the file.
>
> A lot of this depends on whether you view each message
> as being primarily a "transaction" or whether it might
> just as easily be a checkpointed data transfer. For
> control/transaction oriented messages I would tend to
> agree with you that the receiver should be processing
> the message with the lowest TSN first. But I don't
> think that is necessarily a universal rule.
>
> -- 
> Caitlin Bestler - [email-masked] - http://asomi.com/
> http://asomi.com/CaitlinBestlerPublicPgpKey.html
>
>