Subject: OCP questions

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 15 Apr 2003 16:19:26 -0600

I've been going over the callout protocol requirements and OCP, and
find them in generally good agreement.  I don't fully understand
the requirements, though and have a couple of questions about them
and OCP.

First, I know I asked about whether or not a transaction was supposed
to be kept on a single connection, but I cannot find my question or
the answer in any archive, so, annoyingly to everyone, including
myself, I need to ask again.

If I am reading things correctly, the requirements allow several
"connections" over one transport connection, but OCP forbids it.
Is there disagreement?  If not, which notion is correct?

The requirements mention "keep-alives" and "heartbeats".  Was there
any intent to require heartbeat support?  OCP does not use them,
which is fine with me.

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?  In order to allow someone to write an Apache
module for OCP and make use of the HTTP header parsing libraries, for
example?  And bring in all the baggage about chunking?  If so, we need
to state this somewhere, and say why we are doing this, rather than
defining protocol-independent bindings.  The "application agnostic"
stuff seems to lead one to expect protocol-independent metadata.  This
is why I am deeply confused.  Further, if there is a truly application
independent encoding, say, for mime parts, then why not just use this
as the single encoding?  At one time it was very important to use
HTTP bindings for this code reuse purpose, but I'm not sure that is
still the case.  Can we document a decision on this point?

OCP's negotiation section hints at a rich set of operations; do
we need more than the usual "here's my menu" and "here's my selection
from your menu" ?

I confess to not understanding the big diagram in OCP; it may be an
elegant way to convey information, if I only understood it.  Where are
the "data have" messages?  Are those "OCP messages" in the last box?
What are "connection C" and "connection G" ?

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?

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 15 Apr 2003 16:57:04 -0600 (MDT)

On Tue, 15 Apr 2003, The Purple Streak, Hilarie Orman wrote:

> First, I know I asked about whether or not a transaction was
> supposed to be kept on a single connection, but I cannot find my
> question or the answer in any archive, so, annoyingly to everyone,
> including myself, I need to ask again.

IMO, the requirements draft semi-implies that a single transaction
cannot cross connection boundaries. OCP Core follows the same
principle though we need to explicitly document this fact (added to
the todo list).

OCP Core will allow certain OCP messages with xid to be sent on
several connections to support fast-abort and similar optimizations
(you may recall a thread about it on this list). The latter feature is
the "fast track" item on the todo list.

> Is there disagreement?  If not, which notion is correct?

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"?

> any intent to require heartbeat support?  OCP does not use them,

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.

> 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.

On the other hand, if OCP transport binding is, say, BEEP, then there
is no need to convert OCP protocol elements to HTTP elements. There is
a need to document how OCP protocol elements are encoded within BEEP
channels, of course.

> In order to allow someone to write an Apache module for OCP and make
> use of the HTTP header parsing libraries, for example?  And bring in
> all the baggage about chunking?  If so, we need to state this
> somewhere, and say why we are doing this, rather than defining
> protocol-independent bindings.  The "application agnostic" stuff
> seems to lead one to expect protocol-independent metadata.  This is
> why I am deeply confused.  Further, if there is a truly application
> independent encoding, say, for mime parts, then why not just use
> this as the single encoding?  At one time it was very important to
> use HTTP bindings for this code reuse purpose, but I'm not sure that
> is still the case.  Can we document a decision on this point?

I may have mentioned that before, but I think we need to decide on OCP
transport binding(s?) first. Once we know the transport, we would be
able to decide how to document OCP encodings. Or, at least, the two
decisions (transport and encoding) should be done simultaneously
because some high-level transports (e.g., HTTP) have strong influence
on encodings.

Answering this question will make OCP much more clear for people who
need message syntax before they can understand a protocol (the
majority of practitioners, I guess).

> OCP's negotiation section hints at a rich set of operations; do we
> need more than the usual "here's my menu" and "here's my selection
> from your menu" ?

We are waiting for Reinaldo Penno to give us an answer. You can ignore
negotiation messages until then.

> elegant way to convey information, if I only understood it.

It simply shows incapsulation of protocol elements (boxes within
boxes). As I said in release notes, I am not particularly happy about
it either. Better rendering ideas or examples are more than welcome!

> Where are the "data have" messages?  Are those "OCP messages" in the
> last box?

Yes, data-have message is an OCP message.

> What are "connection C" and "connection G" ?

Two [partially concurrent] OCP connections.

> 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.

HTH,

Alex.

---

From: jfcm <[email-masked]>
Date: Wed, 16 Apr 2003 12:18:45 +0200

>majority of practitioners, I guess).

I happen to be one of the few needing a model first.
Just to know what we are talking about: it may help.

Most of the points risen here would get a clear response with a simple 
diagrams such as :

http  | data input | dispatcher | call-out protocol | server | call-out 
protocol | data-output | http
<------ OPES ?
         <------ OPES ?
jfc

PS. What about protocol conversion, is that OPES?

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 16 Apr 2003 07:22:43 -0600 (MDT)

On Wed, 16 Apr 2003, jfcm wrote:

> Most of the points risen here would get a clear response with a
> simple diagrams such as :
>

We already have/had such diagrams. Obviously, they did not provide
enough "clear responses". Note that OCP has nothing to do with "http |
data input |" and "data-output | http" parts. OCP Core has specific
wording about that. That wording replaced some of the figures that had
those parts in earlier OCP Core versions.

> PS. What about protocol conversion, is that OPES?

It can be. An application proxy that does protocol conversion may
support OPES mechanisms and may be OPES-compliant. A decent HTTP proxy
today has to convert between HTTP and FTP (or even Gopher, WAIS,
etc.). I do not see why OPES proxies should be more limited than
existing HTTP proxies. If OCP is involved in protocol conversion, OCP
agents would have to negotiate/agree on how to specify
original/adapted protocols via application message metadata.

Alex.

---

From: jfcm <[email-masked]>
Date: Wed, 16 Apr 2003 16:10:34 +0200

>                            <--- OPES ?

>enough "clear responses".

hmmm... This is your opinion which translates into some's difficulty
to understand where we are.

If OPES is defined as the first possbility, http is part of it and call-out
may take it into account. If it is defined the second way, external
protocols are no part of OPES but OCP can consider knowing it. If it
is the third definition (that I thought you would add by yourself in
your response to illustrate the difficulty), then the call-out protocol
has NO relation with the entry protocol.

