Re: TCP_REFRESH_HIT a MISS

On Wed, 4 Aug 1999, Maciej Kozinski wrote:

]> 3) For the developers: Is it possible to express the parent/sibling
]> relationship configured in squid.conf appropriately in the log file for
]> cache digest hits, e.g. log a CD_(PARENT|PEER)_HIT?
]>
]
] Could you write more about why do you need that? It would complicate log file
]processing ;) I don;'t have an idea how could it be usable.

Vica versa! I do need it for log file processing. I want to see how much
was fetched from parents and - not combined - how much from siblings. With
cache digests, current (calamaris) practice is to count it as peer
traffic, meaning either parent or sibling.

] I wonder if it really does make a sense... Making this kind of
]difference sure does make a sense in case of ICP, when you ask for
]content information, but also about route availability information
](FIRST_PARENT_MISS?). When you have cache digests, in fact it doesn't
]matter that the hit comes from parent or sibling - every hit is
]sibling-like (in the meaning of ICP), because using CD you're interested
]only in cache having desired content, not these which do not have it.

I get your point. Only CD_HITs are logged, and then it does not matter
since parents and siblings are treated equal, since there is no difference
here. But then, why would you distinguish between SIBLING_HIT and
PARENT_HIT (I would (but might change my mind), calamaris does not) - you
ask both groups and if you got at least one hit in both groups you take
the one which is fastest/closest or whatever else you configured. Or did I
miss something in this hit scenario? If my assumption is right, there is
for whatever reason a distinction between PARENT_HIT and SIBLING_HIT. For
the same kind of reason I would like to be able to distinguish between a
CD_PARENT_HIT and a CD_SIBLING_HIT.

]The cache behaviour when no CD hit sould be like for default parent or
]round robin (when more than one parent).

Or first, fastest matching parent (in case of a list of parents with
different requirements and an ICMP database).

]But I think the parents will die soon... in complicated network topology
their existence does make a sense too.

I don't think that parents will die completely, starting with firewalls
and ending in large networks, where outside bandwidth is expensive, but
asking a cache is not, so your organization would have its own cache ask
the provider's caches. Yes, parent caches seem to be less deployed than
before and on the decline.

Le deagh dh�rachd,
Dipl.-Ing. Jens-S. V�ckler (voeckler@rvs.uni-hannover.de)
Institute for Computer Networks and Distributed Systems
University of Hanover, Germany; +49 511 762 4726
Received on Wed Aug 04 1999 - 03:15:17 MDT