Subject: Re: Start on OPES protocol work

From: "Martin Stecher" <[email-masked]>
Date: Sun, 16 Feb 2003 13:15:23 +0100

> 
> > 3.
> > I like to minimize the message overhead (see my performance
> > considerations in point 5). Together with what I said above 
> in the first
> > section, I think that a message header and footer (if a footer is
> > necessary at all) should be as short as possible. Usually, protocols
> > write a protocol version into each request and response - but why? 
> 
> IMO, because it reduces the state to be held by the endpoints of the
> connection.

I guess that some parameters that are exchanged during connection establishment need to be kept anyway; I think that another version field in the state info will not hurt at all.
On the other hand you are certainly right that the version number overhead is not a big issue anyway. I just wanted to give an example. There is usually much more information which is repeated with every request on the same connection.

> 
> > Isn't
> > it enough to do this once when a callout connection is 
> established.? All
> > the messages within a persistent connection will be of the 
> same version.
> > When we try to keep this in mind, every message could be 
> designed to be
> > a minimum around the payload.
> > 
> > Messages should also follow a same general syntax to make parsing as
> > simple and fast as possible and to allow to skip easily 
> message types
> > that are optional.
> 
> Agreed. IMO this has a greater impact on performance than a few bytes
> for version identification.

Correct. But let me again argue why also the little additions can hurt:
If the OPES client needs to wrap parts of the application message in a structure with parts in the beginning and at the end, this usually means to copy the message data on application layer again to setup the structure. While the OPES client will need to forward huge amount of data to the callout service, reducing the number of message data copies should be helpful.

> 
> The thing to remember is that any general purpose protocol will be
> slower than a specially tuned protocol. We're building a 
> general purpose
> tool here - so reliability, ease of implementation and 
> interoperability
> are (IMO) greater priorities.
> 

Yes, they are but this does not mean that the protocol has to be slow. If we also look at these things, I guess that we can have only a little distance to specially tuned protocols.
If we fail here the OPES protocol could stay a nice academic experience without relevance to the industry.

Martin

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sun, 16 Feb 2003 21:28:14 -0500

Hi,

the capability negotiation was in part to avoid having to repeat fields in
the packets since the two ends would have agreed in the protocol version and
several other parameters. Some other protocols where there is some form of
capability negotiation (specially routing protocols) repeat the version
number in the packets, but routing is something that doesn't change often
(at least in theory) and you can put thousands of routes in one packet, so
overhead is not an issue.

I see the the callout protocol having a control phase and a data phase. In
the control phase the version number will be in the packet (in the header or
as another parameter) so that the two ends can agree in the minimum set of
semantics. In the data phase where the opes processor is making the callout
work for its meal, there is no need to the version number (and others)
anymore.

Some people might argue that a version number in the packets make debugging
easier...but we can also achieve this by having a standardized list of
operations (for each protocol version) that a opes processor can request. Of
course extensions should go though this WG and normal IETFT process. Just
like PPP extensions.

what do you think?

regards,

Reinaldo

----- Original Message -----
From: "Martin Stecher" <[email-masked]>
To: "OPES Group" <[email-masked]>
Sent: Sunday, February 16, 2003 7:15 AM
Subject: Re: Start on OPES protocol work

> I guess that some parameters that are exchanged during connection
establishment need to be kept anyway; I think that another version field in
the state info will not hurt at all.
> On the other hand you are certainly right that the version number overhead
is not a big issue anyway. I just wanted to give an example. There is
usually much more information which is repeated with every request on the
same connection.
> If the OPES client needs to wrap parts of the application message in a
structure with parts in the beginning and at the end, this usually means to
copy the message data on application layer again to setup the structure.
While the OPES client will need to forward huge amount of data to the
callout service, reducing the number of message data copies should be
helpful.
> Yes, they are but this does not mean that the protocol has to be slow. If
we also look at these things, I guess that we can have only a little
distance to specially tuned protocols.

---

From: jfcm <[email-masked]>
Date: Mon, 17 Feb 2003 11:04:41 +0100

>course extensions should go though this WG and normal IETFT process. Just

IMHO there should be several layers.

1. the link. Is the service here. What are the general paramenters of the 
service (version, owner, rates, oerating terms and conditions, etc.). Also 
is the link in operation (last time of exchange)

2. the connexion. What is the accepted traffic rate, the type of 
encryption, the accepted protocols, etc. Also is the connexion alive (last 
time of an exchange)

3. the cession. Who is demanding, who is paying, the defaults to be used, 
the service priority, etc. Radom key of the pseudo-random ref. Last 
exchange pseudo-random ref, expected next exchange pseudo-random ref.

jfc

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03