Re: [Tsvwg] Re: SCTP socket semantics (buffer size / send failures / MSG_TRUNC / PRSCTP control)

Randall Stewart wrote:

>
> I would think a minimum of 64k.. but really its a Implementation choice
> IMO.. having a guideline is ok.. but it really is up to an
>  implementation.

The problem is one-to-many sockets with small default shared buffers.  
Whatever the default is, SOCK_DGRAM socket creation should fail if  
messages of the default maximum size cannot be received atomically.  
Otherwise the stack either deadlocks or aborts when a sufficiently large 
message arrives.  That is why the default size should be constrained by 
the default maximum buffer size.

Send failure notifications:

Having SEND_FAILED notifications return the original message is a 
serious constraint on buffer size.  There should be a socket option that 
says how much data from the head of the message is saved for a send 
failure notification.  Zero should mean none.  ENOMEM should be returned 
if the size isn't practical.  

When a send failure occurs, such data should be "moved" from the send 
buffer to the receive buffer to prevent deadlock. IF there is not enough 
room in the receive buffer, the data should be truncated, and both 
MSG_EOR and MSG_TRUNC set on the final read of the notification.

MSG_EOR / MSG_TRUNC policy:

I suggest that whenever a partial delivery is aborted, the next read 
returns zero bytes, with both MSG_EOR and MSG_TRUNC set.  It is a very 
good way to keep readers from running messages together.  Notable case 
is when a PR-SCTP receiver receives a FORWARD TSN that causes it to have 
to abort a partial delivery.  So MSG_TRUNC is a practical necessity even 
on sockets with atomic delivery turned off.

Because of this problem, PR-SCTP capability should have to be enabled 
with an option at the socket level.  By default, messages would still 
expire before transmission started, but not after (as specified by the 
current draft).  I suggest SCTP_PRSCTP_ENABLED for the option name.

 - Mark

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg