[Draft] minutes for the WREC meeting, IETF48 (Pittsburgh)
Apologies for absence: John Martin
In addition to a discussion of the WREC Known Problems document
(draft-ietf-wrec-known-prob-02.txt) there were two presentations. There
was no discussion on the WREC Taxonomy document at this meeting.
Surrogates presentation
-----------------------
Ted Hardie & Mark Nottingham
(draft-nottingham-surrogates-00.txt)
Mailing list: surrogates@equinix.com
(subscribe at surrogates-request@equinix.com)
Open source surrogate: bellwether
<URL:ftp://ftp.equinix.com/bellwether/bellwether.tar.gz>
Definition of the term "surrogate" exists in the WREC taxonomy but this
needs to be extended. Need to document the differences from other devices
(e.g. proxies); caching surrogates vs. caching proxies.
Must examine HTTP headers related to cache-control to distinguish between
caching proxies and caching surrogates; determine the applicability of
existing headers; get rid of proxy-specific directives.
There are currently no interoperable standards for a content provider to
interact with multiple CDNs (how to choose between multiple CDNs, where URL
re-writing is performed?). There are a minimal set of interactions:
expire, refresh, extend TTL, pre-load.
Surrogate specific enhancements: authoritative surrogates, content
negotiation, authentication issues, redirect resolution.
Define semantics of how surrogates behave within the network. Fixing bugs
in cache-control headers vs. defining new directives; cache-control headers
do not necessarily apply to surrogates (but do apply to other
clients). Other groups (e.g. Extensible Proxies & Content Control HTTP
headers) are investigating HTTP header issues; there should be cooperation
between the groups.
HTTP specification prohibits (new?) end-to-end headers. However, the
surrogate acts as a gateway.
The authorization issues surrounding surrogates are presently not clear.
Work needed:
* Definition of the term
* Document differences from other devices
* Examine HTTP headers for applicability
Volunteer Authors: Mark Day, Fred Douglis, Jon Stracke
Extensible Proxies presentation
-------------------------------
Gary Tomlinson
(draft-tomlinson-epsfw-00.txt)
Mailing list: ietf-opencache@imc.org
(subscribe ietf-opencache-request@imc.org)
<URL:http://www.extproxy.org>
Workshop on 13 September 2000
Intent is to provide content driver services within proxies:
* there are currently no standards in place
* orthogonal to caching proxy infrastructure
* provides an opportunity for a (caching) proxy to exploit
content-driven
services
* Need to develop the framework, requirements, and standards
* Examine security issues
* Modifying bits on the fly
* Value add to content services (e.g. Ad. injection)
* Operate on behalf of users or content providers
Within the extensible proxies framework an interception proxy should never
change content without a content provider relationship.
Goals:
* Establish standard architecture requirements, protocols, APIs
* Consistent with end-to-end principle
* Encompass IETF frameworks including AAA and policy
* Programming language independence
First goal is to develop the framework.
Next steps:
* suitable for IETF? (consensus suggests *not* suitable for WREC)
* spans sufficient space for own WG
* need input from content providers - their perspective is currently
missing
* consider the issue of APIs in IETF
* request for a bof in San Diego?
WREC Known Problems draft
-------------------------
Ian Cooper
(draft-ietf-wrec-known-prob-02.txt)
19 submissions covered in the current draft, plus 1 submission since
- Architecture: 9 (+1)
- Implementation: 6
- Administration: 4
Architecture:
"Interception proxies break client cache directives"
(Clients do not send cache-control headers as they believe they are
communicating with a server, not a proxy)
Fix RFC2616 - cache control headers should always be sent
Very high priority (10/10)
Work on proxy discovery to remove need for interception proxies
"Interception proxies prevent introduction of new HTTP methods"
Already "fixed" within RFC2616
RFC2616 states that a proxy must operate as a tunnel if it does
not understand a request
"Interception proxies break IP address-based authentication"
(Content providers mistakenly using IP based authentication)
Recommend creation of an Informational RFC for advise on dos and
don'ts
for content providers
Medium priority (6/10)
"Cannot specify multiple URIs for replicated resources"
(Servers/proxies cannot redirect requests to alternate locations where
the
resource is known to reside)
Priority -1/10 - take to mailing list
"Replica distance is unknown"
Priority of -10/10 - "impossible" to calculate, should not be an area
of interest for the group, let CDNs use their own secret sauce
"Proxy resource location" (and surrogates)
Medium priority (4/10)
"Caching proxy peer selection in heterogeneous networks"
Of interest to the group, come back to this at a later date
Low priority (2/10)
"ICP performance"
(should be moving away from ICP)
"Caching proxy meshes can break HTTP serialization of content"
Move away from use of heuristics
Low priority (1/10)
"The Vary header is underspecified and/or misleading"
Work with other groups (e.g. cnhhttp) to improve
Medium priority (5/10)
Implementation:
"Use of Cache-Control headers"
(Content providers not using Cache-Control headers)
Dos and don'ts document
Medium priority (6/10)
"Lack of HTTP/1.1 compliance for caching proxies"
Little that the group can do directly
Push the community to provide better support
Low priority (for WREC) (1/10)
"ETag support"
Little that the group can do directly
Push the community to provide better support
Low priority (for WREC) (1/10)
"User agent/proxy failover"
Related to discovery of proxies
Medium to high priority (7/10)
"Servers and content should be optimized for caching"
Dos and don'ts document
Medium priority (6/10)
"Some servers send bad Content-Length header for files that contain CR"
Not something the group can address, programming bugs (0/10)
Administration:
The group identified that WREC is not in a position to do any work in this
area.
Next steps:
* Re-work KP document to better describe those problems the group plans
to
address; move other problems to appendix so that they are at least
captured in a single location
* Identify those areas future work for the group and get started
- "fix" RFC2616 cache-control issues
- proxy/surrogate discovery
- document on dos and don'ts for content providers
- better specification of Vary header (with cnhhttp)
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST