Subject: RE: iSCSI: MaxCmdSN

From: "Martin, Nick" <[email-masked]>
Date: Mon, 11 Jun 2001 11:59:53 -0500

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:[email-masked]]
Sent: Monday, June 11, 2001 9:18 AM
To: [email-masked]
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

---

From: "Ayman Ghanem" <[email-masked]>
Date: Mon, 11 Jun 2001 14:11:03 -0500

Nick,

Yes, it will be an error for MaxCmdSN to have a value < (ExpCmdSN - 1), and
I agree that MaxCmdSN = (ExpCmdSN - 1) should be permitted. As for the
target receiving a PDU with CmdSN > MaxCmdSN, it is stated in draft-06 (near
the end of 1.2.2.1) that the target MUST silently ignore such a command. No
reject PDU needs to be sent.

-Ayman

> From: Martin, Nick [mailto:[email-masked]]
> Sent: Monday, June 11, 2001 12:00 PM
> To: 'Ayman Ghanem'; [email-masked]
> Subject: RE: iSCSI: MaxCmdSN
>
>
> Ayman,
>

---

From: "Ayman Ghanem" <[email-masked]>
Date: Mon, 18 Jun 2001 00:23:25 -0500

Julian,

The text in section 2.4.10 should make it clear that a response PDU from the
target with MaxCmdSN=ExpCmdSN-1 is permitted, to handle the case when the
target's window has reached 0. It is OK for the initiator to ignore the
MaxCmdSN but not the ExpCmdSN. Also, if the initiator has no other commands
pending at the target, the target MUST send a NOP-IN advancing the MaxCmdSN
to update the corresponding value at the initiator.

-Ayman

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ayman Ghanem
> Sent: Monday, June 11, 2001 2:11 PM
> To: [email-masked]