From owner-freebsd-hackers Fri Jul 19 19: 4:51 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 2C07E37B401 for ; Fri, 19 Jul 2002 19:04:48 -0700 (PDT) Received: from garrincha.netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by mx1.FreeBSD.org (Postfix) with SMTP id 0ABF043E64 for ; Fri, 19 Jul 2002 19:04:46 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: (qmail 9350 invoked by uid 84); 20 Jul 2002 02:08:37 -0000 Received: from riel@conectiva.com.br by garrincha.netbank.com.br with qmail-scanner-1.01 (. Clean. Processed in 0.367329 secs); 20 Jul 2002 02:08:37 -0000 Received: from 2-110.ctame701-1.telepar.net.br (abcghl@200.193.160.110) by garrincha.netbank.com.br with SMTP; 20 Jul 2002 02:08:37 -0000 Received: from localhost ([IPv6:::ffff:127.0.0.1]:24525 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Fri, 19 Jul 2002 23:04:17 -0300 Date: Fri, 19 Jul 2002 23:04:12 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Matthew Dillon Cc: freebsd-hackers@freebsd.org, Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP In-Reply-To: <200207200103.g6K135Ap081155@apollo.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 19 Jul 2002, Matthew Dillon wrote: > Note that this is a transmitter-side solution, not a receiver-side > solution. This will not help your typing if you are downloading a > lot of stuff and the remote end builds up a lot of packets on your > ISP's router. Theoretically we should be able to also restrict the > window we advertise but that is a much more difficult problem. It's not too hard actually. Random early drop should be enough for incoming packets, just artificially restrict the bandwidth to something like 90% of your maximum download bandwidth and drop packets that come in too fast. This will cause tcp to slow down to the speed limit you've chosen and the ISP queue will never fill up. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message