> From: "Larry Masinter" <lmm@acm.org>
> Subject: Re: architectural requirements - something to start us off
>
> Joe Touch wrote on 11/29/99 3:53 pm:
> >The architecture consists of three basic components:
> >server, proxy, and client.
>
> OK, but limited... what about gateways, transformation servers,
> authentication services, etc.?
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".
> >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.
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.
> >Clients connect to servers based on the URL of the request.
>
> Clients connect to servers & proxies based on configured or discovered
> 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
> >Network-level services are assumed to route requests from client to server.
> >This (WREC) architecture addresses proxies, and their effect on that
> architecture.
>
> How about "...addresses inter-proxy application-level routing in order to
> 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?
> >In this new architecture, we need:
>
> Why "new" rather than "extended"?
Granted.
> >- 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 more general way.
> >- 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.
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.
> >I'll propose secondary architectural components as follows:
>
> >- proxy inclusion
> > 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?
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.
> 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.
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.
> >- 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.
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.
> >- 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?)
>
> 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.
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
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:27 MST