From owner-freebsd-hackers Sat Jul 20 0:20:16 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 19D2C37B400; Sat, 20 Jul 2002 00:20:12 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 705F843E3B; Sat, 20 Jul 2002 00:20:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020720072010.HCZT6023.sccrmhc02.attbi.com@InterJet.elischer.org>; Sat, 20 Jul 2002 07:20:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA93310; Sat, 20 Jul 2002 00:05:18 -0700 (PDT) Date: Sat, 20 Jul 2002 00:05:16 -0700 (PDT) From: Julian Elischer To: Rik van Riel Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP In-Reply-To: Message-ID: 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 Sat, 20 Jul 2002, Rik van Riel wrote: > On Fri, 19 Jul 2002, Matthew Dillon wrote: I once wrote a traffic shaper to allow people sharing a link to be able to keep interractive responses good while someone else is FTPing a big file in.. the theory was that teh line becomes unresponsive because the majority of teh window is sitting in the send queue on the internet side of the slow link to the custommer. The answer was to artificially meter out the acks going back to the ftp bulk data source. basically instead of queueing incoming data (well you could do that too,) I queued the outgoing acks and clocked them out by only allowing an ack to be released and forwarded, when my own 'metered simulation' of the ack rate had passed the ack in the packet.. It had the desired affect... With propper tuning you can keep the send queue at the far end of your slow link to 1 or two packets and interactive sessions (which were accounted for, but not controlled) became 'interactive' again despite the existance of the parallel ftp session using most of the bandwidth. Whistle/IBM was going to try for a patent (silly idea I think). I wonder if they ever did..? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message