Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Nov 2000 18:11:02 -0500 (EST)
From:      "Richard A. Steenbergen" <ras@e-gerbil.net>
To:        David Greenman <dg@root.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: tcp sendspace/recvspace 
Message-ID:  <Pine.BSF.4.21.0011051800020.306-100000@overlord.e-gerbil.net>
In-Reply-To: <200011052257.OAA24410@implode.root.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 5 Nov 2000, David Greenman wrote:

>    Uh, the negotiated window maximum is the lower of the receiver's advertised
> window and the sender's congestion window, so both sides must cooperate for
> a larger window to be used. Since FreeBSD is used as both a client and server
> platform, I feel it is important to increase both recvspace and sendspace.

Not really. Cooperation on both sides is not totally necessary, as the
senders congestion window does not depend on the senders sendbuf. A larger
sendbuf is only necessary in the face of packet loss recovery. Which is
not to say that this isn't valuable and improves performance, but you'll
still get your performance gain with only receiver side cooperation. The
numbers you're looking for sendbuf wise are at least 2*cwnd.

You should take a look at a paper on the subject from SIGCOMM 98, at
http://www.psc.edu/networking/papers/auto_abstract.html and the
implementation for NetBSD that they have done (as well as other
interesting projects) at http://www.psc.edu/networking/research.html. I
wouldn't recommend copying their implementation exactly, but they have
interesting numbers and graphs on the subject.


>    Overall I like the idea of a dynamically scaling these, but I'm talking
> about the "right now" and not the "next year some time, maybe". I am concerned
> about the increased memory use in some applications, but memory is cheap
> these days and getting cheaper. Really the only issue I see is that some
> people may not be prepared to tune there kernel configs to allow for the
> increased network buffer use.

Memory isn't the issue, kernel memory is the issue, as well as behavior in
the face of network outages.

-- 
Richard A Steenbergen <ras@e-gerbil.net>   http://www.e-gerbil.net/humble
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011051800020.306-100000>