Subject: iSCSI: Reject, CmdSN, and DataSN

From: Mark Bakke <[email-masked]>
Date: Fri, 27 Jul 2001 08:41:15 -0500

When a PDU is rejected, I assume that the CmdSN is still
updated, as well as the DataSN where applicable.  That is,
a rejected command still uses up a SN.  It probably wouldn't
hurt to state this in the reject section.

Since the Reject response does not contain ExpCmdSN, if the
last command before the window is closed is rejected, the
initiator has to rely on prior commands completing to re-open
the window.  This will usually work, but what if the window
size is reduced to one outstanding command for some reason?
Any command that is rejected will close the window for good.
A sequence of rejected commands equal to the window size will
do the same.

Any thoughts?

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Mallikarjun C." <[email-masked]>
Date: Sat, 28 Jul 2001 12:32:41 PDT

Mark,

When you say "uses up a SN", do you mean the ExpCmdSN/ExpDataSN
is updated?  If so, I see a problem with at least CmdSN.

Let's consider commands first.  The only Reject reason code that 
I see where a target could update its ExpCmdSN is when there 
is a payload-digest error on immediate data.  In all the other 
cases, either the target doesn't care (immediate/retry/non-FFP), 
or can't know for sure (format error).  I suggest that we _not_ 
advance the ExpCmdSN on immediate data digest error to give the 
initiator an opportunity to re-issue the command to preserve 
command ordering.

Let's now consider data.  Again the only Reject reason code I see
for advancing ExpDataSN is payload-digest error ("2").  Either the 
target
  (a) would generate a recovery R2T (if DataSequenceOrder was 
      negotiated as "no" and target supports Within-command 
      recovery), or 
  (b) eventually signal a service delivery subsystem failure for
      the command (iSCSI response code 0x02).

For (b), it doesn't matter if the target updates ExpDataSN or not.
For (a) OTOH, the target should update the ExpDataSN to deal with
the current data burst (that reminds me that I need to fix this
in Within-command algorithms in Appendix F!).

So to summarize, I think a Reject'ed CmdSN should not be considered
as successfully received on the target.

Your comments are welcome.
--
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
[email-masked]