Re: iSCSI: cmd_sn management on rejected PDUs

["Mallikarjun C." <cbm@rose.hp.com>]

Joseph,

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

Now, on to your question -
>Should the target wait for the initiator to 'fill the hole'
>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: 'ips@ece.cmu.edu' 
Sent: Thursday, February 14, 2002 7:04 AM
Subject: iSCSI: cmd_sn management on rejected PDUs


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
jpittman@netapp.com