Minutes of Minneapolis WG meeting

From: Bill Maggs (bill@inktomi.com)
Date: Thu Mar 25 1999 - 10:00:25 MST


Dear Internet WRECers:

Here are the meeting minutes from this week`s inaugural IETF WREC
Working Group meeting in Minneapolis. John and I thought it went quite
well. The better part of about 100 people showed, and we even had at
least three members of the IAB in the room at one point!

Kindly transcribed by the "dean" of Web caching, Duane Wessels.

A. Agenda as agreed upon

Introductions, agree agenda - 5 mins

1. Taxonomy document - Ingrid and Gary - 15 mins
        - draft-melve-wrec-taxonomy-00.txt
        - discussion - 15 mins

2. Research Issues - Joe Touch - 15 mins
        - draft-wrec-res-00.txt
        - discussion - 15 mins

3. Vendor protocols
        - WCCP (draft-forster-web-pro-00.txt) Dave Forster, Cisco - 15
mins
        - WPAD - Josh Cohen, Microsoft - 10 mins
        - Unnamed Network Element-to-Cache Protocol - John Martin, - 10
mins

4. Charter re-visit - 10 mins
        - do we want to look already at the next 6 months...?

5. AOB
        - design issues and network storage - Jaeyeon Jung - 5 mins
        - draft-saillard-cache-mesh-design-00.txt - 5 mins
        - draft-lovric-francetelecom-satellites-00.txt - 5 mins

John Martin asked for a show of hands in the audience for whom had read
draft WG documents. About 75% said they had. Good job.

B. Taxonomy and Terminology Draft, Gary Tomlinson

This document is at
<http://ietf.org/internet-drafts/draft-melve-wrec-taxonomy-00.txt>

Gary and Ingrid Melve are the editors of this document on taxonomy and
terminology, one of the two main "current practice" documents being
prepared by the WG. Gary stated that the editors are looking for high
level feedback on the first draft of this document, and asked
particularly for lots of input from the WG on terminology.

Scope: defining the Best Common Practice of caching and replication in
networks, including many systems and products from many vendors. Gary
pointed out that a companion document in the group on research issues in
caching and replication would deal with architectures that exist
primarily in the research area.

Context: Gary stressed that this is very much a work in progress, and
in need of much comment and review.

Structure:

The document in composed of several different pieces, including:

I. Terminology
The document is still coming together in this area, according to Gary.
To some extent it has drawn on some other successful RFCs, including
RFC 2068 and 2186

II. Relationships
The key relationships are:

A. Client to Replica
B. Inter-Replica
C. Client-to-Proxy (HTTP)
D. Inter-cache (ICP)
E. Network Element to Proxy (WCCP, L4 switch)
F. Proxy to Replica

III. Security

not much here yet

Taxonomy/Terminology Next Steps

1. Agree on Terminology
2. Agree on taxonomic relationships
3. Roll in remaining vendor proposals
4. Complete for IETF 45

Comments:

There was a question about whether the taxonomy doc was only for current
work, or also included research. The doc edited by Joe Touch is intended
to address this.

Micah Beck said that there is a large overlap between caching and
replication, especially when you examine mechanisms and how each of the
two is used in practice. If you squint, a preloaded cache looks like a
replica. It is important to look at mechanisms for caching/replication
as closely as possible; this is orthogonal to data transfer protocols.

Brian Carpenter raised the micro-issue of making sure to allow
derivative works of the I-Ds that are being submitted along with the two
framework documents.

Ted Hardie asked whether there was some asymmetry in some if the
relationships described in the taxonomy document. Doesn`t the end user
a client interact differently with an origin server than a proxy as
client? Ted promised to forward written examples of some of these issues
to the doc editors (Gary and Ingrid).

Another question about the taxonomy scenarios was whether the topology
was missing the element of a directory manager such as DNS.

C. Research Issues Document - Joe Touch, Editor

Principles:

- focus on open issues
- solved problems do not belong
- terse discussion
- solutions only mentioned asthey apply to an issue
- publication-quality references only

Issue Template: Joe stresses that he is just collecting information, and
has a very firm template in which to submit ongoing research
descriptions.

