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?

Title:
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.
 
-----Original Message-----
From: Mick Seaman [mailto:mick_seaman@ieee.org]
Sent: Thursday, August 14, 2003 9:34 AM
To: 'John Messenger'; 'Yonghong Ren'; stds-802-3-efm@ieee.org
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.
 
Mick
 
 
 
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of John Messenger
Sent: Thursday, August 14, 2003 2:36 AM
To: 'Yonghong Ren'; 'stds-802-3-efm@ieee.org'
Subject: RE: [EFM] Should There Be A Sequence Number In Variable Request/Resp onse PDUs?

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
-----Original Message-----
From: Yonghong Ren [mailto:ren@appiancom.com]
Sent: 13 August 2003 21:25
To: 'stds-802-3-efm@ieee.org'
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. 
 
Regards,
 
Yonghong Ren
Appian Communications