>Note that OCP has nothing to do with "http |

Seems that this wording does not prevent questions. May be
both could be kept? We could check they fit the different
understandings.

>original/adapted protocols via application message metadata.

At a given stage one must start saying what an OPES is and is not.
And stop saying "it can be".

IMHO it CANNOT be a protocol converter if it is not related to the
entry protocol (but the use of different I/O protocol will [affirmative
mode] make it a part of a protocol conversion system).

This will have an impact on OCP. The protocol sequence is then:
http > call-out > smtp.

jfc

>Alex.
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/03

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 16 Apr 2003 09:51:35 -0600 (MDT)

-- was "Subject: OCP questions"

jfc,

	You keep mixing OCP and OPES which makes it very awkward (for
me) to respond. The "OCP questions" thread you responded to was about
OCP. OCP Core is application-agnostic and, hence does not care much
about proxied protocols, their conversions, etc.

	I took the liberty of renaming your Subject line. If you want
to polish or completely change OPES definition, PLEASE stay on this
new thread and make specific suggestions here. If you want to discuss
OCP Core draft instead, please use existing OPES architecture and the
old thread (or start a new one). I understand that OCP depends on OPES
architecture, but OCP thread is not about OPES in general, it is about
OCP. This new thread can be about what OPES is or should be.

	Specific OPES-related comments are inlined.

> to understand where we are.

What I said is not an opinion. It is a fact. We had very similar
diagrams in OCP Core (e.g., see section 2.1 "2.1 OCP environment" in
version head_sid3 of the OCP Core draft [1]) and, since people keep
asking questions, they did not get us "clear responses" you promise.

[1] http://www.measurement-factory.com/tmp/opes/snapshots/head_sid3/ocp-spec.html#section_ops-environment

> If OPES is defined as the first possbility, http is part of it and
> call-out may take it into account. If it is defined the second way,
> external protocols are no part of OPES but OCP can consider knowing
> it. If it is the third definition (that I thought you would add by
> yourself in your response to illustrate the difficulty), then the
> call-out protocol has NO relation with the entry protocol.

I do not know what "possibilities" you are talking about. Are they
related to the arrows on your diagram? Care to define them explicitly?

> Seems that this wording does not prevent questions. May be both
> could be kept? We could check they fit the different understandings.

By "both", do you mean the old figure and the new wording?

> At a given stage one must start saying what an OPES is and is not.

OPES is about many specific things. If you keep asking specific
questions ("Is OPES about Foo"), you will keep getting specific
answers ("OPES can be about Foo", but it can also be about "Bar").

> And stop saying "it can be".

I was just answering your question! OPES, regardless of the
definition, can be many things. It is OK to say "OPES is about
protocol conversion", but since OPES is also about other things, it is
more accurate to say (IMO) that "OPES can be about protocol
conversion". That is, "protocol conversion" is within OPES scope.
The latter is the best wording, I guess.

> entry protocol

OPES _is_ related to the input/entry protocol. We even plan
input/output protocol-specific drafts, possibly one per proxied
protocol!

> (but the use of different I/O protocol will
> [affirmative mode] make it a part of a protocol conversion system).

Do not know what you mean by "I/O protocol".

> This will have an impact on OCP. The protocol sequence is then:

The above is not how callout protocol is now defined. Callout is
something that comes back:

	(http) <--> OPES processor <--> (ftp)
	             ^
	             |
	             V
	          (callout)

Alex.

---

From: jfcm <[email-masked]>
Date: Wed, 16 Apr 2003 19:27:23 +0200

I just think in simple ways:
- Yes/No.
- layers by layer implications
- logical models
- what has not been approved by consensus is not accepted

>about proxied protocols, their conversions, etc.

The thread I followed was questions on that.

>OCP. This new thread can be about what OPES is or should be.

The OPES is NOT defined enough for the OPC Core not to be affected.
At this stage I saw no concensus call on anything yet. Or did I
miss something?

> > > > <------ OPES ? possiblity 1
> > > >          <------ OPES ? possiblity 2
> >  >                            <--- OPES ? possibility 3
> >
>[1] 
>http://www.measurement-factory.com/tmp/opes/snapshots/head_sid3/ocp-spec.html#section_ops-environment

Since people still keep asking questions I suggest that you keep both the 
diagram and the explaination. This may help to understand. So we may also 
see if the diagrams are good enough and if the explanations match the 
diagram. Modelization is the first step, but it is also an iterative process.

>related to the arrows on your diagram? Care to define them explicitly?

I am discussing a diagram where three possibitilities are shown
with a question mark. For your convenience I added the wording
"possiblity #".

>By "both", do you mean the old figure and the new wording?

Yes. As discussed above. Even is things are the same in your mind, either 
they will present the same thing and they will help understanding, or they 
may present different things and will help indifying misunderstandings.

>answers ("OPES can be about Foo", but it can also be about "Bar").

This should not be the case. If you work out a, OPES diagram; you
will have I/Os and you will phrase OPES in a mathematical way as
a function (or group of functions). That function(s) will be clearly
understood if it is clearly and afirmatively described in a generic way.

If the I/O of the OPES black-box are data flows under protocols, then
OPES may relate to protocols, if not they will not. This is what a
diagram will permit/help you to see easily.

>The latter is the best wording, I guess.

No. As everything generic OPES can only carry what they have
beend defined to carry. Some implementations could do more,
they could also participate into some other process. But generic
OPES will do all what they are expected to do if they are well
designed, and no more (otherwise they would have been ill defined
or would cost too much to develop for the expected return).

>input/output protocol-specific drafts, possibly one per proxied

You "plan". This is "possibly". IAB said it is related to http.
To be realted to more you have two options:

- to draft as many OPES systems with impact on OPC
- to make them independent from the I/O protocol (possiblity
   2 or better 3 aboe), leaving that aspect to a protocol interface
   able to relate with such OPES systems.

I do prefer that last approach in one architecture (dispatcher centric).
I do not in the other architecture (daisy chaining). When you say
that OPES "can be both" you do not help me deciding.

We are here talking specifcally of the OPC Core. And in a
dispatcher centric architecture I think the callout protocol is the
center of the whole OPES system; while in the daisy chain
architecture If feel it is quite of no interest.

