Subject: Re: Taxonomy Term closure needed

From: Joe Touch <[email-masked]>
Date: Mon, 13 Sep 1999 13:37:55 -0700 (PDT)

> Date: Mon, 13 Sep 1999 20:17:17 +0200
> Subject: Re: Taxonomy Term closure needed
> To: Joe Touch <[email-masked]>
> From: Henrik Nordstrom <[email-masked]>
> Cc: [email-masked]
> 
> Joe Touch wrote:
> 
> > What concerns me about the above is the use of "intent"
> > in a definition. There must be some objective metric.
> > Management control, service agreeements, etc. aren't
> > useful objective metrics.
> 
...
> > Is there any definition of a reverse proxy that is objective?
> > (and can distinguish it completely from a non-reverse proxy cache?)
> 
> What about this:
> 
> A reverse proxy is officially published (in DNS and/or by official IP
> address) as the origin server and forwards received request towards the
> real origin server. Common usage is relaying requests through a server
> side firewall or providing alternate access points where traffic is
> relayed through private network(s).

Why is it useful or necessary to distinguish what port a proxy sits on?

I saw the discussion that distinguishes whether a proxy is
explicitly forwarded to or in-place-of the server itself. While
this is a clean definition, why make the distinction? Are there
different requests/responses? 

(sure, there are different ways to tune things, but that's a function
of the _data_, not specifically where the proxy is).

Do all requests out of a "server-side proxy" always fall-through
to a single address, rather than 'anywhere in the network'?

Here are the distinctions that may be possible:

	- conventional proxies and clients do not explicitly 
	  direct requests to a server-side proxy cache
	  (the GET request address matches the TCP connection address)

		is this true?

	- requests missing in a server-side cache fall through
	  only to the origin server (i.e., a single fixed IP address
	  and port); they are not forwarded elsewhere

	  	is this true?

Even if both are true, these may not be meaningful differences.
The only meaningful difference may be whether the protocol
changes - does it?

Joe

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 14 Sep 1999 08:51:47 +0200

> The only meaningful difference may be whether the protocol

Yes.

A normal proxy request looks like

[TCP connection client -> proxy server]
GET http://www.example.com/path/to/file HTTP/1.0
[mime-headers]

While a traditional HTTP server request looks like

[TCP connection client -> origin server]
GET /path/to/file HTTP/1.0
[mime-headers]

From reading HTTP/1.1 specs it seems that the intent is to remove this
format difference in a future version of HTTP/1. (RFC 2616 section 5.1.2
Request-URI, second paragraph on page 37)

My main problem with basing a definition of reverse proxy or server-side
proxy on this is that TCP hijacking proxies see server requests while
there is conceptually nothing being server-side or reverse with a TCP
hijacking proxy. The thing being reverse in a revese proxy or
server-side in a server-side cache is how and where it is used, not the
tiny details of the protocol parsing in performs. The term is a
functional description when you discuss network topology and firewalling
with a sites network or IS managers

  A normal proxy brings your people out to the internet

  A reverse proxy gives internet users controlled access to your servers
behind your firewall or private network.

  A server-side cache sits infront of your server and takes some of the
request load by caching.

Regarding the term "server-side caches". To me it is a very broad term
which may include caching performed by the origin server itself. It is
not necessary a proxy. Caching may also be performed in a number of
levels in HTTP server applications, not only at the HTTP protocol level.

--
Henrik Nordstrom

---

From: Patrick McManus <[email-masked]>
Date: Tue, 14 Sep 1999 11:53:58 -0400 (EDT)

In a previous episode Henrik Nordstrom said...
:: 

:: My main problem with basing a definition of reverse proxy or server-side
:: proxy on this is that TCP hijacking proxies see server requests while
:: there is conceptually nothing being server-side or reverse with a TCP
:: hijacking proxy. The thing being reverse in a revese proxy or
:: server-side in a server-side cache is how and where it is used, not the
:: tiny details of the protocol parsing in performs. The term is a
:: functional description when you discuss network topology and firewalling
:: with a sites network or IS managers

