From owner-freebsd-hackers Fri Jul 19 19:45:30 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 0BB7637B400; Fri, 19 Jul 2002 19:45:25 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72CF443E31; Fri, 19 Jul 2002 19:45:25 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g6K2jHCV081550; Fri, 19 Jul 2002 19:45:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g6K2jHOh081549; Fri, 19 Jul 2002 19:45:17 -0700 (PDT) (envelope-from dillon) Date: Fri, 19 Jul 2002 19:45:17 -0700 (PDT) From: Matthew Dillon Message-Id: <200207200245.g6K2jHOh081549@apollo.backplane.com> To: Rik van Riel Cc: freebsd-hackers@FreeBSD.ORG, Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP References: 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 :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 As a receive side mechanism the idea has merit, but I really dislike artificallly dropping packets as a means of controlling TCP. It's impossible to know what the effect of the drop would have on the remote host's protocol stack. Controlling the remote transmitter by having the receiver change it's window advertisement seems to be a safer route. I may take up the receive-side problem after I get the transmit side down. I still have a lot of work to do on the transmit side. It still takes a little too long to lock onto the correct bandwidth, and interactive traffic will confuse it (though that is one of the reasons why one should set a fairly high minimum, like 4K-8K or so). Your comment on limiting the bandwidth to 90% of maximum is really humerous to me! I spent good two hours trying to get the sender-side algorithm to maintain >90% maximum available bandwidth. The algorithm I am using winds up being the most stable at around 88% and it took a bit of messing around to get it to stabilize at > 90%. I expect a receiver side algorithm would have the same problem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message