Minutes WREC 1999-11-11

From: Ingrid Melve (Ingrid.Melve@uninett.no)
Date: Fri Nov 26 1999 - 03:08:34 MST


Web Replication and Caching (wrec)
0================================0

Meeting November 11, 1999 at the 46IETF, reported by Ingrid Melve

  Agenda
  
    1. Introductions, agree agenda (5 min)
    2. Taxonomy document (10 min) Ingrid / Ian or Gary
       draft-melve-wrec-taxonomy-00.txt
    3. Known Problems (15 min) John Dilley
       draft-ietf-wrec-known-prob-00.txt
    4. Research Issues (10 min) Joe Touch
       draft-wrec-res-00.txt [NB: If there has been no progress on this
       document since July then we need to either drop it, publish it or
       move it to the re-chartered WREC].
    5. Emerging protocols (15 min) Alberto/Jeremy
       draft-cerpa-wrec-necp-00.txt
    6. Other related work (10 min) Ivan Lovric
       draft-lovric-icp-ext-02.txt
    7. Rechartering (30 min)
       We need to discuss re-chartering WREC. The mood I have gauged from
       the group is that we need to define a charter with some real work
       items and development in it. In particular, the areas of:
          + replication methods
          + inter-proxy communication,
          + proxy to network-element communication,
          + proxy / replica discovery
       
   John Martin chaired the group. John introduced the group and pointed
   out that this is the last meeting of the working group in its current
   form. WREC is proceeding, taxonomy a few months late, rechartering
   discussion (NECP draft is out) as the work we set out to do is done.
   
   More than half the participants had read the drafts!
   
  Taxonomy
  
   [2]draft-ietf-wrec-taxonomy-00.txt is documenting current taxonomy for
   web replication and caching. Unless there are fundemental problems
   with the draft, it should be published closed to its current form.
   
   NECP draft-cerpa-wrec-necp-00.txt is implemented and should be added.
   Discussion on the term reverse proxy, consensus that the current
   wording covers current use.
   
   Two weeks is the cutoff for comments to the mailing list, otherwise
   the document goes to Last Call.
   
  Known Problems draft
  
   No comments recieved the last weeks, and John Dilley considers the
   work to be done (John Dilley was unable to attend the meeting and Jay
   Kistler presented this part.
   
   Two weeks for comments, then it goes to Last Call.
   
  Research Issues draft
  
   There really is not a document. The input so far has been research
   projects, not issues and what to do with it. Want to postphone the
   document until the taxonomy is done and discuss what the issues might
   be then. Decide to drop this document for now.
   
  Emerging protocols
  
   Network Element Control Protocol (NECP) draft is out as individual
   Internet-Draft, presented by Jeremy Elson. L4 switches may use this
   protocol for load balancing or intercepting for transparent proxies.
        NECP allows the cache and switch to exchange control traffic

        What control traffic?
         - When server come up, they can tell the switch:
           "add me to your group for Service X"
         - Servers can send load information; switch does better balancing
         - Switches immediately stop sending work to dead servers
           using periodic KEEPALIVES
         - Transparent Proxy Caches can tell switches to allow direct
           connections for certain clients (e.g. on auth failure)

        Key features
         - minimal
         - assumed per-flow state available on switch
         - extensible load metrics
         - authentication

        Non-features
         - specific load balancing policies
         - IP addresses of friendly servers/caches
         - configuration management

   The group suggested and the NECP authors agreed to cleaning up the
   terminology to be in compliance with the taxonomy draft. This included
   referencing taxonomy terms and replacing text with standardized terms.
   
   WPAD is a working group Internet-Draft draft-ietf-wrec-wpad-01.txt
   (documenting current protocol) presented by Josh Cohen.
   
   The DNS part of this is not good enough, but this is currently
   deployed. Comment on the security consideration section being weak, it
   should include PAC non-compliance (PAC files intepreted by client in
   inconsistent ways) and DNS searching if not hit in first zone.
   
   Want to move forward with WPAD, issues raised from the AD (Keith)
   about IAB/IESG and security considerations.
   
  Rechartering
  
   Suggested starting point:
    1. Definition of problem
    2. Requirements of a (web) replication architecture
          + replication methods, service vs. content replication
          + loosely coupled vs. tightly coupled
          + content discovery
    3. Specific related technology development (e.g.)
          + replica/proxy to network-element communication
          + inter-proxy/replica communication (content distribution)
          + proxy/replica discovery
       
   Agreement was reached to use a top-down architecture. Time expected on
   this is 3-4 months. At the same time there will be specific related
   technology development that needs to integrated with the solutions.
   
   There was a discussion on rechartering, but no conclusion was reached.
   The discussion is to continue on the mailing list.
   
   Joe Touch promised to send outline of architectural requirements to
   the list.
   
Anycast

   Anycast may be used for setting up multiple servers at one IP address,
   given that the servers reside within the same AS. If the servers are
   divided between several different service providers, there scaling
   issues will most probably prevent the number of anycast services from
   reaching more than ten. Anycast is a local solution for delivering
   redundance or for failover, but does not scale in the global Internet.
   
   An interesting proposal for tunnelling Anycast was presented by Dina
   Katabi
   [3]http://www.ana.lcs.mit.edu/dina/draft-katabi-global-anycast-01.pdf
   
Towards an integrated web replication infrastructure?

   IPv6 took seven years, we can do this in two. The goal is to ask the
   network for objects, not to go to specific servers and ask the servers
   for objects.
   
   The current model is to configure the client and then afterwards being
   configured the client can look for objects. If the configuration
   subsitutes a proxy for other lookup mechanisms, there is less
   configuration to be done at the client level and more at the proxy.
   
   Object that exist at more than one location, either because they were
   cached or because they were replicated should be findable from the
   clients. Finding the closest version of a object is difficult today,
   unless the client is configured to use a proxy and there is some
   intelligence at the proxy.



This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST