Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] Should There Be A Sequence Number In Variable Request/Resp onse PDUs?

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.
-----Original Message-----
From: []On Behalf Of Yonghong Ren
Sent: Thursday, August 14, 2003 7:25 AM
To: ''; 'John Messenger'; Yonghong Ren;
Subject: RE: [EFM] Should There Be A Sequence Number In Variable Request/Resp onse PDUs?

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.
Yonghong Ren
Appian Communications.
-----Original Message-----
From: Mick Seaman []
Sent: Thursday, August 14, 2003 9:34 AM
To: 'John Messenger'; 'Yonghong Ren';
Subject: RE: [EFM] Should There Be A Sequence Number In Variable Request/Resp onse PDUs?

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.
-----Original Message-----
From: []On Behalf Of John Messenger
Sent: Thursday, August 14, 2003 2:36 AM
To: 'Yonghong Ren'; ''
Subject: RE: [EFM] Should There Be A Sequence Number In Variable Request/Resp onse PDUs?

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?
    -- John
-----Original Message-----
From: Yonghong Ren []
Sent: 13 August 2003 21:25
To: ''
Subject: [EFM] Should There Be A Sequence Number In Variable Request/Resp onse PDUs?

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. 
Yonghong Ren
Appian Communications