Editor's Note: These minutes have not been edited. ICP BOF Minutes Memphis IETF Monday 15:30 Slides: http://www.nlanr.net/ICP/ietf38-icp-bof-slides.ps Proposed Charter: http://www.nlanr.net/ICP/icp-wg.html Duane presented a few slides to describe the goal of the BOF. In brief, he emphasized that the scope of this BOF was 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 think it belongs in a followup 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 advancing 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: o The ICP opcodes currently in use and their semantics. o Which opcodes an ICPv2 compliant application must support, and which are optional. o A description of flags curently used to extend the protocol beyond its original design. o 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 implementaions and include the following: o Terminology used to discuss hierarchical Web caching. o Typical cache mesh configurations and why ICP is helpful. o A discussion of lessons learned from implementing and deploying ICP. o 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: o Useful data caching strategies. o Minimizing uncacheable pages. o Where caches should be placed within the network. o The HTTP/1.1 caching model. Duane invited questions/comments related to the first draft: message format, opcodes, option flags, security. 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. No comments from audience. Questions/issues from the audience: o Articlate the rationale between choosing a sibling vs. 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. o 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 slighly 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. Proposed ICP WG charter: Duane pointed out two important goals of the charter: o Only tackle existing ICP v2. o After RFC's published, decide if ICP WG needs to continue in IETF to further advance the protocol. Open Discussion: IETF working groups work best when dealing with real problems and real proposals. If anyone wants to continue ICP WG, they should go off and design something first (Jim Gettys). Why are we targeting ICP as an Informational RFC? o because we don't want this to be a standard (Gettys). o Informational RFC's can be published easier and faster. Why are we seeking to form a working group? Why not just submit the RFC? o because we are seeking community input on whether or not the protcol should be advanced (Allyn Romanow). Why not just make it a Best Current Practices? o BCP documents usually refer to policy, not protocols. o 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 thier source is unavailable. The next version of ICP should make vendor-specific extensions possible without breaking backwards compatibility. There is an issue with keeping the protocol simple vs. 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 does ICP deal with it. o Forwarding loops are not really a problem with ICP, perhaps because it is a hop-by-hop protocol. ie, ICP requests are not forwarded. o Forwarding loops are detected in the HTTP part of cache requests, with the Via header. More Information ICP Home Page: http://www.nlanr.net/ICP/ ICP Mailing List: icp-wg@nlanr.net