Subject: iSCSI: cmd_sn management on rejected PDUs

From: "Pittman, Joseph" <[email-masked]>
Date: Thu, 14 Feb 2002 07:04:14 -0800

I have a question about sequence number management when
command PDUs are rejected.

If an initiator sends a non-immediate command PDU which the
target rejects, does this command consume a cmd_sn?  For
example, consider this case:

  - initiator sends a non-immediate text request with a
    non-zero target transfer tag, sequence number 37
  - target looks up the target transfer tag, doesn't recognize
    it, and generates a reject/UNKNOWN_TT_TAG message

Should the next command PDU sent by initiator use cmd_sn=37
or cmd_sn=38?

2 follow-up questions:

IF the rejected PDU IS supposed to consume a cmd_sn, then
what are the rules regarding how badly a PDU BHS may be
mangled before it can be considered worthy of consuming
a cmd_sn?  That is, should a PDU BHS with the expected cmd_sn
and I-bit == 0, but containing an otherwise random stream of
bytes, consume a cmd_sn?  And what if the header digest is
incorrect?

IF the rejected PDU is NOT supposed to consume a cmd_sn (i.e.
next command PDU should be cmd_sn=37), then what is supposed
to happen in the following case:

  - target supports command window size of 4
  - initiator sends a non-immediate text request with a
    non-zero target transfer tag, sequence number 37
  - initiator sends three more non-immediate commands with
    cmd_sn 38, 39, and 40
  - target rejects cmd 37

In this case, cmds 38, 39, and 40 have arrived 'out of order'.
Should the target wait for the initiator to 'fill the hole'
by issuing some other command with cmd_sn=37?

Thanks in advance for any spec interpretation or advice.
--
Joe Pittman
[email-masked]

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 14 Feb 2002 17:12:22 -0500

> Should the next command PDU sent by initiator use cmd_sn=37

Draft 10, pg. 28:
  The target iSCSI layer sets ExpCmdSN to the largest
non-immediate CmdSN that it can deliver for execution
plus 1 (no holes in the CmdSN sequence).

Thus, if everything was normal before the initiator sent
the buggy PDU w/ CmdSn 37, then ExpCmdSN at the target
will not change, and be 37.

Previously at the initiator ExpCmdSN was 37 (if all was ok
before that), and you'd apply the rules on page 29. Let's
do the last one (more general):

Initiator upon recv. Rej. PDU:
 IF Rej. PDU ExpCmdSN (=37) < ExpCmdSN (=37) THEN
    Ignore
 ELSE
    ExpCmdSN = PDU ExpCmdSN
 ENDIF

So, ExpCmdSN at the initiator is now still 37,
and the next PDU the initiator will send will bear CmdSN 37.

This solves the problem of cycling through CmdSN too quickly.
In a large network (say company X, doing video editing), 32 bits
is too small and we don't want to go through them too quickly.

The above IF THEN ELSE can be optimized to <= and thus
is equivalent to:
  IF Rej. PDU ExpCmdSN > ExpCmdSN THEN
     ExpCmdSN = PDU ExpCmdSN
  ENDIF

At which point the text will have to say 
``If ... less than or equal ... then it is ignored ...''.

P.S. All integer comparisons are in terms of RFC1982.

-- 
Luben

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 14 Feb 2002 15:53:31 -0800

Joseph,

Refer section 7.2 of rev10 draft for the answer to this question.

Now, on to your question -
>by issuing some other command with cmd_sn=37?

Generally yes - since the target treats it no different from an unreceived 
PDU.  Specifically, the regular operational ErrorRecoveryLevel expectations
apply to recover the situation you describe.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747

----- Original Message ----- 
From: Pittman, Joseph 
To: [email-masked]' 
Sent: Thursday, February 14, 2002 7:04 AM
Subject: iSCSI: cmd_sn management on rejected PDUs

2 follow-up questions: