Re: OCP questions

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, 16 Apr 2003, The Purple Streak, Hilarie Orman wrote:

> On Tue, 15 Apr 2003 at 16:57:04 -0600 (MDT) Alex Rousskov announced:
>
> >  OCP Core does not forbid several OCP connection over one transport
> >  connection (bugs notwithstanding). OCP Core says, in part
> >  ("Connections" section, blob 87):
>
> >	   If BEEP over TCP is used, than a BEEP channel will correspond
> >	   to a callout connection, allowing callout connection
> >	   multiplexing over a single TCP connection.
>
> >  What made you think that "OCP forbids it"?
>
> These words:
>    For example, if raw TCP is the transport, than a TCP connection
>    will correspond to a callout connection.

which is true unless we want to add connection IDs to OCP. Without
explicit connection IDS it is not possible to have multiple OCP
connection over a transport connection that does not support embedded
"channels" or "sessions".

I would be happy to add connection IDs if needed, but it may be a good
idea to decide on the transport binding(s) first in case we decide on
a single binding that makes connection IDs unnecessary.

> >  OCP Core supports heartbeats via <i-am-here> and <are-you-there>
> >  messages. Those are actually very useful because OCP Core relies on
> >  timeouts to resolve possible problems with overloaded or
> >  malfunctioning agents and timeouts without heartbeats do not work well
> >  for "slow" adaptations.
>
> I think "heartbeat" generally means that a message every n time units is
> required - there's no "are you there".

Yes. OCP agents can implement heartbeat by sending <i-am-here>
messages at regular time intervals if desired. I do not see a need to
make that a default/required behavior though. Do you?

> >  > Reviewing the messages on this list, I find myself deeply uncertain
> >  > about what would be in "OCP/HTTP bindings".  Would it be an encoding
> >  > of the OCP protocol elements (transaction start, transaction id,
> >  > etc.) as HTTP-style headers?
>
> >  You may be confusing/mixing OCP transport binding and
> >  application-specific drafts. We have not decided on OCP transport
> >  binding. In theory, it can be HTTP like in ICAP. If that is the case,
> >  then either OCP Core (if there is only one transport binding) or HTTP
> >  Transport Binding for OCP (if there are multiple transport bindings)
> >  drafts will indeed document how to convert OCP protocol elements to
> >  HTTP elements.
>
> Then there are two distinct options being considered, as you say:
>
> 	1. A single transport for OCP.
> 	2. Multiple transports for OCP.
>
> If there is a single transport, then there will be a single document
> showing how to encode the OCP protocol elements into bitstrings carried over
> that transport.
>
> If there are multiple transports, then there will be a document for each
> transport showing how to encode the OCP protocol elements into bitstrings
> carried over that transport.  Those would be OCP/HTTP, OCP/RTP, OCP/TCP,
> OCP/BEEP, perhaps.  With other possibilties, such as OCP/SNMP. OCP/FTP,
> OCP/WEP, ....

Yes, that is exactly what I was trying to say. In case of a single
binding, there is probably no need for a separate "transport"
document -- everything transport-related can be integrated into OCP
Core.

> Lurking in the wings is the idea of a new transport, call it OCPTRAN for
> the moment (or "copper" :-) see later), running over one or more of
> TCP, UDP, IP, BEEP?, ...

Exactly :-)

> The OCP document as it stands now is a data model and state machine.  It is
> awaiting WG decision on the issue of transport.
>
> OK so far?

Yes, we are in agreement.

> One thing that might help with clarity is to note that we have been
> talking about using a Layer 4 transport as OCP transport sometime,
> but other times we are talking about using a Layer 5 protocols as an
> OCP transport.

I will add such a note to the Core draft.

> What bothers me is the issue of the nature of the proxied protocols
> and whether or not each one needs its own OCP binding.  We know that
> HTTP, with only minor modifications, can be the OCP transport for a
> proxied HTTP connection.  Can/should it be the OCP transport for
> FTP? For SNMP?  For telnet?  That possibility is what led to the
> awkward architecture for protocol conversion, using OCP transport X
> for requests and getting the reply back on transport Y!