I fully agree.. to elaborate:

server side proxies are not really proxies at all.. they're just
origin servers typically implemented that way so clustered hardware
can be used (yielding fault tolerance, division of labor, and things
like filesystem optimizations).. but they are origin servers without a
doubt.. the fact that they fufill some of their requests using HTTP or
ICP or somesuch is not really more germane than if they fufilled them
by running ODBC programs; they are authoritative for the URLs as far
as the client is concerned how they fufill them is a matter of server
design. 

the request presented to them is addressed to them.. and all the data
belongs to the same administrative domain, they are not generic and as
such have no expiration or privacy issues beyond that of normal origin
servers... issues such as the inclusion of cache-control in the
request are not really relevant.. whereas they certainly are with
client side proxies.. in my mind a reverse proxy could choose to serve
a request with cache-control: no-cache out of it's cache because it is
authoritative for that resource..

the sometimes used term accelerator seems to be a much better piece of
terminology for this element.

-P

---

From: [email-masked]
Date: Tue, 14 Sep 1999 09:53:03 -0700 (PDT)

Comments below.
> as the client is concerned how they fufill them is a matter of server

Perhaps I misunderstand you here, but it sounds like you assume that a
surrogate/reverse proxy/server side proxy acts for a single server.
That may be a common implementation, but it is not necessarily the
case.

I started working on surrogates back when I was leading NASA's
webmaster's working group.  That group's chief problem was that CNN
events ("flash crowds") tended to melt the entire NASA network
infrastructure, getting so bad on links to Kennedy and Johnson that
you got cascade failures (retries killing the links, despite tcp
backoff).  We wanted to set up surrogates at the network borders to
take the traffic for the CNN events off the origin servers completely
so that other traffic continued to get through. (We could not do that
by moving all web servers to the border because NASA has several
thousand distinct origin servers with several terabytes of data.)

Initially, manual configuration of the surrogate would mean it was
what you describe--a box or set of boxes that mirrored different
origin servers, depending on where a crowd was forming.  That was not
our aim long term, though.  Our aim was to have a surrogate use a
traffic threshold so that it passed traffic below that threshold to
the origin server but began to cache and serve from the cache when the
threshold was met.  In that instance the surrogate acts as tunnel for
some traffic and serves other traffic from the cache.  The traffic
served from the cache might be from any number of hosts within the
network served by the surrogate.  In the NASA case, those might all be
NASA hosts; in the Exodus case, they might be from a variety of
organizations.  In either case, the surrogate helps keep the origin
server from melting and maintains the internal network infrastructure.

Now, is this taxonomically different from a proxy?  It depends on what
the aim of your taxonomy is.  To borrow a metaphor from biology, this
is probably a case of adaptive radiation, where the same set of genes
looks very different when adapted to a new niche; it's phenotypically
very different but genotypically very similar.  If you want to
describe the base set of genes, then the two different adaptions,
that's fine by me (in other words, I don't care if it's a "primary" or
"secondary" term), but the two devices *are* meant to do different
things in the network, and I *do* want to make sure that the two
aren't conflated to mean the same thing.  Hippos and whales may come
off the same code base, but they pretty clearly aren't the same thing.

				regards,
					Ted Hardie

---

From: [email-masked]
Date: Tue, 14 Sep 1999 10:35:13 -0700 (PDT)

Patrick writes:
> In a previous episode [email-masked] said...
> 
> :: Perhaps I misunderstand you here, but it sounds like you assume that a
> :: surrogate/reverse proxy/server side proxy acts for a single server.
> :: That may be a common implementation, but it is not necessarily the
> :: case.
> 
> not really.. what I was (awkwardly) trying to say is that the server
> side proxy acts for a finite number of servers all under the same
> administrative control.. a single server certainly satifies that as do
> the NASA and exodus examples.

