RE: iSCSI: MaxCmdSN

["Martin, Nick" <Nick.Martin@compaq.com>]

Ayman,

I thought I understood this, and I had a great explanation supporting the
draft (06), but I now realize I was "off by one".  I believe you are correct
that ExpCmdSN will be one greater than MaxCmdSN if-and-only-if an
acknowledgement is to be sent while the window is closed.

The purpose of ExpCmdSN and MaxCmdSN transmitted by the target, is to
advance values with the same names maintained in the initiator.  ExpCmdSN
acknowledges receipt of all CmdSN values < ExpCmdSN.  MaxCmdSN is the
largest CmdSN the target promises to accept, and conversely the largest
CmdSN the initiator is permitted to send.

The target can not regress these numbers in the initiator.  When the target
transmits (and the initiator accepts) N as the MaxCmdSN, the initiator is
allowed to transmit CmdSN values through N.  Then it must stop.  Any number
of additional PDUs may carry the same MaxCmdSN value.  None of these will
cause the initiator's value to advance.  A response carrying a MaxCmdSN less
than the initiator's current MaxCmdSN value is presumed to have arrived
late.  It does not advance nor regress the initiator's present value.

After the initiator sends CmdSN of MaxCmdSN (still N), it can not send any
more until MaxCmdSN advances.  It should be permitted for the target to
acknowledge the receipt of all commands received through this CmdSN which is
N.  In this case ExpCmdSN would be N + 1 and MaxCmdSN is still N.  We know
that no commands are in flight.  When the target is able to accept another
command, it must advance MaxCmdSN (value > N in serial arithmetic), and it
will send the new value to the initiator in the next inbound PDU (i.e.
data-in, SCSI response, or nop-in).

Yes, I believe it would be a protocol error for MaxCmdSN to have a value
less than ExpCmdSN - 1.  This would be an acknowledgement for a CmdSN which
the initiator was not yet permitted to send.  I think MaxCmdSN equal to
ExpCmdSN - 1 should be permitted.

Note however that nothing will break if this acknowledgement is not
immediately sent or, having been sent, does not advance the initiator's
values.  The window is already closed and remains so.  While the window is
closed, the initiator will be holding the last PDU sent as unacknowledged,
when the target has in fact received it.  The PDU will be successfully
acknowledged when MaxCmdSN advances, because ExpCmdSN in the target will not
advance simultaneously while the window is closed.  

Was this done intentionally to delay the last acknowledgement when the
window is closed, or is it an "off by one" issue in  draft 06?

This made me think about a related issue:
It think it would be permitted for the target to reject or drop a PDU with
CmdSN greater than MaxCmdSN, but I am not sure if it is required to do so.
I do not see a response code the target could send that would tell the
initiator what it did wrong.

Thanks,
Nick

-----Original Message-----
From: Ayman Ghanem [mailto:aghanem@cisco.com]
Sent: Monday, June 11, 2001 9:18 AM
To: ips@ece.cmu.edu
Subject: iSCSI: MaxCmdSN


In section 2.4.10, "if the PDU MaxCmdSN is less than the PDU ExpCmdSN ....,
they are both ignored". Is this considered an invalid response from the
target?. What happens when the target queuing capacity reaches 0. For
example: target received and processed cmdsn N, but can not receive cmdsn
N+1 yet. In the response for N, target puts N+1 for expectedCmdSN. How does
it inform the initiator that its window is closed?. Setting MaxCmdSN to N
will be ignored if I understand the above paragraph correctly.

-Ayman