[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : RE : RE : draft-ietf-opes-ocp-core

Alex,
I think I wasn't clear in previous mail. Please see response below, I hope it will better explain my need.

> -----Message d'origine-----
> De : Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] 
> Envoyé : mardi 26 août 2003 19:31
> À : MITTIG Karel FTRD/DMI/CAE
> Cc : ietf-openproxy@xxxxxxx
> Objet : Re: RE : RE : draft-ietf-opes-ocp-core
> 
> 
> 
> On Tue, 26 Aug 2003, MITTIG Karel FTRD/DMI/CAE wrote:
> 
> > Altering the cache control header will work, but it could 
> lead to side 
> > effects.
> >
> > If you take the case when service's clients are subnetworks or 
> > enterprises with proxies on it, they wont be able to cache the 
> > response any more. In the same way, client application can 
> respect too 
> > closely zero TTL and re-send request very frequently. 
> Result will then 
> > be an increased load on your processor, and the benefits of caching 
> > unfiltered content will be loss.
> 
> My interpretation of the above is "application cache controls 
> may not be able to express what a particular OPES system may 
> want to express". For example, HTTP does not have enough 
> knobs to control caching at intermediaries separately from 
> caching by end clients while your OPES system wants to do 
> just that. Is this interpretation correct?
> 

Not exactly: my need is to be able to cache the OCP treatment applied, which should be independent of the application protocol and application caching information. See example below.


> Can you provide a more specific example that illustrates 
> inability of, say, HTTP Cache-Control modifications to 
> achieve your goals?
> 


Take an HTTP filtering service offered to 2 communities (for example high and low schools using a filtering service), each passing through the OCP processor. The aim of the service is to filter Internet access but with a different level for each community. Internet content can then be divided in 3 parts:
	- the content allowed&denied only for community 1 (say [E1])
	- the content allowed&denied only for community 2 (say [E2])
	- the content allowed&denied for communities 1 and 2 (say [I])

There are 2 ways to treat the problem:
	- The "simplest" one is to say that the service is different, so you provide 2 OCP processors calling 2 services (or the same service with different parameters). In this case, caching is not a problem, but this solution becomes costly because you double the equipments.
	- The second one is to say that the service uses a policy to know which treatment to apply depending of the client. In this case, there will only be one processor and one service, which is far more interesting. 

Normally, saying the processor can do HTTP caching, you will need to call the service after the caching process ("response post-cache" vectoring point) to avoid the cache storing a modified version which should only be send to community 1 or 2. You don't have in this case to modify cache control of responses, so it works fine.

The problem with this solution is that you will query your service for each incoming request (or indeed each outgoing response). If there are proxies in one community, you will then save corresponding cached responses, but it will be really hard to predict the gain.

If you want to make some optimization, you can see that [I] content could be cached by the processor. Or, this part can represent a lot of queries, saying x%, so allowing the processor to cache corresponding modified response will save x% load on your service.

But now, if you put your service before the caching process of your processor, the processor won't be able to distinguish between [E1]&[E2], even if it is able to store the 2 versions of responses, because it doesn't (and doesn't have to) know service policy. So the service has to tell processor not to cache this part. One way is to do this as you suggested by modifying the response using protocol parameters to say it is not cacheable.

The drawback in this case is that it has an impact on clients applications. If one community uses proxies, they wont be able to cache the responses any more. You will then increase the service load related to these responses to an unknown level (depending of the original TTL and the treatment required).

So the only way I see to be sure to gain those x% (which could be for some services around 80%) is to add a simple "is-cacheable" flag in OCP messages (without needing extended controls like application protocols provide).

Karel


> > But you're right, the problem is specific to some application 
> > protocols (and also some cases), so it can be address in 
> application 
> > bindings.
> 
> Agreed. This becomes are to-do item for HTTP OPES binding then.
> 
> Alex.
> 
>