ietf-openproxy
[Top] [All Lists]

Re: AW: OCP transport nomination

2003-05-05 22:28:35


On Mon, 5 May 2003, Markus Hofmann wrote:

From the discussions so far, it seems that the functionality and the
features provided by BEEP mostly fit our needs. The main concern
seems to be about XML related performance and implementation
overhead. An option might be to use XML only for BEEP's channel
management. Would this address the performance concerns?

Probably not if my understanding of how to naturally map OCP to BEEP
is correct. A natural mapping would require creation of a separate
channel for any [meta]data that needs to be passed to the other OCP
agent, asynchronously or semi-asynchronously:
        - original application message data
        - original application message metadata
        - adapted application message(s) data
        - adapted application message(s) metadata

Ideally, we need one channel for each because, unfortunately, BEEP
does not allow mixing BEEP message frames from different BEEP messages
within one channel, and OCP needs to mix [large] data, [large]
metadata, and [small] control messages. We can reduce the mixing
requirements somewhat (e.g., by requiring that all metadata is known
before data is sent), but we would still end up with 2-3 extra
channels per OCP transaction.

If channel establishment is slow (because of XML or whatever), we have
a problem. The only way to solve this performance problem is to reuse
channels across OCP transactions. This is usually possible from BEEP
point of view (AFAIK), but makes the protocol more difficult to
understand and implement because you lose nice encapsulation of
channels within OCP transaction.


An alternative to channel reuse is an "unnatural" mapping to BEEP
that, essentially, does not use much of the BEEP core features (such
as message framing)  but rather re-implements them hidden from BEEP,
inside simple BEEP messages, to work around BEEP message exchange
limitations. Sort of like doing IP-over-IP encapsulation, I guess.

Are there other fundamental issues that would speak against using
BEEP and justify a new protocol (or suggest using another existing
protocol)?

Another fundamental issue FOR using BEEP is reuse of security-related
profiles (though Hilarie may disagree that there is enough to reuse).

Alex.