Re: [squid-users] SQUID and WCCP V1 in an ISP setup

One more time:

>> > Cache peering is counter-productive in your environment. WCCP will
>> > divide traffic in such a way that data sharing is not required--it
>> > splits traffic based on destination IP of the client
>>requests so every
>> > cache will contain unique data.

_Destination IP_. Not already visited sites by any given client. WCCP
doesn't /care/ where you've been or who you are. It balances based on
the destination IP--so a request destined for a website at 192.168.1.1
will hash out such that it goes to cache1 while a request from the same
client1 destined for a website at 192.168.1.2 will hash out such that it
goes to cache2. When client2 visits the webserver located at
192.168.1.1, he will /also/ be directed to cache1, and when he visits
192.168.1.2 he will also be directed to cache2. Always. Every time,
and no matter who the client is or how long ago the last visit to that
site was. There is no memory based persistence in WCCP, as it would
fail to work because of the exact problem you mention.

Aaron Seelye wrote:

> Just a question Joe, how does WCCP keep track of where everybody went? I
> know when you do per-destination load balancing (as opposed to per-packet),
> it only keeps track of the destinations for five minutes. With many clients
> being rerouted using wccp, I'd imagine the number of destination hosts gets
> quite large. I would think that it would just keep a small number of those
> hosts in memory for it's rerouting and balance the others normally. Over
> time (a day or so) I'd think that without peer-caching, those squid boxes
> would become around 75% identical in their cache contents. Am I missing
> something?
>
> Aaron
>
>
>>-----Original Message-----
>>From: francisv@dagupan.com [mailto:francisv@dagupan.com]
>>Sent: Thursday, December 06, 2001 8:10 AM
>>To: squid-users@squid-cache.org
>>Subject: RE: [squid-users] SQUID and WCCP V1 in an ISP setup
>>
>>
>>I get it now, thanks Joe.
>>
>>-----Original Message-----
>>From: Joe Cooper [mailto:joe@swelltech.com]
>>Sent: Thursday, December 06, 2001 11:48 PM
>>To: francisv@dagupan.com
>>Cc: squid-users@squid-cache.org
>>Subject: Re: [squid-users] SQUID and WCCP V1 in an ISP setup
>>
>>If you're using WCCP to balance requests across multiple
>>caches then no
>>cache member will /ever/ have an object that another cache wants.
>>
>>To copy from my original message:
>>
>> > Cache peering is counter-productive in your environment. WCCP will
>> > divide traffic in such a way that data sharing is not required--it
>> > splits traffic based on destination IP of the client
>>requests so every
>> > cache will contain unique data.
>>
>>The key in that paragraph (which I guess I should have put before the
>>inflammatory statement that cache peering is
>>counter-productive, since
>>it blinded you to the rest of the paragraph ;-), is that the
>>traffic is
>>divided based on destination IP from the client request--so
>>there never
>>be a request for the same data from more than one cache.
>>
>>What I've just said isn't always true--and I'm sure someone
>>will pipe up
>>with why it's not if I don't point it out now. The 'nevers' in the
>>above statements are not true if you take one cache out of
>>the group or
>>add a new cache into the group--or if you change the IP
>>ordering of the
>>web caches in the cluster. In any of those cases (which are isolated
>>and shouldn't happen on a regular basis) there will be some
>>overlap of
>>cache data among the caches--and requests for objects that
>>are already
>>in one cache may reach another cache. In which case cache
>>peering might
>>be useful for about two days--and then it would become
>>counter-productive again.
>>
>>Cache peering then, is a complete and utter waste of cycles and local
>>network bandwidth. Every peer request will always come back
>>as a MISS.
>> Always. No exceptions (except the silly exceptions
>>mentioned in the
>>previous paragraph). So every miss on a local cache will
>>have to wait
>>for misses to come back from its peers before going out to the origin
>>server. We don't want that, as it is counter-productive.
>>
>>Make sense now?

-- 
Joe Cooper <joe@swelltech.com>
http://www.swelltech.com
Web Caching Appliances and Support