>Do not know what you mean by "I/O protocol".

Protocol used to input or output the data. The same
wording as you, just above.

>         (http) <--> OPES processor <--> (ftp)

Thnak you for the draft/ So you can see that that the sequence
of the data path is http > (dispatcher) call-out (server) call-out >
(dispatcher) > ftp.

So if you only keep protocol, the protocol sequence is what
I indicated. It permits to see that - unless protocols conversion
or continuity relies on stored information every meta info in
the input protcol must be transported in the call-out protcol.
So the OPC is I/O protocol dependent and new versions can
be specified on I/O protocols basis.

Or OCP supports enough information to be mapped into many
protocols. Then all the protocols one can interface are OPES
acceptable.

This makes two totally different architectures and ways to
consider OPES.
jfc

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 16 Apr 2003 15:05:51 -0600

OPES is not going to do protocol conversion.  An OPES-like architecture
could, at some point, define the processing points and control messages
for this kind of functionality, and I hope that someday we'll get there,
but I doubt that it will be in a WG called OPES.

You make a good point in observing that if OPES did protocol
conversion, then the notion that the callout protocol is the encoded
in the proxied protocol becomes confused - callout transactions would
logically use protocol X in one direction and protocol Y in the other.
And further, we'd have to think through several issues about matching
names, authentication methods, connection initiation to endpoints,
etc. that just didn't come up when we did the architecture.

Of course, someone might be able to do some protocol conversions using
OPES and a single protocol encoding for the callout protocol.  That's
fine and good, I'm sure the framework we are developing will support
more uses than we directly address.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 16 Apr 2003 15:43:11 -0600 (MDT)

Short summary/conclusion for those that do not want to read the whole
thing:

	jfc,

	I am still not sure what exactly you are objecting to (if
	anything). Would it be possible for you to summarize your
	position in a stand-alone statement _and_ propose specific
	changes to any of the existing drafts? This will ensure
	that we, eventually, have consensus.

	If you are not objecting to or suggesting anything specific
	but are rather asking questions, you may want to re-post
	a set of specific questions that are still not answered
	(but it is impossible to guarantee that every question
	 can be answered to one's satisfaction, of course).

Detailed responses are inlined below.

> The OPES is NOT defined enough for the OPC Core not to be affected.

Maybe, but that does not prevent me working on OCP Core. If OPES
definition changes, I can adjust OCP Core as needed. I do not
anticipate significant OCP changes, regardless of what this discussion
does to OPES definition. Thus, I do not think I am wasting my time.
IMO, those who think the changes will be significant should
concentrate on OPES definition/scope first (and leave OCP alone, for
now).

> At this stage I saw no concensus call on anything yet. Or did I miss
> something?

I consider published WG drafts (most important ones are already
approved as RFCs) as consensus. This does not imply that no changes to
those drafts are allowed, of course. It just raises the bar for making
those changes.

There is currently a consensus call for the OCP Core draft to become a
WG draft. So far, there has been no specific objections I am aware of.
We have discussed a few changes that have already been implemented.

> Since people still keep asking questions I suggest that you keep
> both the diagram and the explaination. This may help to understand.
> So we may also see if the diagrams are good enough and if the
> explanations match the diagram. Modelization is the first step, but
> it is also an iterative process.

OK. I will try to resurrect the diagram while trying to avoid
now-undefined terms such as "input and output protocol". The problem
is that this kind of diagram/text does not really belong to OCP. OPES
Architecture or another document should address the scope of OPES
components and their interaction. It is wrong to spend so much effort
on documenting what OCP is NOT, especially in the OCP Core draft.

> with a question mark. For your convenience I added the wording

Please provide textual definitions. It is virtually impossible (for
me) to discuss definitions that have no textual representations. [ If
you want to use a formal model, that's fine with me to, but the
current diagram is not a formal model because its elements and symbols
are undefined. ]

> will have I/Os and you will phrase OPES in a mathematical way as a
> function (or group of functions). That function(s) will be clearly

I cannot make such a diagram or a set of mathematical functions that
would completely define OPES and raise no further questions. If you
can, you should do that and we will discuss the result.

For me, OPES system is simply an intermediary that obeys certain rules
(e.g., tracing and bypass), that adapts proxied traffic, and that may
use OCP to facilitate adaptations via callout servers.

> diagram will permit/help you to see easily.

OPES relates to protocols being proxied. Do you think otherwise? If
not, I do not think anybody else does, so we still have consensus,
which is already documented in the architecture draft.

> or would cost too much to develop for the expected return).

And why this is a "No"? I see no contradiction between the above two
paragraphs. Some OPES systems can do protocol adaptation. Some cannot.
Both kinds of systems are OPES as long as they (intend to) obey OPES
rules.

> > > IMHO it CANNOT be a protocol converter if it is not related to the

It is related. I have heard no opinions suggesting otherwise.

> IAB said it is related to http.

Correction: IAB (RFC 3238) does not refer to HTTP in any normative
            context.

> You "plan". This is "possibly".

These are not the only two options. The approach I am advocating is to
have one generic (application agnostic, independent from the I/O
protocol) OPES Core and several application-specific bindings or
mappings of that core. OCP Core is a part of OPES Core. So are OPES
tracing and OPES bypass drafts (or whatever they end up being called
when/if merged). We will have different tracing mapping/support in
HTTP and, say, RTSP, because those protocols are so different.

> that OPES "can be both" you do not help me deciding.

IMO, OPES can be used in both architectures. I am not sure what you
are deciding about, but I am sorry if I cannot help you.

> architecture If feel it is quite of no interest.

Fine(*). Is that a problem? I do not see anything wrong with a
particular OPES component being useful in some environments and not in
other environments. OCP is a MAY for OPES. Like caching is a MAY for
HTTP.

	(*) though it is impossible to verify your "no interest"
	assertion without having definitons of "dispatcher centric"
	and "daisy chain" architectures

> Thnak you for the draft/ So you can see that that the sequence of
> the data path is http > (dispatcher) call-out (server) call-out >
> (dispatcher) > ftp.
>

_Every_ metainfo? I do not see how is that implied. The exact protocol
conversion/mapping functions are undefined by OPES; it is perfectly
fine, in general, to alter meta information (adapt it), including a
case where all information is deleted (SMTP black hole for SPAM).

> be specified on I/O protocols basis.

