RE: [EFM] Should There Be A Sequence Number In Variable Request/Resp onse PDUs?
Title:
If the
information ios not self describing to the extent that it is possible to
determine that it fulfills a request for specific information then either (a)
the information is not properly self describing and should be fixed, or (b) the
original request is not properly described.
Introducing sequence number/correlator fields does make the protocol
stateful because, trivially, the state is remembered by a protocol participant.
It also introduces a range of errors - what if a response with correlator number
does not actually contain the information requested for example? The best a
correlator number can do is provide the guess as you describe, and then the
guess needs checking - by someone at least.
There
may be overall system design reaosns (proxy queries through gateway functions
for example) why a correlator is a good idea, but these ought to be spelled out
(this case may be a very bad idea since it invokes a new species of non-standard
relay). I don't think it is a good idea to use the correlator as a crutch to
obscure flaws in a design (inadequately described info for example). If the
purpose of the correlator is to mtach reponses with requests then properly
described data should be capably of being used as a simple hash to do the
location matching - remembering that all the cases of unknown correlator,
repeated correlator, correlator with partial info, correlator with surplus info,
correlator with different info all have to be trapped some time in a robust
design. If the correlator is envisaged simply as a performance improvement
someone may be surprised at the new possibilities for error it
introduces.
Mick
Hi.
First
of all I agree with you completely that the protocol should be (and is)
connectionless. We want this protocol to be as simple as
possible.
However, I don't think that a "correlator" field would necessarily make
it stateful. The field is merely used to assist the requester to match a
response to its request in a simple and consistent manner. An example of this is
SNMP. An ID is in each PDU and it's used by the SNMP manager only. The SNMP
agent doesn't track the request IDs. And even with the ID, SNMP protocol is
connectionless.
Without such a field, one would be forced to scan through the PDU and
compare the variables and take a guess on whether a response
matches a request. The content is self describing in the sense of what variables
it contains, but it is not self-describing enough to be useful in matching
requests and responses.
I do
agree that the requester should moderate the number of requests it sends. The
protocol already specified that no more than 10 PDUs per second can be sent. But
the current draft doesn't prohibit more than one Variable Requests at a time.
So, I am still in the position of introducing such a field.
Thanks.
Regards,
Yonghong Ren
Appian
Communications.
My
(limited becuase I haven't read this particular protocol) opinion is that in
general information providing protocols should be designed to be
'connectionless' wherever possible for simplicity, that is to say that
information that is sent completely describes itself.
In
such a design it is not neccessary to send sequence/correlation numbers in the
protocol even if there are multiple outstanding requests, and they should be
avoided. It is up to the requestor of the information to match the self
describing information received with any outstanding user requests for such
information - of which there may be one, none (user may have given up/gone
away), or several (several users may want the same information). It is also up
to the requestor to moderate the nuber of times prompts or solicitations are
sent for information.
Mick
Hi,
At
least the responses contain the information on which values are being
returned, so to some extent one can simply use that as a kind of
correlator.
However, I agree that a correlator field might well be useful to
correlate requests and responses, but I'd recommend calling it a correlator
rather than a sequence number, and avoid any language requiring it to be
incremented in each request etc. Simply say that the correlator from the
variable request PDU should be returned in each resulting variable response
PDU - then, anyone who wanted to, could set it to a unique value, and
anyone else could just set it to zero and ignore it when
returned.
Does
anyone else have an opinion?
Cheers,
-- John
Variable Request and
Response PDUs don't have a sequence number field.
If one is allowed to send multiple outstanding
Variable Requests, then how is to
match a response to its corresponding request? Should not we introduce a sequence
number? Sure, to some extent one could match
them by looking at what variables are included, but it's not a sure
way.
If the intention is not
to allow more than one Variable Request at a time, which I think is
reasonable in order to keep the OAM operation simple, then a note to that
effect in the standard would be nice.
Your comments are
welcome and appreciated.
Regards,
Yonghong Ren
Appian Communications