Subject: [Tsvwg] Question on SCTP sockets draft

From: Jon Berger <[email-masked]>
Date: Wed, 28 Mar 2001 16:03:13 +0100

Forwarding an email from my colleague Mike Bartlett.  He can't see the IETF
mail server at the moment.

Jon
>  -----Original Message-----
> From: 	Mike Bartlett  
> Sent:	Wednesday, March 28, 2001 2:29 PM
> To:	[email-masked]'
> Subject:	Question on SCTP sockets draft
> 
> Hi Randall
> 
> I would be grateful for some clarification on the latest SCTP Sockets
> draft.  My question relates to what sections 7.1.9 and 7.1.10 have to say
> about the SO_RCVBUF and SO_SNDBUF socket options on UDP-style SCTP
> sockets.
> 
> For SO_RCVBUF the draft says that for a UDP-style socket, the specified
> receive buffer size "controls the receiver window size for all
> associations bound to the socket descriptor".  
> I'll ask my question using an example. An application creates a UDP-style
> SCTP socket and then specifies using this socket option that the receive
> buffer size is 2000.  It then implicitly creates 2 associations on this
> socket using sendmsg().  I assume that the first association will have an
> advertized receive window of 2000, and the second association will also
> independently have an advertized receive window of 2000.  Is this correct?
> 
> The alternative reading is that the receive window of 2000 would somehow
> apply across both associations at once, which does not map at all well
> onto the value specified in the INIT (or INIT-ACK) chunk.
> 
> My question is similar on the send buffer size option, SO_SNDBUF.  The
> draft says "For SCTP TCP-style sockets, this controls the amount of data
> SCTP may have waiting in internal buffers to be sent. This option
> therefore bounds the maximum size of data that can be sent in a single
> send call. For UDP-style sockets, the effect is the same, except that it
> applies to all associations bound to the socket descriptor". 
> Please tell me that this send buffer size can be repeatedly and
> independently applied to every association created on the UDP-style
> socket.  Returning to my example, if the application specifies a send
> buffer size of 3000 before implicitly creating the 2 associations, I
> assume that the first association implicitly created on the socket has a
> send buffer size of 3000, and the second also has an (independent) send
> buffer size of 3000.  
> Again, it is possible to read this as meaning that the total, cumulative,
> amount of data SCTP may have waiting in internal buffers for both
> associations on this UDP-style socket is 3000, but I prefer the first
> reading!
> 
> Many thanks,
> 
> Mike Bartlett
> Voice Networking Group
> Data Connection Ltd
> Tel:            +44 20 8366 1177        Fax:    +44 20 8363 1039
> Email:  [email-masked]
> Web:            http://www.dataconnection.com

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 28 Mar 2001 15:38:03 -0600

Jon/Mike:

Right now this draft is still in quite a bit of turmoil :)

It will be updated again... soon (I hope). Your point
is quite valid and I am not sure the authors have thought
on which way it would work. 

Normally from what I have seen in my recent FreeBSD play, 
the option effects most strongly the sending side since
it gates the largest packet that can be sent.. I have not looked
at the receive side though.. the drivers usually just use
an up call and pass a mbuf chain to the soappend() function. This
does have the ability to reject the request and this may well
be where the limit would hit... I will have to check.

It makes sense to me though that each association would have the
amount you specify... and I am not sure if it is also true
that the value would reflect through to the rwnd... I am going
to have to do a bit more digging to see what FreeBSD does with
this on the UDP and TCP side :0

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)