Subject: Re: [Tsvwg] Re: SCTP Socket API

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 30 Dec 2005 21:30:50 +0000

Michael Tuexen wrote:

> This would be a good option providing the above functionality.
> If the user sets this option, he simply tells the kernel that
> he will never want more bytes. If he provides less byte in a
> receive call, the procedure of A) apply. I do not know if it would
> make sense to send (optionally) also an ERROR chunk to let the peer
> know that part of the message was lost. I'm nor sure that
> it is good that the receiving SCTP side discards (part of) a message
> and SACKs it and the peer thinks that SCTP has delivered it to the
> user.

And how would it be a better idea to place the data in a ULP
buffer before the ULP ignored it?

With such an option the ULP is announcing its intention to 
ignore any portion of the message beyond offset X, and that
the SCTP implementation is free to optimize reception of
those bytes directly into the bit-bucket.

As that the receiving ULP is *always* free to bit-bucket any
portion of any message it receives I don't see why the peer
needs to be informed merely because an intermediate copy
was eliminated before the data reached the bit bucket.

Obviously the receiver must always be notified of the actual
data size that the peer attempted to send, or at least that
it was longer than the maximum allowed. But it is then up
to the Receiver to know whether the peer attempting to send
more data is an irrecoverable error, or merely a case of the
peer trying to provide more optional data than it can use.

The key distinction here is that it is the receiving ULP
that is ignoring the data, not the SCTP layer. The SCTP
layer would merely be optimally placing the data in the
buffer that the ULP specified, i.e. in the bit bucket.

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg