Subject: RE: ICP issue

From: LOVRIC Ivan CNET/DSE/CAE <[email-masked]>
Date: Wed, 4 Aug 1999 09:42:10 +0200

>AFAIK, in todays cache meshes, a cache must know its peers. It may
be
	>reasonable to suggest that when asymmetric links and other
complications
	>exist, a cache administrator should configure peer selection
algorithm
	>appropriately. IMO, the described problem has little to do with
ICP. It
	>is a question of how configurable peer selection is.

	To solve this problem, a peer selection algorithm should know at
least the size of the requested URL which should be sent back in the
ICP_OP_HIT message. However, RFC 2186 gives no indication of the object size
in the ICP_OP_HIT message. So any peer selection algorithm won't work well
without this information that ICP should return. 

	>I do not know if ICP contains peer selection part (e.g., go to the
first
	>HIT peer). Even if it does, the practice shows that peer selection
is
	>separate from object discovery protocols (ICP, HTCP, Carp, Cache
Digest,
	>etc.). Peer selection procedure drives object discovery routine(s),
	>determining the order in which the latter are used, the time to
stop,
	>and the final selection among several candidates.

	Agreed ! The issue may concern other object discovery protocols. I
guess it is a good practice to separate object discovery protocols from peer
selection; however, object discovery protocols should at least give enough
information (such as object size) to the peer selection algorithm in order
to make the right choice.

	>Real life networks are probably too complex to design a universal
	>automated peer selection algorithm, no matter how much info that
	>algorithm may have access to. This is especially true when people
are
	>killing themselves over 1% increase in hit ratio.

	One of the main goals of the caches is to reduce latency to improve
the QoS from the user point of view; IMO, some work has to be done (within
the WG) to determine what should be the right level of information to
transmit between the layer of object discovery protocols and the layer of
peer selection in order to fully reach this goal.

	Ivan,

---

From: John Martin <[email-masked]>
Date: Thu, 05 Aug 1999 14:33:48 +0200

Ivan,

I guess it boils down to whether you are trying to reduce response time or 
increase hit rate (at all costs). In other words, I am not sure that 
running a complex selection algorithm on a per-query basis is worth the 
effort (and would be difficult with today's technology). However, I 
understand your requirement for this in a case where (e.g.) there are huge 
objects loaded over a satellite and smaller objects loaded from other peers.

>without this information that ICP should return.

I think that returning the size is not unreasonable but I can see probems. 
E.g. what if two caches return different sizes for the same object?

>to make the right choice.

Indeed. There are a lot of different criteria one could apply to peer 
selection or object discovery. I don't think that ICP is the right engine 
for either, though - it is too lightweight.

>peer selection in order to fully reach this goal.

We will be working on the future of caching and I know a lot of people 
share your interest in determining the ``best'' proxy from which to 
retrieve a given object - for both end users / clients and proxies 
themselves. I expect that WREC will start working on these issues once we 
finish our initial phase and it is re-chartered.

Rgds,
John
---------------------------------------------------------------
Network Appliance           Direct / Voicemail: +31 654 308 275
Kruisweg 799                               Fax: +31 23 567 9699
NL-2132 NG Hoofddorp               Main Office: +31 23 567 9600
---------------------------------------------------------------