Subject: [Tsvwg] SCTP socket buffer options

From: Mark Butler <[email-masked]>
Date: Tue, 06 Dec 2005 21:37:34 -0700

There is an issue with the draft specification for the behavior of 
SO_RCVBUF and SO_SNDBUF on SCTP sockets.  The draft specifies a macro 
definition to allow applications to determine whether each option is 
implemented on an assocation level or a socket level at compile time.  
Unfortunately, some implementations allow the semantics to be changed at 
run time to support either interpretation, e.g. via a sysctl option in 
LKSCTP, making the compile time information inadequate and misleading. 

As a general principle, socket options should have common semantics, 
whether supported by an implementation or not.  SO_RCVBUF and SO_SNDBUF 
by long standing predecent specify socket level buffering. Different, 
protocol level options should be used for finer grained control.  
Implementations should be able to support both levels simultaneously, 
e.g. to keep one sender from starving all the others without abandoning 
the ability to keep the socket buffer from growing without bound.

As such, I propose that the draft be changed as follows:

1. Change the documentation of SO_SNDBUF and SO_RCVBUF to specify socket 
level buffer limits.

2. Add two new options to request per association buffer limits on 
one-to-many sockets:
       SCTP_ASSOC_SNDBUF and SCTP_ASSOC_RCVBUF.

3. Remove references to or deprecate the use of HAVE_SCTP_MULTIBUF

By convention, application level socket buffer options are provided on a 
best effort basis.  Portable applications desiring non-default buffering 
should set both pairs of options.  

Does that sound reasonable?

 - Mark

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