OCP Core is independent of proxied protocols. There will be specific
application bindings for specific "application messages".

> Or OCP supports enough information to be mapped into many protocols.
> Then all the protocols one can interface are OPES acceptable.
>
> This makes two totally different architectures and ways to consider
> OPES.

And I want to support both by separating application-independent Core
from application-dependent bindings.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 16 Apr 2003 16:18:54 -0600 (MDT)

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

> OPES is not going to do protocol conversion.  An OPES-like
> architecture could, at some point, define the processing points and
> control messages for this kind of functionality, and I hope that
> someday we'll get there, but I doubt that it will be in a WG called
> OPES.

I think you gave a premature answer. If OPES is to support HTTP, then
OPES processors will have to participate in protocol conversion (HTTP
-> FTP) because an HTTP proxy has to do that. In fact, any existing
HTTP proxy that supports ftp:// URLs is, essentially, an OPES
processor. It adapts application messages that it proxies! Have you
ever thought about what happens when your browser sends

	GET ftp://ftp.example.com/pub HTTP/1.0

through an HTTP proxy? ftp.example.com does not talk HTTP on port 21
and does not know about HTML. Yet, your browser gets an HTTP response
with a nicely formated directory listing in HTML. Magic?

Note that I am not saying that OCP has to be involved.

> in the proxied protocol becomes confused - callout transactions
> would logically use protocol X in one direction and protocol Y in
> the other. And further, we'd have to think through several issues
> about matching names, authentication methods, connection initiation
> to endpoints, etc. that just didn't come up when we did the
> architecture.

I think you are finding complications when none exist. At least not at
the OCP Core level. Look at the way application message is currently
defined in OCP Core. There is no place for [additional] confusion,
even if protocol conversion is done via callout servers. The [proxied
protocol (or protocols) do not exist at the OCP Core level!

> Of course, someone might be able to do some protocol conversions
> using OPES and a single protocol encoding for the callout protocol.
> That's fine and good, I'm sure the framework we are developing will
> support more uses than we directly address.

True.

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 16 Apr 2003 17:44:18 -0600

Proxies do lots of things that OPES will not specify.  Some are so
heinous that I'll not even mention them.  And no, I don't believe they
use magic, but your question shows an admirably open mind.

Hilarie

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 16 Apr 2003 19:17:27 -0600

>  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. 

>  malfunctioning agents and timeouts without heartbeats do not work well

I think "heartbeat" generally means that a message every n time units is
required - there's no "are you there".

>  drafts will indeed document how to convert OCP protocol elements to

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, ....

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?, ... 

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?

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.  

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!

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.

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.

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.  (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).

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").

>  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.  How can you not like "zinc"?  OSERVICE-BLOB?
OUTBOARD-SERVICE-DATA?

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 16 Apr 2003 23:31:21 -0600 (MDT)

>    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.

> 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?

> OCP/BEEP, perhaps.  With other possibilties, such as OCP/SNMP. OCP/FTP,

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.

> the moment (or "copper" :-) see later), running over one or more of

Exactly :-)

> awaiting WG decision on the issue of transport.

Yes, we are in agreement.

> 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.

> 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.

> 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".

> 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.

> 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.

---

From: jfcm <[email-masked]>
Date: Thu, 17 Apr 2003 11:53:46 +0200

I think I agree with most of this and accept most of the pending points.

I only feel that simplicity/complexity will depend on the modelization 
defining where OPES boarders are. If you include all the possible plugs it 
may have to use in the design of a device, you will get a more complex 
device. And you will not be sure it can be used worldwide. If you get it a 
transformer and make it frequency indepedant you have probably more 
chances. But you need to get local converters.

>transport (BEEP over what)", then I agree.

Would you be so kind to give us a brief on your finding/feeling when
you are finished. I think it might help (me/us?) a lot. Thank you.
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 10:48:37 -0600 (MDT)

BEEP is a good candidate for OCP transport. Here are a few major
arguments for/against using BEEP as OCP transport. I hope that
Marshall Rose can review this and offer his insight both as BEEP
author and as a co-author of a syslog protocol build on top of BEEP.

	1. BEEP exists but is new

	   BEEP Core specification is a stable "Standards Track" RFC.
	   However, only few protocols over BEEP have been documented
	   and, as far as I can tell, none are super popular yet.
	   This means that we do not need to reinvent the wheel, but
	   we may also find yet-unknown problems with the existing
	   wheel design.

	2. BEEP uses XML

	   If we choose BEEP, any compliant implementation
	   would have to parse XML elements. BEEP documentation
	   asserts that many great XML libraries exist, some
	   optimized for performance. While I agree, I also assert
	   that most (if not all) of the existing libraries are
	   usually not suitable "as is" for a given decent-size
	   project that is concerned with efficiency,
	   portability and/or licensing restrictions. I do not see
	   much MIME code reuse in HTTP implementations and I expect
	   the same to be true about similar XML-based protocols.

	   Using BEEP for OCP essentially implies that every OPES
	   processor or callout server will have to include an
	   XML library. Unless we think that this is already the
	   case for 90% of implementations that will support
	   OCP, we should think twice about this new burden.

	   On the other hand, we could try to make OCP/BEEP less
	   extensible but also less XML-dependent by mandating or
	   recommending semi-fixed structure of required XML elements.
	   Parsing or generating such elements would be simple
	   and possible without any XML library. This kind of violates
	   protocol boundaries (though BEEP appears to do similar
	   things when it limits XML to exclude entity references).

	3. BEEP is connection oriented

	   Some suggested that there should be OCP transport
	   that can run on top of UDP or even raw IP. Selecting
	   BEEP would then imply that we need two transport
	   protocols because BEEP cannot run on top of UDP.

	   However, lossy protocols such as UDP or raw IP are
	   prohibited by OCP requirements draft. Moreover,
	   no arguments have been made (yet) to justify
	   the need for a lossy transport.

	   Moreover (Marshall, please do not read this sentence),
	   it is probably technically possible to implement
	   BEEP on top of UDP to preserve the same high-level
	   semantics. One would essentially have to define what
	   to do when a UDP or IP packet is lost and implement
	   congestion avoidance. I hope we do not have to do
	   this ugly hack though.

	4. BEEP exchange styles are close fit, but not perfect

	   BEEP requires replies to every BEEP MSG. OCP does not.
	   We can add "null" replies, of course, but the
	   protocol does not need them (it would be a waste from
	   technical point of view).
	   Some might argue that mandatory replies will actually
	   make OCP easier to understand.

	   I wonder why BEEP assumes that replies must be required
	   (being so flexible in other aspects), but it is
	   probably too late to change that assumption. Can BEEP
	   exchange styles be extended? Probably not without
	   losing compatibility with existing BEEP libraries.

	5. BEEP Core does not determine transport

	   We would still have to decide whether OCP runs
	   on top of BEEP/TCP only or allow other BEEP
	   transport bindings.

	6. BEEP Core does not determine encoding

	   We would still have to decide how to encode OCP
	   messages. BEEP defaults to application/beep+xml,
	   but other MIME types can be used.

	7. BEEP channels allow simple low-overhead OCP connections

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 11:05:59 -0600 (MDT)

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