I agree that proxied protocols may benefit from a particular OCP
transport. That would be the primary argument to support multiple
transports.

However, IMO, HTTP makes a very poor OCP transport regardless of the
proxied protocol. HTTP is simply not designed for that. I can provide
specific arguments if anybody cares to listen. I think ICAP suffers a
lot in clarity (and, perhaps even features/performance) due to an
unfortunate choice of transport.  Martin will probably disagree. I
think BEEP is a much better fit. I do not have a strong opinion about
this though (yet?).

> There are pros and cons here. Using a "native" callout protocol
> (HTTP over HTTP, SNMP over SNMP, RTP over RTP, etc.) is a quick way
> to get going - the person who knows the protocol can probably figure
> out a quick way to get the callout protocol implemented, the framing
> and other issues are simpler if you aren't changing protocols,
> libraries can be reused, etc.  The con is that the OPES processor
> may become bogged down with too many pieces of client-side code.
> There must be other issues.

I disagree that framing is simpler. I agree that learning curve is
less steep and that [good] libraries can be reused. I would address
the learning curve issue by selecting a very simple transport/encoding
model. I would address the code reuse issue by selecting a
well-supported (existing) or very simple (new) encoding.

> If there is only one transport protocol, then it may become
> complicated with too many features as it tries to encompass all the
> different framing methods, reliability issues, etc.

Or, it might be too simple to support some esoteric corner cases
efficiently. I would strive for the latter rather than designing a
transport "behemoth".

> My opinion is that if we decide on only one transport, that it *not*
> be tied to HTTP, that it be as lightweight as possible.

I agree. That is what makes raw TCP or perhaps BEEP attractive to me.

> (By the way, I'm in touch with someone who says he's got documented
> timings of the overhead involved in parsing a null XML message with
> standard commercial software - 30 times the effort of a simple TCP
> connection sending one byte back and forth; I'm trying to get his
> tech report).

I would be very interested to see this report because I am surprised
by the conclusion. Perhaps "standard commercial software" means
"unoptimized commercial software" (in which case I would not care much
-- general-purpose parsers can be slow and I bet the TCP stack they
used had been optimized many times).

> Personally, I think the best choice is a new transport named OCPTRAN
> that can run over TCP for data that needs reliable service and can
> also run over UDP or just IP if need be.  I'm not sure where BEEP
> fits in this taxonomy - it seems to be orthogonal (in the sense of
> "not a branch point" rather than "useless").

I hear you, but when I read
	http://www.clipcode.com/peer/beep_technical_whitepaper.htm
I feel guilty for not using BEEP and inventing yet another *TRANP. I
have not finished reading or digesting the paper though. If by "not a
branch point" you mean "we would still need to decide on BEEP
transport (BEEP over what)", then I agree.

> >  > I cannot keep myself from stumbling over "application message" time
> >  > and again.  And again.  The stuff between the OPES processor and
> >  > callout server that might be encapsulated data coming from or going
> >  > to the proxied transaction ... can that have an unambiguous name,
> >  > like "zinc", if there's nothing better?
>
> >  Except for section 1.1, there should be no mentioning of "proxied"
> >  anything. The fact that OPES processor is a proxy is out of OCP scope,
> >  and section 1.1 attempts to document that. "Application message" is
> >  whatever OPES processor and callout server what it to be, essentially.
> >  I would not like "zinc", but would very welcome better alternatives to
> >  describe an undefined (content, metadata) pair.
>
> Even if the draft doesn't refer to proxied data, the concept is still
> there, and "application message" will continue to seem ambiguous, to
> me, anyway.

Yes.

> How can you not like "zinc"?  OSERVICE-BLOB? OUTBOARD-SERVICE-DATA?

"Blob" is close. What do you call a blob tuple (metadata + data)?
Blot? Blop (for blob pair)? Plob (for pair of blobs?)

Alex.