Re: Unsolicited data

["Julian Satran" <Julian_Satran@il.ibm.com>]

Robert,

The warning is not wrong. Variable length unsolicited data might be a
legitimate requirement is some applications.
And a clever target can take care of that by issuing an R2T "in advance"
and fill the gap (if any) later.

However in order to let only consenting initiators and targets do this I
will add the following text to 2.3.5

   If the Expected Data Transfer Length is higher than the FirstBurstSize
   (the negotiated maximum amount of unsolicited data the target will
   accept) the initiator SHOULD send the maximum size of unsolicited data.
   The target MAY terminate in error a command for which the Expected Data
   Transfer Length is higher than the FirstBurstSize and for which the
   initiator sent less than FirstBurstSize unsolicited data.

 In addition 2.4.3 reads:

   This field contains iSCSI service response.

   Valid iSCSI service response codes are:

      0x00 - Command Completed at Target
      0x01 - Target Failure
      0x02 - Delivery Subsystem Failure
      0x03 - Unsolicited data rejected
      0x04 - Not enough unsolicited data
      0x05 - Command in progress
      0x80-0xff - Reserved for Vendor-Unique Responses

   N.B. Response code 0x04 must be used only if the target does not support
   output (write) operations in which the total data length is higher than
   FirstBurstSize but the initiator sent less than first burst size and
   out-of-order R2Ts can't be used.

   The Response is used to report a Service Response. The exact mapping of
   the iSCSI response codes to SAM service response symbols is outside the
   scope of this document.

   Certain response codes MUST be associated by the target with a Check
   Condition Status as outlined in the next table:

   +--------+------------------------------+---------------------------+
   | Code   | Reason                       | with SCSI CHECK CONDITION |
   +--------+------------------------------+---------------------------+
   |0x01    | Target Failure               | ASC = 0x44 ASCQ = 0x00    |
   +--------+------------------------------+---------------------------+
   |0x02    | Delivery Subsystem Failure   | ASC = 0x47 ASCQ = 0x03    |
   +--------+------------------------------+---------------------------+
   |0x03    | Unsolicited data rejected    | ASC = 0x49 ASCQ = 0x00    |
   +--------+------------------------------+---------------------------+
   |0x04    | Not enough unsolicited       | ASC = 0x49 ASCQ = 0x00    |
   +--------+------------------------------+---------------------------+
   |0x05    | SNACK rejected               | ASC = 0x47 ASCQ = 0x03    |
   +--------+------------------------------+---------------------------+

   As listed above, each defined response code MUST be used (under the
   conditions described in the 'Reason' field), only when the corresponding
   SCSI CHECK CONDITION is signaled, to convey additional protocol service
   information.  A SCSI CHECK CONDITION with the ASC and ASCQ values as
   tabulated MUST be signaled by iSCSI targets for all the instances in
   this document referring to usage of one of the above defined response
   codes.

   Please note that a response of "Command Completed at Target" may also be
   associated with an error status.

   The warning will now read:

1.1  Unsolicited data and performance

   Unsolicited data on write are meant to reduce the effect of latency on
   throughput (no R2T is needed to start sending data).  In addition
   immediate data are meant to reduce the protocol overhead (both bandwidth
   and execution time).

   However negotiating an amount of unsolicited data for writes and sending
   less than the negotiated amount when the total data amount to be sent by
   a command is larger than the negotiated amount may negatively impact
   performance and may not be supported by all the targets.

   Regards,
   Julo

"Robert D. Russell" <rdr@mars.iol.unh.edu> on 19-07-2001 20:59:22

Please respond to "Robert D. Russell" <rdr@mars.iol.unh.edu>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Unsolicited data





Julian:

The warning in section 8.6 of draft 06-99 still does not solve the
problem and is in fact wrong.  It now reads:

  "However negotiating an amount of unsolicited data for writes and
   sending less than the negotiated amount when the total data amount to
   be sent by a command is larger than the negotiated amount may
   negatively impact performance as the targets will not be able to ask
   for the remainder of the data."

The problem is, even if the initiator DOES send the full negotiated
amount, the target does NOT know this in advance and therefore cannot
send out the R2T for the rest until getting the unsolicited data PDU
with the F bit set to 1.  In other words, even the very best
implementation of an initiator does NOT solve the problem -- the target
still does NOT know what is coming because the initiator can NOT tell him.
Performance is ALWAYS impacted, regardless of what the initiator does.

The simplest solution would be to REQUIRE the initiator to send
the negotiated amount (after all, if he doesn't want to send that much
every time then why did he negotiate that much?).  Then the target
will know, in advance, what is coming and send out the R2T for the
rest of the data WITHOUT WAITING!  This is where the performance gain
is to be found.

(In all of the above discussion I am assuming the Expected Transfer
Length is greater than the First Burst Size.  The acutal requirement
for sending unsolicited data is that the initiator be required to
send min(Expected Transfer Length, First Burst Size) as unsolicited
data if unsolicited data has been negotiated.)

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774