iSCSI - changes - PDULength and related

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

Dear colleagues,

It was the an (almost) general agreement on the list that having a more
flexible "PDULength" would be beneficial.
This can be achieved without dramatically affecting the draft and
implementation.
The areas mostly affected are related to recovery.
The proposed changes are attached (DataPDULength has changed name and
semantic to MaxRecvPDULength).
In addition text request and response key+value strings are not required to
be confined to a single PDU (as we PDULength can be a low as 64 bytes!)

Comments?

(See attached file: changes-PDULength.txt)
PDULength related changes:
__________________________

3.16  SNACK Request


Byte /    0       |       1       |       2       |       3       |
   /              |               |               |               |
  |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
  +---------------+---------------+---------------+---------------+
 0|0|1| 0x10      |1|Rsrvd| Type  | Reserved                      |
  +---------------+---------------+---------------+---------------+
 4/ Reserved                                                      /
 +/                                                               /
  +---------------+---------------+---------------+---------------+
16| Initiator Task Tag or 0xffffffff                              |
  +---------------+---------------+---------------+---------------+
20| BegRun                                                        |
  +---------------+---------------+---------------+---------------+
24| RunLength                                                     |
  +---------------+---------------+---------------+---------------+
28| ExpStatSN                                                     |
  +---------------+---------------+---------------+---------------+
32| Reserved                                                      |
  +---------------+---------------+---------------+---------------+
36| ExpDataSN or Reserved                                         |
  +---------------+---------------+---------------+---------------+
32/ Reserved                                                      /
 +/                                                               /
  +---------------+---------------+---------------+---------------+
48

Support for SNACK is optional.

SNACK request is used to request retransmission of numbered-responses, data or R2T PDUs from the target.  The SNACK request indicates to the target the missed numbered-response or data run, where the run is composed of an initial missed StatSN, DataSN or R2TSN and the number of additional missed Status, Data or R2T PDUs (0 means only the initial).

The numbered-response or R2T requested by a SNACK have to be delivered as exact replicas of the ones the initiator missed including all its flags. 

The numbered Data-In PDUs individually requested by a SNACK have to be delivered as exact replicas of the ones the initiator missed including all its flags.  Data-In PDUs requested with RunLength 0 (meaning all after this number) may be different from the ones originally sent in order to reflect changes in MaxRecvPDULength. 

Any SNACK requesting a numbered-response, Data or R2T that was not sent by the target MUST be rejected with a reason code of "Invalid SNACK".


3.16.1 Type

This field encodes the SNACK function as follows:

0-Data/R2T SNACK - requesting retransmission of a Data-In or R2T PDU
1-Status SNACK - requesting retransmission of a numbered response

All other values are reserved.

Data/R2T SNACK for a command MUST precede status acknowledgement for the given command.

For a Data/R2T SNACK the Initiator Task Tag MUST be set to the Initiator Task Tag of the referenced Command. Otherwise, it is reserved.

For a Status SNACK the ExpDataSN field is reserved.

An iSCSI target that does not support recovery within connection MAY discard status SNACK. If the target supports command recovery within session it MAY discard the SNACK after which it MUST issue an Asynchronous Message PDU with an iSCSI event indicating "Request Logout".

3.16.2 BegRun

First missed DataSN, R2TSN or StatSN

3.16.3 RunLength

RunLength is the number of sequential missed DataSN, R2TSN or StatSN. RunLength 0 signals that all Data-In, R2T or Response PDUs carrying numbers equal or greater to BegRun have to be resent.

The first data SNACK after a Task Management request of TASK REASSIGN (see 3.5.1) for a command whose connection allegiance was just changed MUST use RunLength "0" to request retransmission of any number of PDUs (including one).  The number of retransmitted PDUs in this case, may or may not be the same as the original transmission, depending on if there was a change in MaxRecvPDULength in the reassignment.

The first data SNACK after a MaxRecvPDULength decrease for a command issued on the same connection before the change in MaxRecvPDULength MUST use RunLength "0" to request retransmission of any number of PDUs (including one).  The number of retransmitted PDUs in this case, may or may not be the same as the original transmission, depending if the loss was before or after the MaxRecvPDULength was senses at the target or not.

----------------------
23 MaxRecvPDULength

Use: All
Who can send: Initiator and Target

MaxRecvPDULength=<0|number-64-to-2**24> 

Default is 8192 bytes.

This is a connection specific parameter.
Initiator or target declares the maximum data segment length in bytes they can receive in an iSCSI PDU. 

A value of 0 indicates no limit.

24 MaxBurstSize

Use: LO
Who can send: Initiator and Target

MaxBurstSize=<0|number-64-to-2**24> 

Default is 256 Kbytes.

Initiator and target negotiate maximum SCSI data payload in bytes in an Data-In or a solicited Data-Out iSCSI sequence (a sequence of Data-In or Data-Out PDUs ending with a Data-In or Data-Out PDU with the F bit set to one). 

A value of 0 indicates no limit (the largest possible number).

The minimum of the 2 numbers is selected. 


25 FirstBurstSize

Use: LO
Who can send: Initiator and Target

FirstBurstSize=<0|number-64-to-2**24>  

Default is 64 Kbytes.

Initiator and target negotiate the maximum amount in bytes of unsolicited data an iSCSI initiator may send to the target, during the execution of a single SCSI command. This covers the immediate data (if any) and the sequence of unsolicited Data-Out PDUs (if any) that follow the command.

A value of 0 indicates no limit (the largest possible number).

The minimum of the 2 numbers is selected. 

FirstBurstSize MUST NOT exceed MaximumBurstSize.