> Here is an issue of the ICP protocol that I discussed with J.Dilley in
> Oslo.
>
> Sorry for the design of this diagram but it's difficult to do better in
> text mode. However I join you the powerpoint document.
>
> Sib1--->--Link1 (bw 2Mb/s, latency 300ms)-->-----Link3 (bw 128Mb/s,
> latency 0ms)--Sib2
> |--<-Link2 (bw 64 kb/s, latency 0ms)--<--|
> |
> Cache C
>
>
> ICP won't work well in that context. Let's see why...
> If a user submits a request to the Cache C which results in a miss, C will
> send an ICP request to both siblings Sib1 and Sib2. Considering that we
> have an asymetrical link between Sib1 and Cache C (for instance ISDN from
> C to Sib1 and satellite link from Sib1 to C) and that the bandwidth of
> Link1 is higher than Link3, the ICP-HIT reply will always come from Sib2
> before Sib1.
> However, for URLs with size > 5,4K, it would be more efficient to get the
> URL from Sib1 rather than Sib2.
> In fact, the problem is more complex because Sib1 and Sib2 can't have a
> 100% hit ratio.
> With a more common value of 10%, It is more efficient to use Sib1 with
> URLs upper than 48K.
> So the best way to chose depends on the hit ratio and on the link
> characteristics. Maybe other parameters should also be taken into account.
>
> I am curious to know what is the behaviour of the other cache protocols in
> such funny but more and more frequent contexts.
>
Before including this problem within the "known problems draft" in the
approriate form, does anybody have any comments about it.
<<ICP issue.ppt>>
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:26 MST