[aklug] Re: GCI, ond others, bandwith restrictions

On Wed, Oct 20, 2010 at 9:10 PM, Arthur Corliss
<acorliss@nevaeh-linux.org> wrote:
>> Streaming media (by which I mostly mean YouTube) easily count for 40%
>> of HTTP traffic. I'm experimenting with YouTube caching at the moment;
>> so far I'm seeing about 30% savings, which should get us back closer
>> to 20% savings overall.
>
> I've been tempted to try some of that. =A0We are dropping all GET queries=
, but
> I've thought about caching queries to MS & Apple update servers, etc. =A0=
I'd
> appreciate hearing about any success and/or problems you run into doing
> that.

I used to cache MS updates, but unfortunately can't remember why I
stopped. I remember it was a pain, though. Apple updates I am
definitely considering; they're fairly large, and our percentage of
Macs is only rising.

What does dropping GET queries do? How does that work?

With MS updates, an external redirector used to be needed. Squid 2.7
and 3 have introduced several new options for overriding refresh
times, so I need to research that again.

For streaming flash video, I'm testing a commercial squid redir from
cachevideos.com, which again is an external redirector. So far so
good.

> For those providers that have peering agreements I think it would be usef=
ul
> to be able to set up HTCP peers between our clusters. =A0Whether ACS or G=
CI is
> doing any caching at all, though, is a good question.

For organizations that are large enough to enforce use of a PAC file
(Proxy Auto Configuration), squid is a fairly viable option.
Transparent proxying (with disclosure) is easier to maintain, though.
Either way, there are some badly written sites and clients that have
never worked through squid (Microsoft Sharepoint, I'm looking at you.
Google Android, I'm looking at you.) Be prepared to keep a
non-proxyable whitelist.

I have done squid peering via ICP with one of my upstream providers,
but only when multiple ISPs were available. At one point when I had
some bandwidth from AT&T they were transparently proxying all my
outbound traffic on port 80. Boy was it was messy, with no recourse!

As with anything that adds a layer of complexity to your network that
can't be bypassed, be prepared to have it break in interesting ways.

jermudgeon
IT Administrator
Whitestone, Alaska
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Thu Oct 21 06:17:39 2010