From owner-freebsd-isp Mon Feb 12 15:37:47 2001 Delivered-To: freebsd-isp@freebsd.org Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by hub.freebsd.org (Postfix) with ESMTP id 415A837B491 for ; Mon, 12 Feb 2001 15:37:44 -0800 (PST) Received: from henrik.localdomain ([212.151.236.146]) by fep04-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with ESMTP id <20010212233716.EQOF6568.fep04-svc.swip.net@henrik.localdomain>; Tue, 13 Feb 2001 00:37:16 +0100 Received: from henrik.localdomain (IDENT:henrik@localhost [127.0.0.1]) by henrik.localdomain (8.9.3/8.9.3) with SMTP id AAA12418; Tue, 13 Feb 2001 00:21:07 +0100 Message-ID: <3A886FE3.7F2C5053@hem.passagen.se> Date: Tue, 13 Feb 2001 00:21:07 +0100 From: Henrik Nordstrom X-Mailer: Mozilla 3.01 (X11; I; Linux 2.2.14-5.0 i586) MIME-Version: 1.0 To: David Wilson Cc: Dennis , FreeBSD Mailing List , squid-users@ircache.net, technical@sai.co.za Subject: Re: Transparent proxying with delay pools based on IP precedence bit References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Wilson wrote: > >we could do that in our etbwmgr product for freebsd. > That would be great ! Especially if it could somehow interface with Squid so > that any Cache hits would not be bandwidth limited, but TCP_MISS's would be > pulled down at the bandwidth specified for that particular client, 16K if it > was and international site or 64K if it was a local site... all based on > precedence bit. Please note that due to the way delay pools operates, they are quite likely more efficient than any packet based bandwidth limiting. Delay pools operates at the application level, with no TCP overhead due to extra retransmissions or whatever. -- Henrik Nordstrom Squid hacker To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message