> also run over UDP or just IP if need be.

If the group is convinced that designing a new transport is a good
idea, one way to proceed is to take BEEP, remove its XML dependency
(unless we choose to use XML for OCP messages) and remove mandatory
responses. Doing just that will allow us to reuse a lot of existing
documentation (and even code). Hilarie, could you please try to
convince us that new transport is needed assuming no UDP support is
required?

Hmm... The above can be rephrased in a more direct way, I guess:
Hilarie, what is wrong with BEEP, assuming no UDP support is required?
Once we know what is wrong, we can see what it would take to fix it.

If the group is further convinced that unreliable transport support is
needed, I would suggest that we add lossy transport support to the
above. Hilarie, could you please try to convince us that unreliable
transport support is required? More specifically, what kind of
application protocols cannot be adapted with OCP/TCP using a
reasonable set of OCP transaction timeouts to accomodate slow callout
servers or bad connectivity to them?

Thank you,

Alex.

---

From: Marshall Rose <[email-masked]>
Date: Thu, 17 Apr 2003 10:28:20 -0700

as requested by alex, i'll reply.
    
> 	   we may also find yet-unknown problems with the existing
    
i think your greater risk in terms of whether you can find a library you
like or whether you have to role your own.
    
experience with reliable syslog shows that the libraries out there are
"too general" for what syslog implementors want. unfortunately, those
implementors found that out the hard way, i.e., they invested a lot if
using a library instead of just rolling their own implementation.
    
further, some of the non-commercial libraries out there are GPL'd, which
many open-source and commercial implementors reject because of the
down-stream constraints it places on their code. (it was a bit of an
eye-opener to hear that even the open-source guys think this way.)
    
the choice of whether you use a library or roll-your-own all comes down
to "cost", which includes things like price (free or not), but also
includes things like the integration cost (e.g., same language, same
threading model, required libraries, etc.)

certainly many of the reliable syslog implementors i've talked to feel
they would have been better served by rolling their own...

> 	2. BEEP uses XML
    
xml is mandatory in beep for channel management, that's it. the subset
that of xml that beep uses means that you can take something like expat
and easily integrate it.
    
for an ocp channel, you can use any format you want. beep doesn't
care. it gives you an 8-bit clean container. after that, it's up to you.

> 	3. BEEP is connection oriented

the only protocol i've ever seen that had a reason for being both CO and
CL is the DNS, and even then, the kind of transactions being used by the
DNS for CO and CL vary dramatically.
    
if it makes sense to use ocp in a CL mode, don't consider beep. do
something else.

> 	   make OCP easier to understand.

the reason why MSG's get a response is because until you see the
response, you never know if the the MSG actually got to the other side
and got worked on. ultimately, it's the application, and not the
transport, that's responsible for things like that (cf., Clark, etc.).
    
if you want to do some kind of streaming thing in OCP, you can look at
the way syslog reliable does it. darren came up with that and it's
fairly elegant.

> 	   losing compatibility with existing BEEP libraries.

you'd need to define a beep feature negotiation to do that.

> 	   on top of BEEP/TCP only or allow other BEEP

realistically, does something besides TCP have any significant presence?

> 	   but other MIME types can be used.

true. see my answer to (2) above.

> 	7. BEEP channels allow simple low-overhead OCP connections

i'm not sure what this means. if you take a look at the xmlconf stuff,
they have a specialized application which requires multiple parallel
running in the same authentication context. they use beep for that.
    
even if you don't have the multiplicity requirement, using beep means
you never have to screw around defining authentication/privacy stuff,
because beep comes with sasl and/or tls.
    
if you find yourself defining a protocol that has a lot of
administrative overhead (e.g., negotiation, security, etc.), then odds
are you should have looked at beep before specifying all that stuff.
    
however, you should always use the best tool for the job. if beep is
overkill, don't use it.
    
/mtr

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 12:22:09 -0600 (MDT)

On Thu, 17 Apr 2003, Marshall Rose wrote:

>     i think your greater risk in terms of whether you can find a
> library you like or whether you have to role your own.
>
>     experience with reliable syslog shows that the libraries out
> there are "too general" for what syslog implementors want.
> unfortunately, those implementors found that out the hard way, i.e.,
> they invested a lot if using a library instead of just rolling their
> own implementation.
>
>     further, some of the non-commercial libraries out there are
> GPL'd, which many open-source and commercial implementors reject
> because of the down-stream constraints it places on their code. (it
> was a bit of an eye-opener to hear that even the open-source guys
> think this way.)
>
>     the choice of whether you use a library or roll-your-own all
> comes down to "cost", which includes things like price (free or
> not), but also includes things like the integration cost (e.g., same
> language, same threading model, required libraries, etc.)
>
> certainly many of the reliable syslog implementors i've talked to
> feel they would have been better served by rolling their own...

I share this experience in other protocols/areas. There are just to
many variables to find a good fit between a general-purpose protocol
library and a decent-size project. This is why I am also concerned
with XML!

> > 	2. BEEP uses XML
>
>     xml is mandatory in beep for channel management, that's it. the
> subset that of xml that beep uses means that you can take something
> like expat and easily integrate it.

... if you already use C language, do not have performance or memory
management problems with expat ways of doing things, and are OK with
MIT license. This is actually what surprises me about the XML choice
for BEEP Core -- its use is so limited that it is hard to justify!

