iSCSI Rev 4

["Douglas Otis" <dotis@sanlight.net>]

Julian,

Page 11:
   "Status numbering is per connection and is used to enable recovery
   in case of connection failure."

Status number is not used to recover a connection failure.  It is used to
recover from a communication error on a connection but not for the case of a
connection failure.  The SCSI tag is used to recover a connection failure.

Page 11:
   "Commands in transit from the initiator SCSI layer to the SCSI target
   layer are numbered by iSCSI and the number is carried by the iSCSI
   PDU as CmdSN (Command-Sequence-Number).  The numbering is session-
   wide.  All iSCSI PDUs that have a task association carry this number.
   CmdSNs are allocated by the initiator iSCSI within a 32 bit unsigned
   counter (modulo 2**32).  The value 0 is reserved and used to mean
   immediate delivery. Comparisons and arithmetic on CmdSN SHOULD use
   Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS =
   32.

   The means by which the SCSI layer may request immediate delivery for
   a command or by which iSCSI will decide by itself to mark a PDU for
   immediate delivery are outside the scope of this document.

   Using immediate delivery with some commands may have unexpected side
   effects.  If used with Task Management commands those may get to the
   SCSI task manager at the target before the tasks they where suppose
   to act upon.
   Whenever those effects are undesirable connection allegiance or
   ordered delivery MAY be used."

Do you see a paradox with immediate delivery identified with a zero sequence
and then saying ordered delivery should be used for immediate delivery if
sequencing matters?  Connection allegiance does not ensure ordered delivery
on immediate commands unless you call a hold on all commands pending
resolution of a communication error.  How should immediate delivery confine
task attributes?


Page 12:
   "CmdSNs are significant only during command delivery to the target.
   Once the device serving part of the target SCSI has received a
   command, CmdSN ceases to be significant.  During command delivery to
   the target, the allocated numbers are unique session wide.

   The iSCSI target layer MUST deliver the commands to the SCSI target
   layer in the order specified by CmdSN."

Could you more clearly define delivery to the target.  Could you say "Upon
command order having been checked and processed on a session basis, CmdSN is
discarded?"  If there is little communication between network adapters, at
no point is there an ability to know when to drop the CmdSN except at some
higher level.  The concept of delivery is vague.  This sentence seems to be
assuming a structure not clearly defined.  Perhaps you should elaborate what
is implied by this statement.


Page 16:
   "A target SHOULD NOT silently discard data and request retransmission
   through R2T.  Initiators MUST NOT perform any score boarding for data
   and the residual count calculation is to be performed by the targets.
   Incoming data is always implicitly solicited. SCSI Data packets are
   matched to their corresponding SCSI commands by using Tags that are
   specified in the protocol."

Here again the meaning is a bit vague so could you elaborate what is meant
by score boarding.  I assume tracking a data sequence is still required?  If
there are any errors within a data transfer, the entire transfer is repeated
via a reissue of command with a different CmdSN?  How would you maintain
sequential processing upon a data error?  See comment for Page 84.


 Page 18:
     "- IPv4 address, in dotted decimal notation.  Assumed if the
      name contains exactly four numbers, separated by dots (.),
      where each number is in the range 0..255.
      - IPv6 address, in dotted decimal notation.  Assumed if the
      name contains more than four, but at most 16 numbers, separated
      by dots (.), where each number is in the range 0..255.
      - Fully Qualified Domain Name (FQDN - host name).  Assumed if
      the <domain-name> is neither an IPv4 nor an IPv6 address."

As an alternative to 16 decimal to binary conversions for IPv6, the use of
square brackets as a convention together with hexadecimal representations
would reduce the overhead associated with processing these IP values. See
RFC 2373. Both could be done for IPv4 and IPv6 to allow immediate
recognition of either an IP address or a domain name.


 Page 84:
   "At initiator, the following cases lend themselves to within-
   connection recovery:

      (1)Lost iSCSI numbered Response recognized by either receiving
      it with a data digest error or receiving a Response PDU with a
      higher StatSN than expected. The initiator MAY request the
      missing responses through SACK, in which case the target MUST
      reissue them.
      (2)Requests not acknowledged for a long time. Requests are
      acknowledged explicitly through ExpCmdSN or implicitly by
      receiving data and/or status. The initiator MAY reissue non-
      acknowledged commands. The reissued, non-acknowledged commands
      MUST carry their original CmdSN and the X (retry) flag set to
      1.  Please note that this is the only case in which the
      reissued command will carry the same CmdSN.
      N.B. While the original connection for a command is still
      "active" (has not been logged-out or restarted), any command
      MUST be retried only on the original connection. After logging
      out the original connection, commands can be retried on a
      different connection, but must still carry the original CmdSN."

A long time is vague and why is a timeout out of scope?  This goes to the
comment I made for immediate delivery.  Of course only commands sequenced
can be acknowledged via ExpCmdSN.  Once a command has been acknowledged,
there is no means to maintain sequence upon a transport error that requires
retransmission of the command as a means of recovery.  It is possible to
create a transport that allows recovery without loss of sequence.  Already,
iSCSI is layered under a framing/TCP/WN/PDU.  You have three layers above
your PDUs but still no PDU sequence integrity.

Doug