Name: no acronym
Definition-not circular
Goal-measurable benefit
Layers-spell out all layers addressed in the research
Indicator-condition for measurable benefit
Contraindications-if Nicaraguan freedom fighters are involved
Components-key mechanisms that make up this issue
Proposed solutions-brief
Security Issues
Contact

Maturity-Joe says it does not belong here.

Topics:

client-to-client communication
common policy management
common security
multicast
push
routing
topology

Joe proposed a pseudo last call for topics at IETF 45

Questions:

What happens when there is a partial solution? Joe replied that this
group can generate a known problems document, such as violations of
known specifications.

What happens as issues change and get solved? Shouldn`t they be
republished? Aren`t they always working documents?

John Martin replied that these things can be published as RFCs.

D. Vendor Proposals

1. WCCP 1.0 - Dave Forster (forster@cisco.com)

Protocol was previously proprietary

Allows communication between a router and up to 32 caches

A cache advertises itself to a router

A router verifies reacheability

A cache elects itself as "designated."

The designated cache divides up the address space for load balancing
among all registered caches.

WCCP is currently proprietary. A timetable for submission to the IETF is
being determined.

New features/enhancements in WCCP 2.0:

-multicast
-more than one home router- a many-to-many relationship between routers
and caches
-redirection of multiple services/ports, not just http.

Questions:

What about load feedback? In 2.0, cache can feed back load info to the
router

What about IP authentication? In 2.0, you can gop through the router
and skip the cache.

What is the relationship between v1 and v2, and why is v1 an I-D if it
will go away? The intention is to document existing deployed protocols.

What mechanism is there to prevent DoS attacks? None

2. Web Proxy Auto-Discovery Protocol - Josh Cohen, Microsoft Check out
<egg.microsoft.com/wpad>

Josh`s slides should be available on the WREC Web site soon.

This is a joint effort of MS, Inktomi, and Sun to obviate the need for
transparent proxying

There are two ways to do WPAD:

a. via DHCP, option 252 - does not broadcast for a DHCP server because
of security concerns. The response is URI of a .PAC or .INS file

b. via DNS - a lookup to wpad.fulldomain.xx; then WPAD constructs a URI
based on the host lookup response (aa.bb.cc.dd) and a hard coded
filename (i.e. wpad.dat). Going to this URI returns the download of a
config file like jsproxy.pac, which is then run.

When is discovery triggered?

-When the LAN address changes
- When the response expires
-the first use of a "connectoid"

Future Activity

-a joint effort for standardizing
-support for RealAudio, etc
-one-time run, instead of every time

Questions:

Brian Carpenter commented that many dialup systems don`t have domains.
Root nameservers get about 60% bogus domain name queries, he points out,
mostly for the domain "Desktop." Yowch.

Also, what happens of NAT is the path of the request?

E. Network Element-to-Cache Comm. Protocol (formerly known as SWAMP)-
John Martin

-simple, lightweight protocol. UDP, fixed header, variable payload
-two-way
-I`m alive
-Are you alive?
-I`m healthy
-No more please
-Redirect this
-Don`t do x

-designed for memory efficiency
-includes security and authentication-currently based on shared secret
hash
-joint effort of Netapp, Alteon, Foundry, Arrowpoint, Radware
-very open

General Qs:

Is it the groups intention to have a protocol doc for each of the five
scenarios in Gary`s doc? Not really. We`re here to do BCP.

F. Goals and Milestones -Bill Maggs

no changes proposed -

All I-Ds to IESG by IETF 45 (Oslo, July 1999)
Revise charter just after IETF 45

Questions: should individual I-Ds be submitted under the name of the
WREC WG or independently?

Keith Moore said that it doesn`t really matter, it`s up to the WG chairs

Patrik Falstrom voiced the opinion that the docs will be easier to find
if they are submitted under the name of the WG.

The WG chairs said they welcomed I-Ds to the WG. That ensures we will
work to improve them.

Lastly, a plug was made for the Web Caching Workshop in San Diego March
30-April 2. See <workshop.ircache.net>

G. Presentations

These three presentations will be summarized in a following minutes
submission, due to space (and typing!) concerns

Please continue to support the list!

Bill



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