SCSI: Draft 00 areas of concern.

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

To whom it may concern;

Pg 7:
   "iSCSI initiators MUST implement the command/request numbering scheme
   only if they support more than one connection per session (as even
   sessions with a single connection may be expanded beyond one
   connection).

   Command numbering for sessions that will only be made up of one
   connection is optional. iSCSI initiators utilizing a single
   connection for a session and not utilizing command numbering MUST
   indicate that they will not support command numbering by setting
   InitCmdRN to 0 in Login command."

This prevents the target a means of modifying the number of commands that
can be sent from the initiator.  This could lead to a dead-lock should
communications buffers become filled.  As recovery is facilitated with
multiple TCP connections, the single connection implementation is not likely
being fully considered.

This also explains the lack of concern for connection failure detection.
The default keep-alive connection timeouts for most OS implementations is 2
hours so a specific recommendation should be made to alter this setting.
There should also be a specific specification rather than "short time" as
indicated in section 4.3 on page 62 for reestablishing a connection.  For
this transport to work reliably using a single connection, a connection
failure must be done by means of the ULP.  The use of a NOP-Ping once every
10 seconds during a period inactivity while status or data is pending is a
reasonable means of testing the connection.  The overhead is 51 bits/second
during these rare critical periods.  This should allow connection failure
detection within 40 seconds for recovery within Section 1.2.3 timeouts.  To
make this a negotiated value, perhaps T4 could be added as connection probe
interval during inactivity with T1, T2 or T3 pending.


Pg 10:
   "Once the initiator is authorized to do so, the iSCSI session is in
   iSCSI full feature phase. The initiator may send SCSI commands and
   data to the various LUNs on the target by wrapping them in iSCSI
   messages that go over the established iSCSI session.  For SCSI
   commands that require data and/or parameter transfer, the (optional)
   data and the status for a command must be sent over the same TCP
   connection that was used to deliver the SCSI command (we call this
   "connection allegiance").  Thus if an initiator issues a READ
   command, the target must send the requested data, if any, followed by
   the status to the initiator over the same TCP connection that was
   used to deliver the SCSI command.  If an initiator issues a WRITE
   command, the initiator must send the data, if any, for that command
   and the target MUST return the status over the same TCP connection
   that was used to deliver the SCSI command.  However consecutive
   commands that are part of a SCSI linked commands task MAY use
   different connections - connection allegiance is strictly per-command
   and not per-task. During iSCSI Full Feature Phase, the initiator and
   target MAY interleave unrelated SCSI commands, their SCSI Data and
   responses, over the session."

Pg 61:

"4.1 Connection failure

   For any outstanding SCSI command, it is assumed that iSCSI in
   conjunction with SCSI at the initiator is able to keep enough
   information to be able to rebuild the command PDU, that outgoing data
   is available (in host memory) for retransmission while the command is
   outstanding. It is also assumed that at a target iSCSI and
   specialized TCP implementations are able to recover unacknowledged
   data packets from a closing connection or, alternatively the target
   has means to re-read data from a device server.  It is further
   assumed that a target will keep the "status & sense" for a command it
   has executed while the total number of outstanding commands and
   executed commands does not exceed its limit. A target will
   sequentially number the delivered responses and thus enable
   initiators to tell when a response is missing and which response is
   missing.

   Under those conditions, iSCSI will be able to keep a session in
   operation if it is able to keep/establish at least one TCP connection
   between the initiator and target in a timely fashion.  Unfortunately,
   the maximum admissible recovery time is a function of the target and
   for some devices and communications networks recovery may be complex
   and may percolate to upper software layers.  It is assumed that
   targets and/or initiators will recognize a failing connection by
   either transport level means (TCP) or by a gap in the command or
   response stream that is not filled for a long time, or by a failing
   iSCSI ping (the later should be used periodically by highly reliable
   implementations).  Initiators and targets SHOULD use the keep-alive
   option on the TCP connection to enable early link failure detection
   on idle links."

Pg 63:
"5.2 Multiple Network Adapters

   The iSCSI protocol allows multiple connections, not all of which need
   go over the same network adapter. If multiple network connections are
   to be utilized with hardware support, the iSCSI protocol command-
   data-status allegiance to one TCP connection insure that there is no
   need to replicate information across network adapters or otherwise
   require them to cooperate."

Page 61 is in conflict with page 10 and 63.  The connection allegiance does
require adapter cooperation during recovery.  There should be detailed
information as to the recovery interface at the adapter or specifically
requiring status, sense, and idempotent data to be stored globally.  This
can also be solved by removing connection allegiance.  There should be
greater detail of this layer of the protocol as it relates to the NIC.

I wish to expressed a general concern over using hyper-text, name servers,
and connection proxies rather than conventional User Authentication and
Authorization schemes with deterministic routes.  The authorization should
be binary maps needed by the client and server.  The server could be given a
OTP for the client using a standard LDAP. The server would only need to
implement the directory client.  User privileges and device failures should
permit relatively stable schemas.  A proxy at potentially every node can not
be secured without equally extensive authorization information.  A means of
authorizing is missing from this proposal.  Most would not view a user
database contained within the SCSI server as a reasonable solution for
enterprise or larger environments.

Doug