Re: CARP for squid 1.2

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Sun, 31 May 1998 12:40:15 -0600 (MDT)

--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 31 May 1998, Eric Stern wrote:

> CARP (Cache Array Routing Protocol) intelligently divides load
> up between a number of proxy servers.

Just to clarify:

CARP divides the load absolutely un-intelligently. The redirection is based
on a hash value of a URL. For _example_, URLs with MD5 in the first 30% of
MD5 range [0, 0.30*2^128] go to proxy1, next 50% go to proxy2, and last 20%
[0.80*2^128, 2^128] go to proxy3.

In general, CARP redirector knows nothing about the popularity (frequency of
accesses) of URLs and _actual_ load on the proxies. Thus, CARP does not do
"smart" load balancing, resource allocation and access control, and such. If
the load on individual proxies changes asynchronously OR if you guessed the
"carp-load-factor"s wrong, CARP may overload one proxy while the other will
be under-loaded.

However, as most simple but general ideas, CARP is a very good solution for
dividing a stream of requests between proxies when both
        - capabilities of proxies are stable and known a priory
          (these capabilities are reflected in the carp-load-factor in the
          patch),
        - load variation on each of the proxies is synchronized
          or negligible.

A few questions about the patch:

        After quick checking, I failed to find any modifications to
cf.data.pre in the patch. Please consider moving your notes in README.CARP to
that file.

        In README.CARP you use "carp-load-factor". The parser checks for
"carp_load_factor". Also, the last parameter of strncasecmp() looks strange.

        Can we use MD5s instead of computing hash values from scratch? This
would (a) eliminate quite expensive loop through each character of a url, (b)
improve distribution of hash values (sum of characters with a shift is not a
good hashing function). Does CARP specs fix the method of computing that hash
value?

        Current implementation uses CARP to select among siblings and no
parents or non-carp siblings are allowed in squid.conf. The idea, as I
understand it, is to use CARP-enabled Squid as a CARP redirector only rather
than a caching proxy. I am not sure, but it seems to me that using CARP for
selecting parents makes sense as well. That is, CARP could be used in a more
general form in a _caching_ proxy, similar to the round-robin option... What
do you think?

Thanks for the patch!

Alex.

> from the CARP White Paper (Copyright Microsoft Corp.)
>
> CARP uses hash-based routing
> to provide a deterministic "request resolution path" through an array of
> proxies.
> ...
> 1) Because CARP provides a deterministic request resolution path, there
> is none of the query messaging between proxy servers.
> ...

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:50 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:48 MST