No revision this time - I should have time later tonight or first
thing UK time tomorrow to get a "final" version out. Here are some
comments which might make my life easier (or harder, depending on any
ensuing discussions).
On Thu, 24 Jun 1999 09:42:42 -0700 (PDT), Joe Touch wrote:
>> From: ian@mirror-image.com (Ian Cooper)
>> To: wrec@cs.utk.edu
>> Subject: Re: Taxonomy draft, draft-melve-wrec-taxonomy-00.txt
>> Date: Thu, 24 Jun 1999 16:02:55 GMT
>>
>...
>> 2. Terminology
>>
>> proxy
<snip>
>
>Implementing both server and client requirements is required
>only for non-transparent proxies. The notion of a client or
>server exists only at certain levels - app, transport, etc.
>
>> tunnel
<snip>
>
>Do you want to distinguish or mention types of tunnels? At
>first, I thought you meant application tunnels; at second read
>this could apply to transport, network, or link tunnels too.
>
>> cache
<snip>
>
>Also to reduce server load.
>
>> ....Any client or server may
>> include a cache, though a cache cannot be used by a server
>> while it is acting as a tunnel.
>
>This is confusing - it appears to intend to exclude caching as part
>of tunneling for a particular transaction; it could be interpreted
>as "proxy caches are not allowed to tunnel traffic", even for
>separate requests. Is that also intended?
Some very good points.
Those definitions were originally taken from RFC2068 (I updated
"proxy" today, but need to check the status of the others against
RFC2616). I tend to agree with you, but that means we're fast heading
away from the definitions in HTTP. Any suggestions as to how to
resolve those differences? Should we simply indicate that industry
use is different from the prior definitions? (And is that going to
create any problems for the group?)
>> origin server accelerator
>> a reverse proxy with a cache, acting as server to clients,
>> and a client to servers.
>
>What is reverse about it? All proxies act as servers to clients; clients
>to servers. Does this mean "caches requests", vs a proxy cache "caches
>responses" ?
I'd been wondering about the specific difference (well, mostly in
terms of the later "reverse proxy"). We do need to document the terms
- my understanding is that they are both the same thing under
different names.
You are, of course, correct in that both proxy environments act as
clients and servers. I'll try to clarify.
>> network element
>> router or switch
>
>Or link (e.g., satellite link)? Do you mean "controllable component
>of the network", i.e. to exclude hubs?
Yes, I do mean the latter. I was hoping Cisco's documentation would
help with this, but a quick look doesn't show anything.
>> server cluster
>> a tightly coupled set of servers acting together to share
>> load
>> [Ed note: was proxy cluster - makes more sense to have a
>> generic term]
>
>Wouldn't the generic term be "cluster, as in proxy cluster or server cluster"?
Yup.
>> reverse proxy
>> An intermediary system which acts as both a server and a
>> client for the purpose of serving requests on behalf of
>> origin servers. Requests are serviced internally or by
>> passing them on to the origin server they are representing.
>> A reverse proxy must interpret and, if necessary, rewrite a
>> request message before forwarding it. Reverse proxies are
>> often used as server-side portals through network firewalls
>> and as helper applications for off loading requests from
>> origin servers.
>
>This definition isn't sufficiently different from "proxy cache" -
>what's reverse about it?
Hmm, and we had origin server accelerator too. Sorry for the
duplication.
>> The following definitions are added to describe caching device
>> topology:
>>
>>
>> user agent cache
>> the cache within the user agent program
>>
>> local caching proxy
>> the caching proxy a user agent connects to
>
>local is a relative term; a server can have a local caching proxy too
>(an accelerator). If this is the user's first proxy, can we call
>this "client caching proxy"? or Primary proxy?
True. But in my line of business we call them local caches :-) - so
I was trying to document that current practice. Good point though!
>> upper level caching proxy
>> seen from the content consumer's view, all caches
>> participating in the caching mesh that are not the user
>> agent's local caching proxy
>
>Secondary or intermediate proxy? (upper-level has many implications:
> - that the proxy topology is necessarily hierarchical (it is not)
> - upper means closer to the server
> it could mean HTTP-layer, vs. TCP-layer
I like intermediate - though it probably isn't the "correct" choice of
word when discussing what used to be a "top level" proxy.
>> central cache server
>> a centralized server to requests made by local and upper
>> level caching proxies, but which does not act as a proxy
>
>this can be called just a "cache server" - whether it is central
>or not is independent.
Yes.
>> diffused arrays
>> tightly coupled array of caching proxy servers, acting
>> logically as one service and partitioning the URL name
>> space across the array
>> [Ed note: looks like the above two terms should be merged
>> in some way.]
>
>this is a cache cluster. how requests are 'routed' or dispensed
>within the cluster is the business of the cluster, and not
>a term that needs defining.
>
>> caching mesh
>> a loosely coupled set of co-operating proxy- or caching-
>> servers, or clusters, acting independently but sharing
>> cacheable content between themselves using inter-cache
>> communication protocols (see Section 7)
>
>this too is a cache cluster.
>cache clusters have properties:
> request 'routing'
> object partitioning
Good points. I inherited some of these definitions :)
>Some of these are being defined in the research issues document too.
>I'll post an update of that later today.
That'd be really useful. Thanks.
>> network traffic interception
>> the examination of network traffic within a network
>> element to determine whether it should be redirected
>> [Ed note: still needs some work - doesn't fully consider
>> an environment where the proxy is in a bridge]
>
> Intercept implies to capture that traffic, not just examine it.
>
> Snooping matches the definition better.
Good point.
>> proxy autodiscovery
>> this describes the discovery and configuration for use of
>> a proxy in an environment where the content consumer may
>> be unaware of the proxy's existence. The use of the proxy
>> is transparent to the content consumer, but not to the
>> client.
>
>is this exclusive to the client? don't/couldn't proxies also autodiscover
>each other too?
Yes, I guess.
>> temporal domain, sparse working set cache
>> a subset of the content from one or more origin servers,
>> stored temporarily and collected from requests made by
>> content consumers
>
>the use of the term domain may be overloaded (DNS domain).
>the use of the term temporal is redundent with the term cache.
>I'm not sure why such a specific term is required, either.
>
>> persistent domain
>> a collection of origin servers maintaining a persistent
>> data set from the authoritative reference
>
>the use of the term domain may be overloaded. do you require
>that the server set be in the same DNS domain?
>
>> replica origin server
>> origin server storing a persistent replica of a data set
>> stored at the authoritative reference
>
>Joe
Why couldn't you have made some of these comments earlier Joe!? :)
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:26 MST