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" <martin(_dot_)stecher(_at_)webwasher(_dot_)com>
To: "OPES Group" <ietf-openproxy(_at_)imc(_dot_)org>
Sent: Sunday, February 16, 2003 7:15 AM
Subject: Re: Start on OPES protocol work
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