If somebody takes a shortcut in supporting the XML part of BEEP, it
would be trivial to prove that their implementation is not OCP
compliant by sending an "interesting" (difficult to parse but valid)
XML element as a part of a channel management routine. Thus, we would
either have to close our eyes on this problem and test with simple XML
elements only, or we would have to acknowledge that many (most?) OCP
implementations are not really compliant. Not a nice choice.

The same can be said about MIME, I guess. Most HTTP implementations
fail to parse at least some "interesting" MIME-like headers
(quotations, escapes, multiple lines via LWS, etc.). This is really
unfortunate and does lead to compatibility problems long-term.

What do you think about documenting an even simpler XML subset and
recommending (requiring?!) its use within OCP/BEEP? Would that help at
all? Did you consider that option when designing BEEP?

> care. it gives you an 8-bit clean container. after that, it's up to

Yes; I should have stated that in the original summary.

> the only protocol i've ever seen that had a reason for being both CO
> and CL is the DNS, and even then, the kind of transactions being
> used by the DNS for CO and CL vary dramatically.
>
> if it makes sense to use ocp in a CL mode, don't consider beep.
> do something else.

I should have said "BEEP is a lossless protocol". However, your DNS
comment is important. Let's wait for Hilarie to drive that lossy
transport argument.

> transport, that's responsible for things like that (cf., Clark, etc.).

Yes, that is why the always-respond restriction in BEEP seems out of
place. Some applications (like OCP) do not care whether certain OCP
messages are already being worked on (a pipeline model).

> if you want to do some kind of streaming thing in OCP, you can look
> at the way syslog reliable does it. darren came up with that and
> it's fairly elegant.

Do you mean a stream of ANS frames, with optional in-frame aggregation
of syslog messages? Aggregation aside, that seems like the only sane
way to do "streaming" or "pipeline" with BEEP. I kept the same
approach in mind when considering OCP over BEEP. Or are you talking
about something else?

I would not recommend using aggregation trick with OCP though.

> > 	   Can BEEP

Interesting point!

> realistically, does something besides TCP have any significant presence?

No, unless Hilarie manages to convince the group that lossy transports
such as UDP must be supported (which would create its own problems
because BEEP cannot run on top of UDP as-is).

> i'm not sure what this means. if you take a look at the xmlconf
> stuff, they have a specialized application which requires multiple
> parallel running in the same authentication context. they use beep
> for that.
>     even if you don't have the multiplicity requirement, using beep
> means you never have to screw around defining authentication/privacy
> stuff, because beep comes with sasl and/or tls.
> administrative overhead (e.g., negotiation, security, etc.), then
> odds are you should have looked at beep before specifying all that
> stuff.

I agree. #7 is a "for BEEP" argument. BEEP channels are a perfect
match for what OCP connections are. OCP connections are not really
"connections" from transport point of view; more like sessions. Most
OCP negotiations can be done on BEEP session basis (TCP connection),
allowing for low-overhead OCP connections (BEEP channels).

> however, you should always use the best tool for the job. if beep is

Thanks for a detailed response!

Alex.

---

From: Marshall Rose <[email-masked]>
Date: Thu, 17 Apr 2003 11:52:30 -0700

> library and a decent-size project. This is why I am also concerned
    
all i can say is that your perception about xml appears to be at
variance with my impression of a lot of other people's perceptions.

> for BEEP Core -- its use is so limited that it is hard to justify!

see above.

> XML element as a part of a channel management routine.

the xml subset used by beep makes that rather difficult.

> Thus, we would

i think it's a false choice. anyone who can wade through and understand
the opes specifications, will have no difficulty dealing with xml. let's
keep our perspective here.

> all? Did you consider that option when designing BEEP?

no, because then you move out of the realm of widely-deployed
tools. that's why canonical xml is a bad thing: it requires the use of
special-purpose libraries.

> messages are already being worked on (a pipeline model).

ok, do you care that they actually got there or not?

> approach in mind when considering OCP over BEEP. Or are you talking

if you don't need an acknowledgement for each MSG, you can do what
reliable syslog does, wherein the server sends a MSG when the channel
opens, and the client sends back zero or more ANS in response.
    
/mtr

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 13:26:33 -0600 (MDT)

> variance with my impression of a lot of other people's perceptions.

Good! Since my view is rather pessimistic, I would rather be proven
wrong. :)

> > Thus, we would either have to close our eyes on this problem and
> > test with simple XML elements only, or we would have to
> > acknowledge that many (most?) OCP implementations are not really
> > compliant. Not a nice choice.
>

It is not a question of misinterpreting the specs. The shortcut I am
talking about is a deliberate action. For example: "For simplicity, we
will assume that CDATA will never be sent to our server as a part of
BEEP channel management; let's not handle CDATA!". And then some OPES
processor decides to send its copyright statement in CDATA...

> > recommending (requiring?!) its use within OCP/BEEP? Would that
> > help at all? Did you consider that option when designing BEEP?
>
> no, because then you move out of the realm of widely-deployed tools.
> that's why canonical xml is a bad thing: it requires the use of

Right. Since I assume that most decent implementations will have to
use special-purpose libraries anyway, it is not a problem for me. So
it all boils down to whether appropriate XML libraries are available
for the majority of real-world implementations we care about. I am
skeptical; you say the majority think that they are indeed available.

> ok, do you care that they actually got there or not?

I know they would get there because I use lossless transport (I would
be notified if something goes wrong). I do not care about the timing
though (because it is a pipeline/stream). I am only interested in the
adapted data sent back; that adapted data may come at any time, even
before [some of] my original data reaches the other end(!)...

> reliable syslog does, wherein the server sends a MSG when the
> channel opens, and the client sends back zero or more ANS in
> response.

Yes, of course. The problem is that the server does not "want" to send
any MSG until it gets data from the processor. I understand how to
hack what I need using BEEP mechanisms, but they seem to go against
the logic/semantics of what is going on. What I need is:

  Processor(client): start, data-have, data-have, data-have, ... end
  Server: start, data-have, data-have, ... end

without much of a relationship between the two lines/flows. What I
would have to do with BEEP is:

	Processor(client): server-can-start(MSG)
	Server: processor-can-start(MSG)
	Processor(client): start(ANS), data-have(ANS), data-have(ANS)...
	Server: start(ANS), data-have(ANS), data-have(ANS)...

or some variation of the above.

