From owner-freebsd-hackers Thu Jul 12 19:17:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from revolt.poohsticks.org (revolt.poohsticks.org [63.227.60.74]) by hub.freebsd.org (Postfix) with ESMTP id 7C03137B401 for ; Thu, 12 Jul 2001 19:17:30 -0700 (PDT) (envelope-from drew@revolt.poohsticks.org) Received: from revolt.poohsticks.org (localhost [127.0.0.1]) by revolt.poohsticks.org (8.11.3/8.11.3) with ESMTP id f6D2HET67695; Thu, 12 Jul 2001 20:17:14 -0600 (MDT) (envelope-from drew@revolt.poohsticks.org) Message-Id: <200107130217.f6D2HET67695@revolt.poohsticks.org> To: Matt Dillon Cc: Leo Bicknell , hackers@FreeBSD.ORG Subject: Re: Network performance tuning. In-reply-to: Your message of "Thu, 12 Jul 2001 18:28:15 PDT." <200107130128.f6D1SFE59148@earth.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67692.994990634.1@revolt.poohsticks.org> Date: Thu, 12 Jul 2001 20:17:14 -0600 From: Drew Eckhardt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200107130128.f6D1SFE59148@earth.backplane.com>, dillon@earth.backpl ane.com writes: > This is fairly easy to do for the transmit side of things and would > yield an immediate improvement in available mbuf space. For the receive > side of things we can't really do anything with existing connections > (because we've already advertised that the space is available to the > remote end), You can't change the RFC 1323 window scale. You can reduce the window size with each ACK, although this is frowned upon. To quote RFC 791, The mechanisms provided allow a TCP to advertise a large window and to subsequently advertise a much smaller window without having accepted that much data. This, so called "shrinking the window," is strongly discouraged. The robustness principle dictates that TCPs will not shrink the window themselves, but will be prepared for such behavior on the part of other TCPs. Given a choice between failing new connections because insufficient buffer space is available and a slow down (both from the decreased window size and packets dropped by the sender as it's adjusting), the later is probably preferable. Of course, avoiding this by reducing the buffer size of new connections before you run out is a better idea. -- Home Page For those who do, no explanation is necessary. For those who don't, no explanation is possible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message