iSCSI: data ACKs

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

Consequent to the London consensus on keeping SNACKs in 
the protocol, I believe it is fair to enable targets desirous
of efficiently managing their buffers, by way of a data
acknowledgement request-response mechanism in iSCSI (under
certain constraints, as below) as earlier requested by
Matthew Burbridge on this list.  The current solution of 
allowing targets to re-access the medium to satisfy data 
transfer retransmission presents problems in the following 
cases -
        - any target in general that attempts to prevent
          reaccessing the medium in view of cache management 
          complexities, or wanting to conserve backend SCSI 
          bandwidth (only if the error rate is high).
	- tapes supporting queued commands, that want to 
          free up memory to work on subsequent commands.
	- iSCSI "middle boxes" supporting multiple tape 
	  devices behind, and wanting to decrease buffer
          requirements.
	- the SCSI-legitimate (but perhaps highly unlikely) 
          case of write-after-read to the same LBAs.

I propose the following means to enable a data ACK mechanism
	- target requests an ACK by setting a TBD bit
          (say A-bit, for ACK) on read data PDU.  It MAY
          set the A-bit once at most every MaxBurstSize 
          bytes, and MUST NOT do so any more frequently 
          than that.
        - an initiator generates a SNACK of type "ACK" (per
          Julian's earlier proposal) on reception of an 
          A-bit data PDU.  If there were pending data 
          retransmissions in the burst, the generation of 
          ACK is deferred till the holes are filled.
        - target processes the SNACK and frees up the 
          acknowledged buffers. 

The reason a new A-bit is proposed to be used (in stead of 
the F-bit) is that there may be unrelated reasons for setting 
the F-bit by a target (may be to enable opposite data 
flow for a bidirectional command, for ex.).

I believe that the implementation complexity in the above 
proposal is minimal, while the runtime cost is non-existent
for all "short" (< MaxBurstSize) transfers, and the same
for "long" transfers (> MaxBurstSize) is very reasonable.
You will note that the onus is on targets to generate ACK
requests and process ACKs, if they want to manage their 
buffers efficiently.  Finally, the ack scheme should be 
applicable only to sessions where the operational 
ErrorRecoveryLevel >= 1.

Comments?
-- 
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com