RE: Transparent proxying with delay pools based on IP precedence bit

Hi Dennis,

Thanks for getting back to me.

>just curious, is this a standard practice?
I'm not sure if it's standard practice, but using precedence fields
definitely makes our life much easier when it comes to discriminating
between local and international Incoming traffic.

>how does it handle outgoing non-tcp traffic?
We don't really limit our clients outgoing bandwidth, because our provider
doesn't limit us ;-)
It's really just incoming bandwidth that we worry about.

>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.

David Wilson

-----Original Message-----
From: owner-freebsd-isp@FreeBSD.ORG
[mailto:owner-freebsd-isp@FreeBSD.ORG]On Behalf Of Dennis
Sent: 08 February 2001 09:48
To: David Wilson; squid-users@ircache.net
Cc: freebsd-isp@FreeBSD.ORG; technical@sai.co.za
Subject: Re: Transparent proxying with delay pools based on IP
precedence bit

At 12:42 PM 02/06/2001, David Wilson wrote:
>Hi guys, howzit going ? ;-)
>
>An nice juicy question:
>
>We are an ISP and we allocate our leased line clients subnets of IP's.
>At the moment we use a Packeteer traffic shaper to limit our each of
clients
>international bandwidth to 16K international & 64K Local.
>The Packeteer is able to distinguish between local & international traffic
>because our bandwidth provider marks our incoming packets "precedence"
>fields of all international traffic with a "2" and all local traffic with a
>"0".

just curious, is this a standard practice? we could do that in our etbwmgr
product for freebsd.

how does it handle outgoing non-tcp traffic?

Dennis

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html