The first two messages are not needed from OCP point of view, but are
required by BEEP because it supports multiple responses for one
request but not multiple requests with one response (essentially).

We may be able to hide server-can-start and processor-can-start MSGs
behind some other OCP messages that must be sent anyway, but that may
increase the confusion.

Is there a better way?

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 14:58:12 -0600 (MDT)

Abbie Barbir argued that OPES processors should support SOAP as a
foundation of OCP. Abbie, I think it is time to resume that discussion
in the OCP transport light/scope. I have three basic questions:

	1. SOAP is not a transport protocol. Would you
	   require a specific transport protocol to
	   be used if OCP is implemented using SOAP?
	   For example, would you require that BEEP/TCP and
	   only BEEP/TCP is used under SOAP?

	2. My understanding is that using SOAP pretty
	   much requires XML message format/encoding for
	   OCP messages. How do you suggest we implement
	   OCP data pipeline with SOAP? More specifically,
	   what is the best way to transfer, say, a 900KB
	   "binary" stream from OPES processor to callout server?
	   Single large SOAP message? Multiple small messages?
	   How to encode binary data?

	3. Does SOAP allow for SOAP "connections" that are
	   mapped to transport connections of some kind?
	   If we do not have access to transport connections,
	   how do we keep state and avoid constant
	   renegotiations? How do we guarantee that two
	   messages to the same callout server IP address
	   end up at the same server (as opposed to being
	   NATed or load-balanced to different servers)? Do
	   we care about IP not being sufficient to identify
	   a real server?

Thanks,

Alex.

---

From: Marshall Rose <[email-masked]>
Date: Thu, 17 Apr 2003 14:52:33 -0700

> before [some of] my original data reaches the other end(!)...

not true. when TCP fails, a really good API will tell you the last octet
that got acknowledged. most APIs just tell you the connection was
broken.
    
what this means is that the *only* way that an application protocol
knows what application data was successfully received is for it to make
those determinations based on the application data it receives.

for example, that's a reason why an SMTP sender waits to get an
acknowledgement to the final "." of a DATA command.

> ... What I

why not use beep's segmentation capability?
    
beep's MSG, RPY, ERR, and ANS messages each contain a single MIME entity,
e.g., an application/octet-stream or whatever.  beep segments a MIME
entity into multiple frames. each frame, except the last one, has an
indicator saying "more to come".
    
in many cases the entire message fits into one frame, e.g.,
    
    C: MSG with some data & no more-bit
    S: RPY with some data & no more-bit
    
if it doesn't fit into one frame,then:

in most applications, the server waits until it receives a frame without
the more-to-come indicator before processing the data, e.g.,
    
    timeline 1
    ----------
    C: MSG with some data & more-bit
    C: some data & more-bit
    C: some data & more-bit
    C: some data & more-bit
    C: some data & no more-bit
    S: RPY with some data & more-bit
    S: some data & no more-bit
    
however, the server can start processing the MSG as soon as it receives
the first frame, even if the more-to-come indicator is present:
    
    timeline 1					timeline 2
    ----------					----------
    C: MSG with some data & more-bit
    timeline 2 starts  
    					    S: RPY with some data & more-bit
    C: some data & more-bit		    S: some data & more-bit
    C: some data & more-bit		    S: some data & more-bit	
    C: some data & more-bit		    S: some data & more-bit
    C: some data & no more-bit		    S: some data & no more-bit
    
the only "tricky" part is that if the server replies with an ERR instead
of a RPY, then the client must send a frame without the more-to-come
indicator and the sender must start ignoring frames that refer to the
errored MSG (cf., section 2.6.3).
    
/mtr

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 16:47:07 -0600 (MDT)

On Thu, 17 Apr 2003, Marshall Rose wrote:

> not true. when TCP fails, a really good API will tell you the last
> octet that got acknowledged. most APIs just tell you the connection
> was broken.

... and the latter is all OCP agent needs to know.

> those determinations based on the application data it receives.

An OPES processor does not care whether the original data was received
(in general). It only cares about the adapted data it receives back.
Thus, if connection is terminated abnormally, the adapted flow is
incomplete and that is all that matters.

A callout server cares even less because it cannot influence what OPES
processor does with the adapted data. If a connection is terminated
prematurely, the callout server simply forgets about corresponding
transactions.

> acknowledgement to the final "." of a DATA command.

True, but such an acknowledgement is not needed in the OCP data
pipeline case, I think.

> > What I would have to do with BEEP is:
> >
>     ...
> the only "tricky" part is that if the server replies with an ERR
> instead of a RPY, then the client must send a frame without the
> more-to-come indicator and the sender must start ignoring frames
> that refer to the errored MSG (cf., section 2.6.3).

This would be a very good solution but BEEP core says (emphasis mine):

   When a message is segmented and sent as several frames, those frames
   must be sent sequentially, WITHOUT ANY INTERVENING FRAMES FROM OTHER
   MESSAGES ON THE SAME CHANNEL.  However, there are two exceptions:
   first, no restriction is made with respect to the interleaving of
   frames for other channels; and, second, in a one-to-many exchange,
   multiple answers may be simultaneously in progress.

This means that OPES agent cannot interleave data-have messages with
other messages without incurring the penalty of an extra three BEEP
messages. If OPES agent want to send a non-data-have message
immediately, on the same channel, in the middle of a data-have stream,
it would have to

  Extra 1. "Close" the current data-have "stream" with "MSG ."
        2. send the non-data-have message
  Extra	3. "Reopen" the data-have "stream" with "MSG *"
  Extra 4. receive "NUL" response for "Extra 1".

The extras can be avoided if non-data-have message is sent on a
different channel, but then we have synchronization problems to worry
about.

Hmm... A combination of the more-bit and other-end-can-send approaches
may be an attractive hack though (but still a hack, unfortunately).
Once again, we seem to be beaten by a strange asymmetry in BEEP:
interleaving ANS "responses" is allowed, but interleaving MSG
"requests" is not.

Did I miss anything?

Thank you for helping with the OCP/BEEP transport mapping.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 17:49:34 -0600 (MDT)

On Thu, 17 Apr 2003, Alex Rousskov wrote:

> A combination of the more-bit and other-end-can-send approaches may
> be an attractive hack though

