From owner-freebsd-hackers Mon Jul 1 9:57:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8635037B400; Mon, 1 Jul 2002 09:57:36 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DEEC43E0A; Mon, 1 Jul 2002 09:57:36 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0274.cvx40-bradley.dialup.earthlink.net ([216.244.43.19] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17P4UX-0006K2-00; Mon, 01 Jul 2002 12:57:34 -0400 Message-ID: <3D2089D5.89D0CE7D@mindspring.com> Date: Mon, 01 Jul 2002 09:56:53 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hawkeyd@visi.com Cc: DougB@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ftp and mail much slower into fbsd 4.4 vs and old BSDi References: <5.1.0.14.2.20020629235459.031daf28_mail.Go2France.com@ns.sol.net> <3D1EB35C.70F64275_FreeBSD.org@ns.sol.net> <200207011600.g61G0RW06589@sheol.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 D J Hawkey Jr wrote: > > You can turn off newreno with the sysctl. I put this in /etc/sysctl.conf > > on my machines: > > > > net.inet.tcp.newreno=0 > > Could you explain what newreno is, in a nutshell, the upshots of using it, > and what the ramifications of turning it off are? > > I'm running FreeBSD 4.5-RELEASE-p7, and it's on by default. If you turn it off, you rat all your firends out in the Prisoner's Dilemma. Congestion control protocols only work if everyone participates. All "Reno TCP" implementations include TCP Fast Retransmit and Fast Recovery algorithms [RFC2581]. Fast retransmit relies on three duplicate acknowledgements to trigger the retransmission of a single lost segment. Once the Fast Retransmit has occurred, TCP then waits for enough additional duplicate ACKs to arrive, indicating that half of the data in flight has left the network. Only when this has occurred will TCP send additional new data. The consequence of this delay is that the entire new window of data is transmitted in one half of one Round Trip Time (RTT). This burst can cause repeated bursts in successive RTTs following the recovery, which can result in overall additional burstiness on the network. Hoe [Hoe95] suggested that during Fast Recovery the TCP data sender space out retransmissions and new data on alternate acknowledgements across the entire recovery RTT. (Note that this eliminates the half RTT lull in sending which occurs in Reno TCP.) ...THat's the PSC "nutshell" description of NewReno. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message