home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 97apr / icp-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  6KB  |  163 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. ICP BOF Minutes
  5. Memphis IETF
  6. Monday 15:30
  7.  
  8.           Slides: http://www.nlanr.net/ICP/ietf38-icp-bof-slides.ps
  9. Proposed Charter: http://www.nlanr.net/ICP/icp-wg.html
  10.  
  11. Duane presented a few slides to describe the goal of the BOF.  In
  12. brief, he emphasized that the scope of this BOF was fairly narrow:
  13. discussing two drafts about ICP to be submitted as informational
  14. RFC's.  The first draft describes the current ICP protocol and message
  15. format.  The second draft describes how ICP is currently applied to Web
  16. cache meshes.
  17.  
  18. There were clearly folks in the audience more interested in a working
  19. group focused on evolving the ICP protocol.  This is a fine
  20. idea, but think it belongs in a followup working group, to prevent
  21. diversion of focus from completing the current badly needed pair of
  22. documents.  After the RFC's are accepted, the working group, under this
  23. charter will be closed, although it could easily reopen under a new
  24. charter with the goal of further advancing the protocol within the
  25. IETF.
  26.  
  27. The first document describes message formats and the protocol for ICP
  28. version 2, as it currently exists in Harvest and Squid Web cache
  29. software. This includes:
  30.  
  31.     o The ICP opcodes currently in use and their semantics. 
  32.  
  33.     o Which opcodes an ICPv2 compliant application must support, 
  34.       and which are optional. 
  35.  
  36.     o A description of flags curently used to extend the protocol
  37.       beyond its original design.  
  38.  
  39.     o How ICP is currently implemented over a multicast transport.
  40.  
  41. The second document details the application of ICP to Web caching.
  42. Again, we focus only on existing implementaions and include the
  43. following:
  44.  
  45.     o Terminology used to discuss hierarchical Web caching. 
  46.  
  47.     o Typical cache mesh configurations and why ICP is helpful. 
  48.  
  49.     o A discussion of lessons learned from implementing and deploying ICP. 
  50.  
  51.     o Explanation of the two different roles that ICP is being tasked
  52.       to fulfill: "object location" and "cache policy expression."
  53.  
  54. This working group will NOT address any of the following open issues in
  55. Web caching:
  56.  
  57.      o Useful data caching strategies. 
  58.  
  59.      o Minimizing uncacheable pages. 
  60.  
  61.      o Where caches should be placed within the network. 
  62.  
  63.      o The HTTP/1.1 caching model. 
  64.  
  65. Duane invited questions/comments related to the first draft: message
  66. format, opcodes, option flags, security.  No comments from audience.
  67.  
  68. Duane invited questions/comments related to the second, still
  69. unsubmitted, draft, describing ICP use in Harvest 1.4 and Squid, and
  70. discussing ICP's role in:  cache hierarchies, sending/receiving queries
  71. and replies, multicast.  No comments from audience.
  72.  
  73.  
  74. Questions/issues from the audience:
  75.  
  76.     o Articlate the rationale between choosing a sibling vs. parent
  77.       relationship with respect to bandwidth  (Gary Tomlinson).
  78.  
  79.       The sibling/parent relationship is primarily based on routing
  80.       criteria, not bandwidth.  This will be clarified in the draft.
  81.  
  82.     o One nebulous issue is what does ICP_HIT really mean?
  83.       We might want it to mean "you are allowed to retrieve this
  84.       URL from me."  But currently it means something slighly
  85.       different, which is "I have some version of this URL and it
  86.       is fresh by my standards."
  87.  
  88.       This is an issue when peer caches have different freshness
  89.       requirements.  ICP has no semantics for exchanging timestamp
  90.       information.
  91.  
  92. Proposed ICP WG charter:
  93.  
  94.  
  95. Duane pointed out two important goals of the charter:
  96.  
  97.     o Only tackle existing ICP v2.
  98.     o After RFC's published, decide if ICP WG needs to continue
  99.       in IETF to further advance the protocol.
  100.  
  101. Open Discussion:
  102.  
  103.     IETF working groups work best when dealing with real problems and
  104.     real proposals.  If anyone wants to continue ICP WG, they should go
  105.     off and design something first (Jim Gettys).
  106.  
  107.     Why are we targeting ICP as an Informational RFC?
  108.  
  109.         o because we don't want this to be a standard (Gettys).
  110.         o Informational RFC's can be published easier and faster.
  111.  
  112.     Why are we seeking to form a working group?  Why not
  113.     just submit the RFC?
  114.  
  115.         o because we are seeking community input on whether
  116.           or not the protcol should be advanced (Allyn Romanow).
  117.  
  118.     Why not just make it a Best Current Practices?
  119.  
  120.         o BCP documents usually refer to policy, not protocols.
  121.         o We should document what we believe is wrong
  122.       so we get it less wrong the next time (Gettys).
  123.  
  124.  
  125.     There was an expression of interest in having a working group as a
  126.     place to meet and exchange ideas for caching related things, such
  127.     as fixing NNTP.
  128.  
  129.     However, working groups tend to flail without concrete proposals.
  130.  
  131.     Note that the commercial Harvest code uses version 3 for its ICP
  132.     messages.  This is not documented in the existing ICP drafts
  133.     because that group has not offered it and thier source is
  134.     unavailable.
  135.  
  136.     The next version of ICP should make vendor-specific extensions
  137.     possible without breaking backwards compatibility.
  138.  
  139.     There is an issue with keeping the protocol simple vs. making it
  140.     very flexible.  One camp suggests ICP remain simple and fast,
  141.     another believes that the entire HTTP request is required.  The
  142.     latter can be viewed as "HTTP over UDP" with only minor additions
  143.     such as an ICP_QUERY request method.  But it would be nice to avoid
  144.     the need to parse HTTP request headers for ICP queries.   Some
  145.     performance related experiments would help make this case.
  146.  
  147.  
  148.     The issue of forwarding loops was brought up, and how does ICP deal
  149.     with it.
  150.  
  151.         o Forwarding loops are not really a problem with ICP, perhaps
  152.           because it is a hop-by-hop protocol.  ie, ICP requests
  153.           are not forwarded.
  154.  
  155.         o Forwarding loops are detected in the HTTP part of cache
  156.           requests, with the Via header.
  157.  
  158. More Information
  159.  
  160.     ICP Home Page: http://www.nlanr.net/ICP/
  161.  
  162.     ICP Mailing List: icp-wg@nlanr.net
  163.