Re: Bandwidth limiting

Any solution based around router hardware isn't an option for us. We've got
linux boxen, and BSD boxen, but the closest thing we have to a router is an
aging Wellfleet that was hauled out of the nest of an Apteryx. The second link
is under discussion. In all likelyhood, both ISDNs will sit off the router,
there are three meshed proxies sitting on the other side of the router that
would have to make use of it.

But, of course, the problem is that the first 64K we'd want to use would be
direct-to-site (not part of a hierarchy) and the second 64K would always be to
a parent (well, two parents, actually).

My preference would be for a config setup like this:

cache_peer gateway.address direct 0 0 default no-query
limit=64K
cache_peer real-parent parent 3128 3130 default no-query
limit=64K

gateway.address would let us figure out which interface to go direct _on_,
'direct' tells us that the peer isn't really a peer, but merely a set of
modifiers to apply to all direct fetches, the limit gives us a number of bps
(_bits_ per second, because that's what the links themselves are measured in),
in excess of which requests would fall through to the next parent-peer with
spare bandwidth for this one-second timeslice.

DISCLAIMER: It's 3:20am. I may not have thought this through. I _definitely_
have _not_ thought about whether it is even _possible_ to do anything like
this to squid under the current design methodology. I'm musing out loud, and
perhaps waffling a bit as well.

D

Chuck Pitre wrote:

> Dancer,
> there are a few ways you can go about this. I do know there are
> bandwith managing software out there for FreeBSD. I also know that would
> can do bandwidth management off of a CISCO router (11.2 .. maybe 11.1 not
> sure) you could do a form of load balancing, once you start puching about
> 70k through the 64k pipe, then start using the 128k pipe... you should be
> able to specify that you don't want to use more than 64k on the 128k pipe.
> However I'm not sure of that. I'm new to the CISCO world :)
>
> On Thu, 19 Feb 1998, Dancer wrote:
>
> > Date: Thu, 19 Feb 1998 13:39:05 +1000
> > From: Dancer <dancer@brisnet.org.au>
> > To: Squid Users <squid-users@nlanr.net>
> > Subject: Bandwidth limiting
> > Resent-Date: Wed, 18 Feb 1998 19:42:18 -0800 (PST)
> > Resent-From: squid-users@nlanr.net
> >
> > Hmm. On my wishlist is an old, old item. I was rummaging through my
> > 'outstanding' list of thingies and came across a wishful thinking item.
> > That is, some way of limiting the quantity of data fetchable from a
> > parent.
> >
> > Here's a scenario:
> > Say you've got two ISDN links. One at 64K and one at 128K. The 64K link
> > goes directly to the world and costs you _nothing_ in bandwidth, and you
> > want to use that, by preference. There's no parent there,
> > though..documents will be fetched from the origin servers.
> >
> > The 128K link is handling other traffic. People use it to type at shells
> > and things. And it costs money (say, 20cents per megabyte). You are
> > willing to use this, but only if the 64K link is full...and you don't
> > want to draw more than 64K of _this_ link, if you can help it. This link
> > gives access to a hierarchy, as well. There's a parent up here, that is
> > inaccessible from the other link.
> >
> > Can anyone see any _really_ easy way to shoehorn bandwidth throttling,
> > and link-selection (especially when the primary link does _not_ have a
> > parent on it ..hmm..perhaps a dummy peer line?) while performing the
> > absolute minimum amount of effort to make it work?
> >
> > D
> >
> >
> > --
> > Did you read the documentation AND the FAQ?
> > If not, I'll probably still answer your question, but my patience will
> > be limited, and you take the risk of sarcasm and ridicule.
> >
> >
>
> Chuck Pitre chuck@vianet.on.ca
> ViaNet Internet Solutions Technical Consultant
> 128 Larch Street ph: 675-0400
> P3E 5J8 fax: 675-0404
> >--------------------------------------------------<
>

--
Did you read the documentation AND the FAQ?
If not, I'll probably still answer your question, but my patience will
be limited, and you take the risk of sarcasm and ridicule.