Subject: architectural requirements - something to start us off

From: Joe Touch <[email-masked]>
Date: Mon, 29 Nov 1999 15:49:07 -0800 (PST)

> Date: Fri, 26 Nov 1999 11:25:04 +0100
> From: Ingrid Melve <[email-masked]>
...
>    Joe Touch promised to send outline of architectural requirements to
>    the list.

Here goes.

The architecture consists of three basic components: server, proxy, and client.

The conventional web architecture defines server-client interaction.
Clients connect to servers based on the URL of the request. Network-level 
services are assumed to route requests from client to server.

This (WREC) architecture addresses proxies, and their effect on that architecture.
In this new architecture, we need:

	- a way to include proxies in the routing of requests
		i.e., a way to route requests through proxies

	- a way to maintain the proxies
		e.g., to keep them consistent

(do we need anything else?)

I'll propose secondary architectural components as follows:

	- proxy inclusion
		a way to include proxies in a conventional proxy-less deployment

		- request forwarding
			a way to direct a request towards an appropriate proxy,
			e.g., via policy, observation of availability, etc.
			(i.e., like IP forwarding)

		- request routing (like IP routing)

			- request route computation
				a way to generate appropriate routes according 
				to some metric
				(i.e., like IP route computation)

			- request route exchange
				a way to configure the routes of proxies, clients,
				and other network elements
				(i.e., like IP route exchange)

			There is the issue of bootstrapping this configuration;
			ala BOOTP, DHCP - i.e., how does one start route exchange
			with nothing configured a-priori?
		
			There are standard mechanisms: manual (set a single location)
			and well-known address (e.g., fixed port, broadcast message).

		(?? is it possible that responses will equivalently be forwarded?
		is there utility to that? I.e., to force where things are cached?
		should the architecture include that, even if not yet developed?)

	- cache consistency
		a way to unify the view of what is cached between 
		sets of proxies

		- cache group discovery
			a way to determine the association of sets of caches

		- cache content exchange
			a way to see what is in the others' caches

		- cache unification
			a way to unify or update the content of a cache

??

Joe

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 30 Nov 1999 09:19:41 PST

>server, proxy, and client.

OK, but limited... what about gateways, transformation servers,
authentication services, etc.?
Also open to the proxy/origin confusion of the word "server".

>The conventional web architecture defines server-client interaction.

rfc 2616/2617 defines client-proxy, proxy-proxy, and proxy-origin
interaction.  I'd think you'd want to characterize WREC by what it adds to
that, rather than to the HTTP 1.0 model.

>Clients connect to servers based on the URL of the request.

Clients connect to servers & proxies based on configured or discovered
autoconfiguration scripts.

>Network-level services are assumed to route requests from client to server.

How about "...addresses inter-proxy application-level routing in order to
support more effective caching. "?

>In this new architecture, we need:

Why "new" rather than "extended"?

>- a way to include proxies in the routing of requests i.e., a way to route
requests through proxies

a more standard way? More effective? More consistent? More broadly
applicable?

>- a way to maintain the proxies e.g., to keep them consistent (do we need
anything else?)

I don't think it will be possible to go far without an analysis of static
vs. dynamic web data, customization and content negotiation, authentication
and authorization delegation.

Proxy-proxy communication usually consists of effectively stale data; is the
caching/ETag model in HTTP/1.1 good enough? And unless you address
hit-metering, copyright and related issues, your work may be moot.

> a way to include proxies in a conventional proxy-less deployment

A better way? Is this an architectural or protocol issue or a configuration/
discovery/ deployment issue?

The rest of your note characterizes the problem as first a routing problem
and then a database replication problem, but I don't see the connection
between the tuo.

>- request forwarding
> a way to direct a request towards an appropriate proxy, e.g., via policy,
observation of availability, etc. (i.e., like IP forwarding)

I assume you're going to investigate the current state of deployment here,
which is quite sophisticated.

>a way to generate appropriate routes according to some metric (i.e., like
IP route computation)
>- request route exchange
>a way to configure the routes of proxies, clients, and other network
elements (i.e., like IP route exchange)
>
>There is the issue of bootstrapping this configuration; ala BOOTP, DHCP -
i.e., how does one start route exchange with nothing configured a-priori?
>There are standard mechanisms:
>manual (set a single location) and well-known address (e.g., fixed port,
broadcast message).
(?? is it possible that responses will equivalently be forwarded? 	is there
utility to that? I.e., to force where things are cached? should the
architecture include that, even if not yet developed?)

There are products that do these things.  The issue is whether it makes
sense to try to coordinate caches across trust boundaries, and how to do so.

>- cache consistency
>a way to unify the view of what is cached between sets of proxies

--
mailto:[email-masked]
http://purl.org/NET/masinter

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Nov 1999 10:06:39 -0800 (PST)

> From: "Larry Masinter" <[email-masked]>
> Subject: Re: architectural requirements - something to start us off
> 

The initial architecture should be comparatively simple;
more complicated variations can be defined in terms of 
the base components.

> Also open to the proxy/origin confusion of the word "server".

Agreed. Is it sufficient to indicate server as "having an interface
with an IP address that matches that of the URL in the request".

> that, rather than to the HTTP 1.0 model.

The RFC defines the method of interaction, and, to some extent,
the architecture. I was trying to capture the flavor of the fact
that 'how you find the proxy' is somewhat missing from the 
current model.

> autoconfiguration scripts.

Let me be more precise.

Clients can connect directly to servers (where the server IP address
matches the looked-up IP address of the URL of the request) by
using conventional network services (DNS, IP forwarding, TCP
connections).

True, clients can currently 'find' proxies by static or autoconfigured
scripts. I'm trying to generalize that issue; the primary
architectural issues are
	- how the client is configured and how the
	  request is routed can be decoupled

	- how requests are routed can be done a-priori or 
	  handed-off to a network service

> support more effective caching. "?

It isn't strictly to support more effective caching; it may
also be to get around caches when they're not on a useful path.
Maybe the real purpose is to provide request forwarding so
caches can be used to the fullest extent possible?

> Why "new" rather than "extended"?

Granted.

> a more standard way? More effective? More consistent? More broadly

A more general way.

> hit-metering, copyright and related issues, your work may be moot.

I was assuming we are (newly) re-chartered to address intercache
communication protocols, in which case they serve two purposes:

	- request forwarding (to enhance forwarding decisions
		based on knowledge of cache contents)

	- exchange consistency information

That's why I see the architecture as consisting of two parts;
it's the two categories most of the documented protocols fall into.

> discovery/ deployment issue?

A more general way. The primary issue is architectural - i.e., that
this architecture doesn't assume that the client/proxy is 'configured'
prior to forwarding. That seems to be an architectural decision. There
are various ways to provide forwarding; configuration is one of them.
An instance of that configuration would be a protocol issue.

> and then a database replication problem, but I don't see the connection

See above - it's an observation on the informational protocols in
WREC. If we're moving towards (eventual) standardization of both
sets of protocols, we need an architecture that addresses both, hopefully.

> which is quite sophisticated.

The idea of an architecture is that it is slightly more structured
than a taxonomy, and used to compare different instances. I'm starting
the architecture discussion; hopefully, it will eventually evolve
into a standards discussion, which would address more details of the
state of the art.

The architecture isn't intended to imply a new system; it is intended
to encapsulate a generalization of what's already there, such that
as many existing systems can be described in terms of its framework.

> sense to try to coordinate caches across trust boundaries, and how to do so.

Sounds like you're hinting at "BGP", and might even include policy
routing.  The idea I'm proposing is that we're recapitulating routing
at the application layer, and we can use the routing architecture as a
model.

Joe