If administrative control can be extended to include a business
relationship like a web hosting company's relationship to its
customers, then I agree.

> The cachability rules of a reverse proxy are goverened by the
> administrative policies that it is serving, not by HTTP
> semantics.. The HTTP requirements are satisified because it is
> considered the origin server from the client's pov.

It depends on the rules.  A GET if-modified-since gets satisfied
the same way, as do any of the e-tag based semantics.   You might
configure a surrogate to ignore some cache directives, but that
happens with user community caches as well.  It is not a necessary
part of the model. 

> For example with your NASA situation.. under high load would one of
> your reverse proxies (I'm unsure of exactly what is meant by
> surrogate, so I'm avoiding the word so I don't misuse it) still
> forward a request to Kennedy that contained [Pragma|Cache-Control]:
> no-cache ? It might.. it might not.. I'd certainly argue that you
> could use out-of-band to notify the proxy of changes.. creating a sort
> of production and development type of environment where the reverse
> proxy never needs to ask what we typically think of as the origin
> server if an element is up to date.. it's presence means it is defacto
> up to date..

You can use out-of-band or "side-band" arrangements to push content
to a surrogate, but it isn't a necessary part of the model.  The
idea of using a threshold-based system is to avoid that sort of 
manual configuration.  

> because of this it isn't really a proxy, it's a destination.. it's an
> origin server that by convention creates it's content through
> HTTP.. if it were a proxy it would have to obey HTTP proxy rules..
> 
> :: Now, is this taxonomically different from a proxy?
> 
> I really think so.. a client expects a proxy to do some work for it,
> and as such has some control over the process of generating the
> response.. a client has no control over how a reverse proxy behaves
> and just wants a resource from it, but cannot control how that happens
> because the reverse proxy 'owns' the data.
> 
> -P

The point of calling these things "surrogates" rather than "proxies" was
to distinguish who expects the device to do some work for it.  As you
note above, the client expects a proxy to do some work for it.  The
server expects a surrogate to do some work for it.  That doesn't make
the surrogate an origin server any more than the proxy is an end-user.
The surrogate may be a destination and the proxy may be a client, but
they are not the same as the ends of the chains.

			regards,
				Ted hardie

---

From: Patrick McManus <[email-masked]>
Date: Tue, 14 Sep 1999 13:17:01 -0400 (EDT)

-P

---

From: Patrick McManus <[email-masked]>
Date: Tue, 14 Sep 1999 15:23:06 -0400 (EDT)

:: > not really.. what I was (awkwardly) trying to say is that the server
:: > side proxy acts for a finite number of servers all under the same
:: > administrative control.. a single server certainly satifies that as do
:: > the NASA and exodus examples.
:: 
:: If administrative control can be extended to include a business
:: relationship like a web hosting company's relationship to its
:: customers, then I agree.

absolutely... administrative control belongs to whomever makes the
decision about what bytes get served on the wire.. under a normal
webfarm SLA that'll be the web hosting company subject to certain
conditions (expiration times, honoring of development->production
requests, whatever..) made with their customer..

I'd suggest that a common distinction would be a web hosting solution
would fall under administrative control where a co-location agreement
typically would not.. but that's not really appropriate for the
taxonomy.

:: It depends on the rules.  A GET if-modified-since gets satisfied
:: the same way, as do any of the e-tag based semantics.   You might
:: configure a surrogate to ignore some cache directives, but that
:: happens with user community caches as well.  It is not a necessary
:: part of the model. 
:: 
[..]
::
:: You can use out-of-band or "side-band" arrangements to push content
:: to a surrogate, but it isn't a necessary part of the model.  The
:: idea of using a threshold-based system is to avoid that sort of 
:: manual configuration.  
:: 

right.. it all depends on the policy.. the point is that how the
content is created is goverened by policy not by protocol (the policy
may simply be to use the protocol, but it may include exceptions, out
of band things, or whatever).. and that's why they all have to be
under the same administrative domain.

