ICP and the Squid Web Cache

1
ICP and the Squid Web Cache

• -Duane Wessels and K. Claffy -
• IEEE Journal on Selected Areas in Communication,
  April 1998

2
Agenda

• Introduction
• History of ICP
• The Internet Cache Protocol
• Implementation of ICP in Squid
• ICP Delays
• Hit or Miss ?
• Is it all worth it ?
• Conclusion

3
Introduction

• Surfing the Web can be slow for many reasons.
• Overload of server systems
• Network congestion
• Caching has proven for reducing end user latency
• Fundamental concept is the intermediate storage
  of copies
• Hierarchical Caching and ICP
• A group of Web caches can benefit from sharing
  another cache in the same way that a group of Web
  clients benefit from sharing a cache
• Like other wide-area, the use of hierarchical
  structure is particularly auspicious for the
  scalability and manageability of Web caching

4
Introduction (contd)

• Cache hierarchy
• A set of child caches share a common parent cache
• Child cache forward requests to their parents for
  documents they do not have

5
Introduction (contd)

• The Internet Cache Protocol (ICP)
• Role is to provide a quick and efficient method
  of inter-cache communication
• Offers a mechanism for establishing complex cache
  hierarchies
• ICP allows
• One cache to ask another if it has a valid copy
  of a named object
• Requests to flow between child caches
• Sibling relationship

6
History of ICP

• Harvest cache project
• ICP was originally developed as a component of
  the Harvest cache project
• Harvest cache used a very simple caching model
• Only GET requests should cached
• There is no need to query peers for non-GET
  requests since other caches wont have them
  either
• Squid
• A number of new features have been added
• Private object, ICMP support, ICP_HIT_OBJ,
  ICP_MISS_NOFETCH

7
The Internet Cache Protocol

• Message Format
• 20-octet header
• Variable-sized payload
• Contains a URL

8
The Internet Cache Protocol(contd)

• OPCODE
• Indicates the type of message
• ICP_QUERY, ICP_MISS, ICP_HIT
• VERSION
• ICP protocol version, for maintaining backward
  compatibility
• PACKET LENGTH
• Total size of the ICP message
• REQUEST NUMBER
• Integer identifier to match queries and response

9
The Internet Cache Protocol(contd)

• OPTIONS
• Bitfield to support optional features and recent
  additions to the protocol.
• PADDING
• Currently unused
• SENDER HOST ADDRESS
• Hold the IPv4 address of sender

10
The Internet Cache Protocol(contd)

• A cache will query its peers by sending each one
  an ICP_QUERY message
• The payload of the ICP_QUERY message is a URL
• A cache will extract the URL, check for its
  existence locally
• reply with either an ICP_HIT or ICP_MISS
• The cache originating the ICP_QUERY collects the
  reply message
• Chooses a peer cache from which to retrieve the
  object

11
The Internet Cache Protocol(contd)

• Transport
• Currently uses only UDP
• UDP version is simpler to implement
• ICP is intended as an unreliable protocol and
  TCPs retransmission would actually be
  detrimental.
• The ICP query/reply exchange must occur quickly,
  within a second or two

12
The Internet Cache Protocol(contd)

• ICP vs. HTTP
• ICP is extremely lightweight
• Fixed size header payload (URL)
• This simplicity has both a positive and a
  negative aspect
• Advantage
• Can quickly parse and interpret an ICP message
• ICP turnaround time be extremely fast because a
  cache might handle many more ICP requests than
  HTTP requets
• Disadvantage
• Dose not match HTTP
• Cache use ICP to locate objects, but use HTTP to
  retrieve

13
Implementation of ICP in Squid

• ICP Query Algorithm
• By default, Squid sends ICP_QUERY message to each
  peer
• Processing an ICP query
• Extracts and parse the URL
• If the URL is not valid, return an ICP_INVALID
  message
• Check local access controls
• If access is denied, return an ICP_DENIED message
• Lookup the given URL
• If does not exist, return ICP_MISS
• If the object is small enough, return an
  ICP_HIT_OBJ
• If does exist, return an ICP_HIT

14
The Internet Cache Protocol(contd)

• Collecting ICP replies
• Squid collects replies until it receive an
  ICP_HIT, or until all ICP_MISS replies arrive
• Immediately upon receiving an ICP_HIT, Squid
  begins retrieving the object from that peer
• If an ICP_HIT_OBJ reply is the first to arrive
• Squid has finished object retrieval without even
  needing to make an HTTP requests
• It just takes the object data from the ICP
  message payload and adds it to the local cache

15
ICP Delays

• Find out how quickly ICP requests can be processed

Looking to verify that an ICP request does no
take much longer than the RTT since it will delay
retrieval of the object
16
Hit or Miss ?

• The ICP query dose not provide enough information
  to accurately predict whether the HTTP request
  will be a hit or miss
• What does ICP_HIT really mean?
• I know a little about that URL and have some
  copy of the object ?
• I have a valid copy of that object and you are
  allowed to get it from me ?
• Quick-fix modification
• Include freshness requirements
• Hit for fresh objects
• Include timestamps

17
Is it all worth it ?

• Admit configuring hierarchical Web caches is
  time-consuming and sometimes difficult to
  coordinate
• What is the benefit ?
• Approximately 10 of requests will be cache hits
  in neighbor caches
• This depends on where you are on the quality of
  your Internet service

18
Conclusion

• ICP provides hints about the location of Web
  objects
• To properly implement ICP as a cache policy
  protocol will inevitably require ICP message to
  exchange full HTTP requests.