Minutes of the Internet Cache (ICP) BOF
Slides: http://www.nlanr.net/ICP/ietf38-icp-bof-slides.psProposed Charter: http://www.nlanr.net/ICP/icp-wg.htmlDuane presented a few slides to describe the goal of the BOF. In brief, he emphasized that the scope of this BOF is fairly narrow: discussing two drafts about ICP to be submitted as informational RFC's. The first draft describes the current ICP protocol and message format. The second draft describes how ICP is currently applied to Web cache meshes.
There were clearly folks in the audience more interested in a working group focused on evolving the ICP protocol. This is a fine idea, but it belongs in a follow-up working group, to prevent diversion of focus from completing the current badly needed pair of documents. After the RFC's are accepted, the working group, under this charter will be closed, although it could easily reopen under a new charter with the goal of further advancement of the protocol within the IETF.
The first document describes message formats and the protocol for ICP Version 2, as it currently exists in Harvest and Squid Web cache software. This includes:
· The ICP opcodes currently in use and their semantics. · Which opcodes an ICPv2 compliant application must support, and which are optional. · A description of flags currently used to extend the protocol beyond its original design. · How ICP is currently implemented over a multicast transport.
The second document details the application of ICP to Web caching. Again, we focus only on existing implementations and include the following:
· Terminology used to discuss hierarchical Web caching. · Typical cache mesh configurations and why ICP is helpful. · A discussion of lessons learned from implementing and deploying ICP. · Explanation of the two different roles that ICP is being tasked to fulfill: "object location" and "cache policy expression."
This working group will NOT address any of the following open issues in Web caching:
· Useful data caching strategies. · Minimizing uncacheable pages. · Where caches should be placed within the network. · The HTTP/1.1 caching model.
Duane invited questions/comments related to the first draft: message format, opcodes, option flags, and security. There were no comments from audience.
Duane invited questions/comments related to the second, still unsubmitted, draft, describing ICP use in Harvest 1.4 and Squid, and discussing ICP's role in: cache hierarchies, sending/receiving queries and replies, multicast. There were no comments from audience.
Questions/issues from the audience:
Articulate the rationale between choosing a sibling versus parent relationship with respect to bandwidth (Gary Tomlinson). The sibling/parent relationship is primarily based on routing criteria, not bandwidth. This will be clarified in the draft.
One nebulous issue is what does ICP_HIT really mean? We might want it to mean, "you are allowed to retrieve this URL from me." But currently it means something slightly different, which is "I have some version of this URL and it is fresh by my standards." This is an issue when peer caches have different freshness requirements. ICP has no semantics for exchanging timestamp information.
Duane pointed out two important goals of the charter:
· Only tackle existing ICP v2. · After RFC's published, decide if ICP WG needs to continue in IETF to further advance the protocol.
IETF working groups work best when dealing with real problems and real proposals. If anyone wants to continue the ICP Working Group, they should go off and design something first (Jim Gettys).
Why are we targeting ICP as an Informational RFC? Because we don't want this to be a standard (Gettys). Informational RFC's can be published easier and faster.
Why are we seeking to form a working group? Why not just submit the RFC? Because we are seeking community input on whether or not the protocol should be advanced (Allyn Romanow).
Why not just make it a Best Current Practice? BCP documents usually refer to policy not protocols. We should document what we believe is wrong so we get it less wrong the next time (Gettys).
There was an expression of interest in having a working group as a place to meet and exchange ideas for caching related things, such as fixing NNTP.
However, working groups tend to flail without concrete proposals. Note that the commercial Harvest code uses Version 3 for its ICP messages. This is not documented in the existing ICP drafts because that group has not offered it and their source is unavailable.
The next version of ICP should make vendor-specific extensions possible without breaking backward compatibility.
There is an issue with keeping the protocol simple versus making it very flexible. One camp suggests ICP remain simple and fast, another believes that the entire HTTP request is required. The latter can be viewed as "HTTP over UDP" with only minor additions such as an ICP_QUERY request method. But it would be nice to avoid the need to parse HTTP request headers for ICP queries. Some performance related experiments would help make this case.
The issue of forwarding loops was brought up, and how ICP deals with it. Forwarding loops are not really a problem with ICP, perhaps because it is a hop-by-hop protocol. For example, ICP requests are not forwarded. Forwarding loops are detected in the HTTP part of cache requests, with the Via header.
ICP Home Page: http://www.nlanr.net/ICP/
ICP Mailing List: icp-wg@nlanr.net