:: server expects a surrogate to do some work for it.  That doesn't make
:: the surrogate an origin server any more than the proxy is an
:: end-user.

actually I think of the surrogate(s) and classic-origin server(s)
all together as logically forming the HTTP origin server.. together
they are the end point of the HTTP transaction, how they coordinate
amongst themselves isn't really relevant.. That cluster is one logical
point in the chain. maybe it's just a higher level view of what you're
saying.. 

this brings us full circle to Henrik's point that he doesn't want to
see surrogates/reverse-proxies lumped together with network
transparent proxies (a point that I wholeheartedly agree with). Caches
and origin servers do indeed get different HTTP requests (the URI
formation mentioned earlier is one element, the absence/inclusion of
cache-control/pragma is another).. a surrogate can answer the request
properly getting an origin-server style request because by policy it
is part of the origin server's scope, but a hijacking proxy can't do
it right all the time when getting the wrong style of request because
it doesn't share knowledge of the origin server's state.

-P

---

From: Patrick McManus <[email-masked]>
Date: Tue, 14 Sep 1999 16:42:18 -0400 (EDT)

In a previous episode Patrick McManus said...
:: 
:: actually I think of the surrogate(s) and classic-origin server(s)
:: all together as logically forming the HTTP origin server.. together
:: they are the end point of the HTTP transaction, how they coordinate
:: amongst themselves isn't really relevant.. That cluster is one logical
:: point in the chain. maybe it's just a higher level view of what you're
:: saying.. 

I was thinking about this a little more and it seems to be a
significant clarification to say that: surrogates are an extension of
the origin server(s) that they share administrative control with,
whereas proxies are independent network elements.

Is that a helpful point to make in the taxonomy?

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Sep 1999 16:32:54 -0700

> terminology for this element.

So it sounds like this is just a server, period.

I wouldn't even glorify it with the term "accelerator" - that
speaks to the 'internal' architecture of the server, and
is, as noted above, not germane.

Joe

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 15 Sep 1999 02:58:53 +0200

> > doubt.. the fact that they fufill some of their requests using HTTP  

> So it sounds like this is just a server, period.

To say that a caching reverse-proxy (the most common server-side caches
deployed outside the internal operation of the HTTP server) is just a
server is perhaps a oversimplification. To the client it behaves like a
server, but the implementation and properties is more that of a caching
proxy. The main properties differentiating it from a "caching proxy" is
the clients view of what and where the service is and how and by whom it
is deployed.

Even more so for non-caching reverse proxies. These are often only
relays with close to no HTTP server functionality at all. All data
processing is then done by the real server(s).

The generic term "server-side caching" is a property of the service and
can be implemented in any manner. Details of such a generic term is
clearly outside the WREC scope as it edges on server
design/implementation.

"server-side caching proxy" or "caching reverse-proxy" is one way to
implement "server-side caching" using a separate "box" utilizing
protocol techniques of a caching proxy, possibly combined with
out-of-band information. This technique can be used to implement a form
of "mirroring"/"site replication", and is why it is of importance to
WREC.

"reverse-proxy" without caching or where caching is not the primary task
is a very much different issue. The most common application is acting as
a trusted relay.  This function is also outside the scope of WREC.

To me it is clear that we need a definition for a proxy-cache like
device ("server-side caching proxy", "caching reverse-proxy" or whatever
name we find suitable) intended to be placed infront of a server,
caching server responses and acting to clients as if it was a
authorative source. This identifies a important set of service
mirroring/replicating models/techniques suitable for future
investigation, AND is a technique actively deployed today.

Due to the composite nature of the function such a device performs, and
the close relationship to the functions performed by a "caching proxy"
the definition should probably be second or third level based on
"caching proxy" and something else which binds it to the origin server
side from both the clients and site administrators point of view.

--
Henrik Nordstrom