Subject: Re: iSCSI: MaxCmdSN and the I bit

From: "Julian Satran" <[email-masked]>
Date: Tue, 19 Mar 2002 16:00:54 +0200

Eddy,

Comments in text.

Julo

Eddy Quicksall <[email-masked]>
Sent by: [email-masked]
19-03-02 02:22
Please respond to Eddy Quicksall

        To:     "ips@ece. cmu. edu (E-mail)" <[email-masked]>
        cc: 
        Subject:        iSCSI: MaxCmdSN and the I bit

1) Section 2.2.2.1 Command Numbering and Acknowledging says

    MaxCmdSN - the maximum number to be shipped.
 
But can't anything with the I bit set take on MaxCmdSN+1? If so, should 
this say "for non-immediate commands, the maximum number ..."? If so, 
there are a couple of other places to update as well (like 9.4.10).

+++ I'll fix the wording. +++
 
2) Is there any reason why the "I" bit would be used with a SCSI Command? 
I ask this because all SCSI commands have to pass to the SCSI layer and 
there would be no way to throttle them when the "I" bit is set.
 
+++ There is no reason to stop an implementor doing it as long as it know 
that it can neither throttle no recover them.
E.G. a device may require an "urgent mechanical recalibration".  As a rule 
we did not introduce limitation unless they where mandated by the protocol 
logic.
+++

3) Section 9.4.9 ExpCmdSN - Next Expected CmdSN from this Initiator says: 
    An ExpCmdSN equal to MaxCmdSN+1
    indicates that the target cannot accept new commands.
But it could if the "I" bit was set and your answer to #2 above is "yes", 
correct?
+++ correct - I'll say non-immediate commands - +++
Eddy

---

From: "Robert D. Russell" <[email-masked]>
Date: Wed, 20 Mar 2002 08:26:04 -0500 (EST)

Julian:

One of the changes that came in with draft 11 is that in the
Asynchronous Message PDU and in the Reject PDU the 4-byte field
at offset 16 became:
   16| Reserved -0xffffffff
whereas previously it had just been Reserved.

I believe the reason for explicitly specifying the value 0xffffffff
is because this field in all other PDUs is the Initiator Task Tag,
and for all those other PDUs this value means there is no valid
Initiator Transfer Tag.  This change now makes it possible for an
initiator to find the task associated with each incoming PDU before
looking at the opcode of the PDU.  So far so good.

The problem is that this field cannot be called Reserved due to section
9 which says that receivers MUST ignore reserved fields, thus defeating
the whole purpose of defining a value the initiator can use.

To correct this, the specs for both Asynchronous Message and Reject
should be changed to explicitly include the Initiator Task Tag field
and specify in the descriptions of each of those PDUs that this field
MUST be set to 0xffffffff.

If this is done, then every PDU will contain the Initiator Task Tag field,
and the description of the BHS in section 9.2.1 can be changed from:
  16| Initiator Task Tag or Opcode-specific fields
to
  16| Initiator Task Tag
which would clearly show the consistent meaning of this field over all PDUs.

Also, there are two related minor clarifications that should be made:

1) The 4th paragraph of section 9.16.1 currently says:
      "For Status SNACK, the Initiator Task Tag is reserved."
   It would be better if this said explicitly:
      "For Status SNACK, the Initiator Task Tag MUST be set to the
      reserved value 0xffffffff."

2) The last sentence in section 9.5.3 says:
      "For all the other functions this field is reserved."
   It would be better if this said explicitly:
      "For all the other functions this field MUST be set to the
      reserved value 0xffffffff."
   (Note that the corresponding sentence in section 9.6.2 already
   says this.)

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774