Re: iSCSI ExpStatSN, StatSN question
"Dean Scoville" <[email protected]>
| Newsgroups | gmane.ietf.ips |
|---|---|
| Message-ID | <[email protected]> |
Rather than simply ask the question, here is how I interpret the
paragraph... any comments?
The "absolute difference" must of course take into account sequence
number wrapping, so for example, the absolute difference between
FFFFFFFFh and 0h is 1, just as the absolute difference between
0h and 1h is 1 and the absolute difference between 0h and FFFFFFFFh
is 1. When an initiator receives a PDU containing a StatSN value,
it takes one of the following 3 actions:
action 1:
If the StatSN is more than the "implementation defined constant" away
from the ExpStatSN (in a positive or negative direction), then the initiator
should consider the connection failed and close it. Otherwise, the
initiator performs error recovery as described below for action 2 or 3.
action 2:
When the initiator's ExpStatSN is greater than the received StatSN
(based on serial arithmetic), the initiator discards the PDU containing
the duplicate status and may send a PDU to the target (NOP-Out, or
other PDU containing the current ExpStatSN) to update the target's
knowledge of the status already received by the initiator.
action 3:
When ExpStatSN is less than the received StatSN (based on serial
arithmetic), the initiator can SNACK for the missing status (or close
the connection, depending on error recovery level).
In response to my original question, when the "implementation defined
constant" is 2**31-1, the threshold is such that the initiator would perform
error recovery in all cases except when the absolute difference is 2**31,
which is the only StatSN that is out of range given the implementation's
chosen constant. The behavior would be as follows:
a) ExpStatSn=FFFFFFFFh, and initiator receives StatSn=0. (i.e., missing one StatSN)
- take action 3, because missing StatSN is within range.
b) ExpStatSn=0h, and initiator receives StatSn=FFFFFFFFh. (i.e., duplicate StatSN)
- take action 2, because duplicate StatSN is within range.
c) ExpStatSn=0h, and initiator receives StatSn=7FFFFFFFh. (i.e., missing lots of StatSNs)
- take action 3, because missing StatSNs are within range.
d) ExpStatSn=0h, and initiator receives StatSn=80000000h. (missing or duplicate?)
- take action 1, because received StatSN is out of range.
e) ExpStatSn=0h, and initiator receives StatSn=80000001h. (i.e., very old duplicate StatSN)
- take action 2, because duplicate StatSN is within range.
Other "implementation defined constants" would vary the range of
acceptable StatSN values. At the other extreme, a "implementation
defined constant" of 0 would cause the initiator to close the connection
whenever a PDU containing a StatSN value that does not match the
initiator's ExpStatSN is received.
Any comments? Does this seem like a valid interpretation?
Thanks,
Dean
-----Original Message-----
From: Dean Scoville [mailto:[email protected]]
Sent: Monday, June 26, 2006 6:29 PM
To: [email protected]
Subject: [Ips] iSCSI ExpStatSN, StatSN question
I would like help interpreting the following paragraph from iSCSI RFC 3720,
Section 3.2.2.2:
"A large absolute difference between StatSN and ExpStatSN may indicate
a failed connection. Initiators MUST undertake recovery actions if the
difference is greater than an implementation defined constant that MUST NOT
exceed 2**31-1."
I don't understand what is meant by "absolute difference"... For the purposes of
this discussion, assume the "implementation defined constant" to be 2**31-1,
which is the largest allowed value... regardless of whether you consider this a
"reasonable" choice for the constant.
In this case, which of the following would require recovery actions, and why?
a) ExpStatSn=FFFFFFFFh, and initiator receives StatSn=0. (i.e., missing one StatSN)
b) ExpStatSn=0, and initiator receives StatSn=FFFFFFFFh. (i.e., duplicate StatSN)
c) ExpStatSn=0, and initiator receives StatSn=7FFFFFFFh. (i.e., missing lots of StatSNs)
d) ExpStatSn=0, and initiator receives StatSn=80000000h. (missing or duplicate?)
e) ExpStatSn=0, and initiator receives StatSn=80000001h. (i.e., very old duplicate StatSN)
thanks,
Dean Scoville
_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips