ietf-openproxy
[Top] [All Lists]

Re: OPES protocol, pre-draft

2003-03-18 10:31:12

Oskar,

I think we may have a different implementations in mind. I am looking at web proxy server (surrogate, I just do not like this word) extended by OPES capabilities. For this model storing all incoming data is not a problem - disks are large and cheap, and storing data is very natural behavior for the system build around cache engine.

Even in this case you cannot assume to always being able to buffer the entire object - even the largest caches run out of disk space at some point and need to do some sort of cache replacement and conserve disk space. Even more, in case of streaming caches you might end up doing prefix caching, i.e. not having stored the entire object, but only the prefix of an object.

The point is that we must not require a specific implementation, but that our protocol should support various forms of implementations. I agree that buffering capacity is of less importance in the model you've described above, but the protocol should also support other forms, and as such I still see value in allowing the OPES processor to not buffer the entire object (meaning there seems to be value to having the [copied] flag.

Correct me if I'm wrong, but it looks like you have in mind something like layer 7 switch. Such devise may have better throughput but very limited storage capabilities. Main differentiator is ability to keep data on disk. Hybrid devices are also possible, e.g. solid state cache. More interesting hybrid is L7 based OPES processor combined with cache farm.

Yup, that's one possible implementation form our protocol should support.

I suppose that buffering policy will depend mostly on the device type. OPES processor with disk will store all intermediate data and use it's caching capabilities to enhance overall performance. L7 switch based device will tend to be very conservative on storage use and may need to exploit protocol capabilities for copy control.

Yup, and that's why I believe the callout protocol should *not* require the OPES processor to always store the entire object.

To support all these needs we may do several things:

1. Dynamic (per-message) control, like in current proposal.
2. Stateful protocol with storage policy negotiated at handshake.
3. Different level of protocol implementation with device capabilities announced (but not negotiated) at handshake. I thing protocol should support all 3 policies. This may significantly simplify implementation of cache-based OPES processors.

I agree that the protocol should support different forms of implementations, but I'm not yet convinced that policies need to be negotiated "at handshake". With the current proposal, the OPES processor can dynamically decide what to buffer and what not, indicating this to the callout server via the [copied] flag. This seems pretty flexible. Is there a specific scenario that cannot be solved with that approach?

-Markus