When going through the list of examples (and then later some of the ideas on
trust and administrative controls), I kept coming back to how things would
vary depending upon who owned the cache and where it fell along the
request/reply pipeline. In order to help out my own thought process, and
maybe simplify things a bit, I've put together a bit of ASCII art here,
along with some thoughts:
| || |
Content | CDN || ISP | Client
Provider | Service || |
| || |
| || |
/-----\ |-----| | |-----| || |-----| | |-----| /----------\
| web |<->| rev |<---->| CDN |<---->| ISP |<---->| fwd |<->|users |
| srv | |proxy| | |cache| || |cache| | |proxy| |(browsers)|
\-----/ |-----| | |-----| || |-----| | |-----| \----------/
| || |
| || |
INBOUND<===================================================>OUTBOUND
(if this does not look correct, try a fix-size font)
Not shown here are any of the remote callout servers that may exist.
This represents what I see as each of the possible proxy-points where a OPES
extension could sit, each with it's own concerns. Note that for content
provider, only the first two (their own and their CDN's) can be guaranteed
to exist, and for the client, only the last two (their own and their ISP's)
- hence the double line separating them.
I am assuming two forms of rules - those going outbound with the content
(dynamic), those installed by owning administrators (static).
I also feel that this breakdown of rules and responsibilities will help us
when we begin to talk about the proxy extensions communicating with the next
proxy up or down the line (there is a brief mention of this in
draft-tomlinson-epsfw-00.txt, section 5.5).
Also, there has been mention of avatars for the clients. While I have heard
this mentioned in discussion and at the recent IETF, I have not seen
anything indicating exactly what form they would take (I assume
automatically supplying personal information or protecting privacy), or how
they would be installed on the proxy. I would like to hear more about this
topic.
In the following I will briefly mention the concerns of each of the owners
along the path, and give examples of the services I would expect there. The
examples I will use are from draft-beck-opes-esfnep-01.txt, and are as
follows:
* Virus Scanning
* Insertion of Ad Banners
* Insertion of Regional Data
* Caching of Personalized/Customized Web Pages
* Content Adaptation for Alternate Web Access Devices
* Limited Client Bandwidth Adaptation
* Adaptation of Streaming Media
* Request Filtering
* Request Filtering through Content Analysis
* Creation of User Profiles
* Search Engine Index on Cached Web Pages
* Language Translation
Content Provider
===============
The reverse proxy at the content provider is the one machine completely
owned and controlled by the content provider. As such, it will be
completely open to accepting new rules from the web servers (along with the
content).
Likely candidates are:
* Insertion of Ad Banners
* Creation of User Profiles
* Search Engine Index on Cached Web Pages
* Language Translation
CDN Service
===========
The CDN Services (or set of CDN's in a peering relationship) are setup to
handle content for their customers (the content providers), and would
therefore MAY allow dynamic loading of rules from the content providers.
Likely candidates are:
* Insertion of Ad Banners
* Creation of User Profiles
* Search Engine Index on Cached Web Pages
* Language Translation
* Insertion of Regional Data
* Caching of Personalized/Customized Web Pages
* Content Adaptation for Alternate Web Access Devices
* Limited Client Bandwidth Adaptation
* Adaptation of Streaming Media
ISP
===
The ISP brings in several concerns - obviously for their own revenue (Ad
banners), and for services they could provide their customers (Virus
Scanning, Filtering, et al), but also for services they could provide
selected content providers (Bandwidth adaptation, Regional data, User
profiles, et al). However, since the set of content providers is not
controlled, it is likely they would want tight security on what modules can
be loaded dynamically and from whom - most likely they would only support
rules applied through administrative controls.
Likely candidates are:
* Virus Scanning
* Insertion of Ad Banners
* Insertion of Regional Data
* Content Adaptation for Alternate Web Access Devices
* Limited Client Bandwidth Adaptation
* Adaptation of Streaming Media
* Request Filtering
* Request Filtering through Content Analysis
* Creation of User Profiles
* Search Engine Index on Cached Web Pages
* Language Translation
Client
=====
Now the client's forward proxies (provided by the access location - a
company, local library, et al) are concerned only for the well being of the
users they are in front of, and will most likely not support added features
for the content providers.
Likely candidates are:
* Virus Scanning
* Caching of Personalized/Customized Web Pages
* Content Adaptation for Alternate Web Access Devices
* Limited Client Bandwidth Adaptation
* Request Filtering
* Request Filtering through Content Analysis
* Language Translation
Now these are my own thoughts and expectations of just what will be
happening on the request path, and I feel this is a good place to start and
gives us more of a context for later discussion. I would appreciate any
extra comments on this, especially if you feel that I have missed something.
Next, I would like to start addressing what restrictions and trust
relationships would need to be in place at each level, so we can make sure
the framework would support this behavior
Rob Erickson
Sr. Network Software Engineer
mailto:Rob(_dot_)Erickson(_at_)Intel(_dot_)com
503-712-2016