Re: Automatic TCP send and receive socket buffer sizing

Anton Yuzhaninov wrote:
Wednesday, December 13, 2006, 1:30:26 AM, Andre Oppermann wrote:

AO> The patch is available here (it may apply with some fuzz):
AO> Any tests and test reports are very welcome.

Please answer on question from Phil Rosenthal:

PR> 1) I've seen in production that some sockets get large very
PR> quickly during periods of high latency (eg: when sending to a user
PR> downloading from a cablemodem and their headend gets temporarily
PR> saturated and has large buffers, which raises the RTT under
PR> saturation, which increases the bandwidth delay product), but then
PR> as there isn't any code to shrink the buffers. This would probably
PR> need to be in the timers to notice the case of the sender
PR> temporarily stopping sending - eg in a keepalive http socket (a
PR> separate, but related issue).

The send buffer increasing because of buffering in the network (like
a cable headend) is expected. We don't have any way to distinguish
this from a normal high latency link. Is is really the job of the
router operator (ISP) to configure the buffer memory and interface
queues properly and to enable things like RED.

Shrinking the send buffer can only be done when it is idle and empty.
But then it doesn't consume any kernel memory anyway. The next time
you send something it is very likely that the network conditions are
roughly the same as before and a large socket buffer makes sense and
increases throughput. In the case where the socket buffer is large
and filled and the receiver becomes unreachable the socket has to
hold on to the data unless the application closes it. There is no
way to undo an application write() and to drop data from the send
buffer. That would violate all TCP specs and assumptions about the
behavior of sockets and reliable data transport.

You have to keep in mind that TCP sees the network only as black box
and doesn't have any information on delays, bandwidths, network buffering
or any other parameter of it. It can only try to discover certain
characteristics after a flow of data has been established. Even then
there is a lot of variance and uncertainty still going on. It's essentially
impossible behave perfectly for all possible network conditions. The
automatic send buffer is not perfect either and has some cases where
it may allocate too much resources of the host to a particular connection.
OTOH it does much better than the small fixed sized buffer we had before.

freebsd-net@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Communication speed between blocking call and non blocking cal
    ... You could use event based notification, ... When you use nonblocking I/O, the system may have to perform extra buffering ... data buffer until you say that you are done with it. ... I checked default socket buffer ...
  • Re: strange select() behavior
    ... sharing descriptors, might fill that interface buffer. ... What do you do when a blocking socket operation returns ENOBUFS? ... because it's a semantic change. ...
  • Re: Can someone help me
    ... // contents from the server to the client public class AsynchNetworkFileServer {class ClientHandler {// constructor public ClientHandler(Socket socketForClient) {// initialize member variable socket = socketForClient; // initialize buffer to hold ... // contents of file buffer = new byte; // create the network stream networkStream = new NetworkStream; // set the file callback for reading ...
  • Re: [PATCH] CONFIG_PACKET_MMAP should depend on MMU
    ... The entire data buffer is allocated as one contiguous lump in NOMMU-mode. ... +#ifndef CONFIG_MMU ... * find out where the socket buffers are so that NOMMU mmap can return the ...
  • Re: Socket stuck with puts over ADSL line
    ... gets stuck with the puts command within the filevent writeable ... Is the socket configured as -blocking 1? ... local buffer would fill rapidly, ... buffered portion across the WAN as its own TCP packet, ...