Re: The future of ICP_OP_HIT_OBJ

My instincts say that HTTP/1.1 connections should be no less (and perhaps
slightly more) efficient. Not necessarily faster, but the returned object
would be subject to TCP flow-control, as well as recovery (if lost).

I consider that a plus. On the down side, it means the data will require at
least one ACK, which it wouldn't as a UDP packet. That in itself could make
a difference. I can see situations where I might (for example) want to use
HIT_OBJ with my parent (to avoid paying for ACKS on the main link), but not
on the local lan between siblings (where bandwidth is cheap).

Or, perhaps I might choose to say, hang-it-all, and do it the other way
around, and use HIT_OBJ locally, where they can't reasonably get lost, and
do it by TCP on the main-link to the parent where things get congested
enough that ICP replies would usually be lost.

Maybe it'd be best to just have an icp-over-tcp flag to go on as a modifier
to the cache_peer/cache_host entries, so we can have our cake and eat it
too. :)

D

Duane Wessels wrote:

> Hi all,
>
> I'd like to get an idea of to what extent people think the ICP HIT_OBJ
> feature is a good idea to continue supporting. Briefly, HIT_OBJ means
> that we include the actual object data inside an ICP HIT reply
> message. HIT_OBJ has caused problems with Squid-1.1 because ICP is
> treated differently than HTTP, namely ICP does not have certain request
> headers such as Cache-Control and Authorization. See
> http://squid.nlanr.net/Squid/FAQ/FAQ-10.html#ss10.12 for more details.
>
> There are a number of factors to consider in deciding if HIT_OBJ
> is a good thing. For example:
>
> - ICP is sent over UDP. UDP does NOT have flow-control
> and could cause congestion.
>
> - Fragmentation of UDP is considered harmful. If a single
> fragment is lost, the entire datagram is lost.
>
> - Many Web objects are small. According to yesterday's log for
> sv.cache, 50% of HTTP "200" replies are 3715 bytes or less.
> 25% are 1475 bytes or less. If we consider ALL replies,
> including "304 Not Modified", then 50% of replies are 2006
> bytes or less. Larger ICP message are probably more likely
> to suffer fragmentation and/or packet loss, but the actual
> chances will depend on path congestion between neighbor
> caches.
>
> - HTTP/1.1 should eliminate concerns over TCP slow start.
> Neighbor caches should utilize numerous, persistent
> connections.
>
> - An ICP HIT_OBJ message will take longer to generate, if the
> object data must be read from disk. A regular ICP HIT
> can be returned immediately.
>
> Given these points, should we keep HIT_OBJ around, or rather just let
> HTTP/1.1 handle it?
>
> Duane W.

--
Note to evil sorcerers and mad scientists: don't ever, ever summon powerful
demons or rip holes in the fabric of space and time. It's never a good
idea.
ICQ UIN: 3225440