Here is how it might look (C == OPES processor, S == callout server)

	// Processor allows the server to start a BEEP ANS stream
	C: MSG 1 1 .
	C: ; perhaps no payload at all
	C: END

	// Server allows the processor to start a BEEP ANS stream
	S: MSG 1 2 .
	S: ; perhaps no payload at all
	S: END

	// normal OCP flow starts for the processor
	// (when it receives "MSG 1 2 .") and then ends
	C: ANS 1 3 .
	C: ...
	C: END
	... // some of the ANSes may use multiple frames
	C: ANS 1 1234 .
	C: ...
	C: END
	C: NUL

	// normal OCP flow starts for the server
	// (when it receives "MSG 1 1 .") and then ends
	S: ANS 1 4 .
	S: ...
	S: END
	... // some of the ANSes may use multiple frames
	S: ANS 1 1235 .
	S: ...
	S: END
	S: NUL

The last two group of messages do not depend on each other from BEEP
point of view. This is still not perfect because it prevents OCP from
using BEEP MSG number/concept for anything useful. However, this
allows to package OCP messages inside BEEP ANS messages, with
virtually no overhead.

This is clearly an abuse of BEEP, to get around its assumptions about
message exchange styles. However, this allows (hopefully) to reuse
other BEEP mechanisms such as channels, profile negotiation, and
session encryption.

I would not be surprised if the above can be polished further to allow
for more tight OCP:BEEP integration.

Alex.

---

From: Marshall Rose <[email-masked]>
Date: Thu, 17 Apr 2003 17:22:43 -0700

> Did I miss anything?

i can't figure out half of what you're saying, because i gave you an
example with MSG and RPY, and you replied talking about MSG, ANS, and
NUL.
    
so, when i say:

    timeline 1					timeline 2
    ----------					----------
    
you seem to be replying that this won't work because you can't have more
than one message in flight on a single channel.
    
correct. so if the requirements is:
    
    - asynchronous request/response where the response can start coming
      back before the request is fully sent.
    
use the approach i explained above. if there is an additional
requirement that:
    
    - more than one simultaneous asynchronous request/response on a
      single beep session
    
then do each parallel exchange on its own channel.
    
if there are other requirements, or these requirements are wrong, let me
know.
    
/mtr

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 23:00:53 -0600 (MDT)

>     timeline 1					timeline 2

yes.

> if there are other requirements, or these requirements are wrong, let me

Simplified transport requirements of the current OCP core, in each
flow direction (processor to server and server to processor), are:

	- efficiently send possibly large application messages and
	  metadata (blobs), with possibly more than one blob being
	  sent at a time; parts of each blob should be
	  delivered in sent order

	- send usually small OCP "control" messages related
	  to the dataflow above, at any time; control messages should
	  be delivered in sent order

We agree that the first approach (one channel per OCP connection) does
not work without hacks because it does not support the "at any time"
part.

Using multiple channels per OCP connection (one for control and one or
more for data/metadata) would work, but, as I said, I am worried about
synchronization problems between data and control channels. My
understanding is that BEEP does not guarantee that two messages sent
on two channels will arrive in the order they were sent. Please
correct me if I am wrong.

This FTP-like approach adds more state than is strictly necessary for
OCP, but I cannot think of any specific OCP task that would _require_
synchronization between data and control channels. So, yes, I think it
can work. Moreover, adding extra control channels to support fast
aborts is on the todo list and the FTP approach would make that
optimization a little easier to describe.

I think we are on the same page now. It would be great to hear from
others as well. Is anybody able to follow my lame attempts at
explaining the problem? Does anybody have horror stories to tell about
FTP (other than firewall problems)? Is there a reason we should not
use multiple BEEP channels per OCP connection _if_ BEEP is selected as
a transport protocol?

Marshall, is it correct to say that opening a new BEEP channel can be
"cheap", even if we want to use encryption and such? Multi-channel
solution appears to be more elegant than my hack, but I am worried
about the cost on performance. If an OCP connection (all BEEP
channels) needs to be encrypted using, say TLS, does it mean that an
OCP agent would have to re-negotiate encryption parameters for every
channel it needs to open? This is not a show-stopper (because we could
keep channels persistent), but we need to understand the costs. It
would be nice if we could say "and for this new channel, use the same
parameters we negotiated for that old channel", but we cannot do that
in general, can we?

Thanks,

Alex.

P.S. Apologies for skipping a few steps in the previous e-mail. I
     put too many new details in one example.

---

From: Marshall Rose <[email-masked]>
Date: Fri, 18 Apr 2003 09:46:08 -0700

thanks for the clarification.

> correct me if I am wrong.

that is correct, channels on the same session, are effectively
parallel. if you need to synchronize them, you can, you have to define
messages to do so for your protocol.

> use multiple BEEP channels per OCP connection _if_ BEEP is selected as
    
if the answer is "FTP", then the wrong question has been asked.

> parameters we negotiated for that old channel", but we cannot do that
    
each beep session has a single encryption/authentication context. you
negotiate it at the start of the session, and it applies to every
channel thereafter, e.g.,
    
	beep channels
	beep frames
	tls packets
	tcp segments
    
all traffic on all channels goes over the same tls session.
    
/mtr

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 18 Apr 2003 12:12:41 -0600 (MDT)

> if the answer is "FTP", then the wrong question has been asked.

Shoot. I deleted a sentence explaining that the multi-channel approach
is probably similar to what FTP uses (data channel + control channel).
I did not mean to suggest that we use FTP for anything; that would not
even be funny. Still, some FTP lessons might be useful.

> each beep session has a single encryption/authentication context.
> you negotiate it at the start of the session, and it applies to
> every channel thereafter, e.g.,
>
> 	beep channels
> 	beep frames
> 	tls packets
> 	tcp segments
>

Great, that helps to keep per-channel overheads low.

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 23 Apr 2003 09:43:16 -0600 (MDT)

Hilarie,

	You mentioned that a new custom OCP transport is the best way
to proceed, but did not follow up on that suggestion. As of now, we
seem to have two existing transports to consider: BEEP and HTTP. Do
you still think a new, custom transport would be better? If yes, can
you elaborate? You can use my specific questions below to start with
(they split the problem into two semi-independent parts: new versus
old transport and reliable versus lossy transport).

	It would be great to have more information so that we can
summarize the advantages/disadvantages of all transports and make the
final selection.

Thank you,

Alex.