Date: Sun, 05 Nov 2000 17:10:40 -0800 From: David Greenman <dg@root.com> To: "Richard A. Steenbergen" <ras@e-gerbil.net> Cc: freebsd-net@freebsd.org Subject: Re: tcp sendspace/recvspace Message-ID: <200011060110.RAA24642@implode.root.com> In-Reply-To: Your message of "Sun, 05 Nov 2000 18:11:02 EST." <Pine.BSF.4.21.0011051800020.306-100000@overlord.e-gerbil.net>
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. This just doesn't jive with my memory on this subject. The socket send queue is limited by tcp_sendspace. How can a server have packets in-flight that are outside of the scope of that? In other words, I don't see how an infinitely large receive window is going to get you anything if the server's tcp_sendspace restricts how much data can be buffered in the socket. Clearly you can't discard the data in the socket, moving the window forward, until the receiver's ack for it has been received, so how can you have more data in flight than is buffered in the socket? I guess I really just don't understand the point you're trying to make and I wonder if we're really talking about the same issue? >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. It's been awhile, but I have read the above paper. I haven't looked at the implementation in NetBSD, however. I'm not arguing that it isn't a good idea - I did say that I liked the idea. >> 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 their 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. Huh? Isn't that what I said? By "memory use in some applications", I was talking about applications of FreeBSD, not application programs. I tried to make that clear in the sentence that followed regarding kernel tuning for increased network buffer usage. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. 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?200011060110.RAA24642>