ietf-openproxy
[Top] [All Lists]

Re: copying commitment and deadlock

2003-03-24 20:28:09

On Mon, 24 Mar 2003, The Purple Streak, Hilarie Orman wrote:

I started trying to read this thread and I find that I need a
summary of how we got here and what we are trying to accomplish.  I
can follow the details, but cannot tell why we are discussing what
seems a fairly complicated interaction.

We are discussing this for two reasons (see the first message
on this thread for details):

        - we need to decide when an OPES processor can
          get rid of the data that was previously marked
          with a [copied] flag (the semantics of the flag
          does not imply an efficient end-of-life moment for
          copies)

        - we need to decide how we can let callout
          server to get out of the loop without losing any
          uncopied data (commitment-based schemes are simple and
          fast but lead to deadlocks, other schemes are more complex
          and slower)

Both decisions must be documented in the callout protocol specs if
copying-related features are to be supported.

I'm uncomfortable about messages that implied that we are trying to
support a layer 7 switch architecture. If that's at the heart of
this, I'm dismayed.  If not, I don't know what's going on.

IIRC, the only suggestion relevant to L7 switching was that no copying
is necessary at all -- we could say that [the initial version of] the
callout protocol supports "move" and does not support "copy"
operations. L7 switch is just an example of an application-level proxy
that may not support "copy" operations. I have argued that "copy"
optimization is too valuable to get rid of.

I have a lot of trouble understanding the value of this if there's
anything other than "this is a copied stream" and "this is not a
copied stream".

This discussion exists because some of us consider copying
optimizations valuable (worth discussing and implementing) but those
optimizations raise questions that protocol needs to address.

Could someone provide a succinct description of the problem?

The first message on this thread describes both problems. The above is
a short summary. However, since I wrote both, it would be great if
somebody else can re-describe the problem for Hilarie in better words.
If there are no volunteers, we can just wait for the protocol draft to
be released this week; hopefully, it will clarify the problems.

Thank you,

Alex.