Re: Window Scale option

[Jason Thorpe <[e-mail]>]

On Mon, 4 May 1998 15:58:36 -0700 
 [e-mail] wrote:

 >   *> I guess what I'm really saying is that if you have a user interface
 >   *> to TCP to allow the application to specify the window scale value
 >   *> without having to set the buffer size,
 > 
 > Dave,
 > 
 > Why would you want to do that?  It seems to me that the window scale
 > itself should be *completely* hidden from the application; it is after
 > all a kludge; as you noted earlier, we want to obsolete it eventually
 > with a sensible window size.  The application should know ONLY about
 > buffer sizes!

I agree completely.

In some ways, I like with Kevin's suggestion of setting this on a per-route
basis, but that has the problem of being a little too "global"; it catches
things which really have no reason to advertise large windows (e.g.
interactive sessions).

On the other hand, I also have a problem with modifying every application
that might want to do this (although I've started doing this in NetBSD just
to see how annoying it might turn out to be...).  Consider just the FTP case:

	- Modify inetd(8) so that ftpd(8) can be handed a control
	  socket with a large recieve buffer (for passive upload).

	- Modify ftp(1) to allow a larger rcvbuf to be specified
	  (for normal [data socket] and passive [control socket]
	  download).

	- Modify ftpd(8) to allow a larger rcvbuf to be specified
	  (for normal upload).

 > Oh, you mean that there could be a system call that set the buffer max,
 > without pre-allocation of buffers.  But since it has to be ABLE to
 > allocate that buffer space, you can still lose at the beginning.

Um, isn't that what the BSD stack already does?  setsockopt of SO_RCVBUF
simply sets so->so_rcv.sb_hiwat to the specified value; buffers are allocated
lazily upon packet reception, and simply hung off the socket buffer until
the high water mark is reached... In the even the buffer can't be allocated,
the packet is simply dropped at the NIC level, an ACK is never transmitted,
the sender's retransmit timer fires, and its congestion window closes (icky,
but it works).

Jason R. Thorpe                                       [e-mail]
NASA Ames Research Center                            Home: [phone]
NAS: M/S 258-5                                       Work: [phone]
Moffett Field, CA 94035                             Pager: [phone]