2.1.13 Web Replication and Caching (wrec)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


John Martin <jmartin@netapp.com>
Bill Maggs <bill@inktomi.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion:wrec@cs.utk.edu
To Subscribe: wrec-request@cs.utk.edu
Archive: ftp://cs.utk.edu/pub/wrec

Description of Working Group:

The purpose of this working group is to define a co-ordinated caching and replication framework for the world wide web.

Replication of web services and caching of http responses are distinct paradigms that to a large degree require distinct solutions. However, it is also important that web caches and replicated services be able to coexist. Ultimately, the working group will define a framework for efficient, reliable, and predictable service in a web which includes both replicas and caches. Part of this framework will be a means by which replicas and caches may be automatically discovered and utilized by clients.

Because of the wide variety of caching and replication solutions which are already in use, the initial task of the group is to familiarize itself with the diversity of existing practice. The group will therefore produce a document which provides a taxonomy of existing caching / replication developments and terminology which would be used as a reference for later work. In parallel with this, existing protocols and standards which are not publicly documented will be submitted to the IESG for publication as informational RFCs by their respective proponents. Once the initial phase is complete, the group will make a recommendation as to whether further protocol work is necessary or desirable, and submit a revised charter for consideration by IESG and IAB.

Goals and Milestones:

Mar 99


First issue of I-D on taxonomy and terminology (Editor: I. Melve)

Mar 99


First issue of I-Ds on existing caching / replication protocols

Mar 99


Meet at Minneapolis IETF

Apr 99


First issue of I-D on design goals / research issues (Editor: J. Touch)

Apr 99


Final issues of I-Ds on existing caching / replication protocols

Jun 99


Final issue of I-D on taxonomy and terminology

Jun 99


Final issue of I-D on design goals / 688 research issues

Jul 99


Meet at Oslo IETF

Jul 99


Submit I-Ds to IESG for publication as Informational RFCs

Jul 99


Revise charter


No Request For Comments

Current Meeting Report

Web Replication and Caching (wrec)

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


- 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!


[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

- 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.


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.


None received.