Subject: iSCSI - positive data ack - change proposal

From: "Julian Satran" <[email-masked]>
Date: Sat, 22 Sep 2001 14:04:34 +0300

Dear colleagues,

As  I mentioned earlier all the elements needed for positive data-ack are
already in place.

I am suggesting the following changes to the document to reintroduce the
data-ACK.

Comments?

Julo
(See attached file: ack.txt)

Within 2.2.2.3
---------------

Initiators MAY also acknowledge received data and reduce by this the resources a target needs to dedicate to data recovery if target and initiator support this type of recovery.

------
3.7.1 F (Final) Bit

For outgoing data, this bit is 1 for the last PDU of unsolicited data or the last PDU of a sequence answering an R2T.

For incoming data, this bit is 1 for the last input (read) data PDU of a sequence.  Input can be split in several sequences each one having it's own F bit. Splitting in sequences does not affect DataSN counting on Data-In PDUs but MAY be used as a "change direction" indication for Bidirectional operations that need such a change and/or end of recoverable sequences by targets with a limited retransmission buffer.  Upon receiving an Data-In PDU with the F set to 1 and the S bit 0 in a session with ErrorRecoveryLevel 1 or higher the initiator MUST issue a DataACK type of SNACK indicating the next expected DataSN for this task.

For Bidirectional operations, the F bit is 1 both for the end of the input sequences as well as the end of the output sequences. 

-----------

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, Data or R2T PDUs requested by a SNACK have to be delivered as exact replicas of the ones the initiator missed including all its flags. 

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".

SNACK is also used to positively acknowledge Data-In PDUs.

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
2-DataACK - positively acknowledges Data-In PDUs 

All other values are reserved.

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

For a Data/R2T SNACK or a DataACK, 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".

If an initiator operates at ErrorRecoveryLevel 1 or higher it MUST issue a SNACK of type DataACK after receiving a Data-In PDU with the F bit set to 1 and the S bit 0.

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.

---

From: Michael Schoberg <[email-masked]>
Date: Tue, 25 Sep 2001 10:42:25 -0500

I'm in favor of Santosh's proposal of numbering all T->I messages and using
ExpStatSN (or just ExpSN) as a positive ACK.  This is very close to what I
was trying to accomplish with the separate ACK queues, but has the added
benefit of not introducing more complexity.  We already have [ExpStatSN /
StatSN] and modifying the definition slightly to include all T->I messages
is QED.

SNACK can continue to be used as a negative ACK for the initiator to request
retransmission of T->I messages.  For that, I see no reason for SNACK to
distinguish what type of message the initiator is requesting.  Rather, SNACK
will refer only to the SN of the lost T->I message(s).

: -----Original Message-----
: From: Julian Satran [mailto:[email-masked]]
: Sent: Tuesday, September 25, 2001 10:03 AM
: To: [email-masked]
: Subject: RE: iSCSI - positive data ack - change proposal
: 
: 
: Rod,
: 
: My English is not that good Rod. What I meant to say about 
: the NOP is that
: it does not convey information (it can't be used by itself as 
: an ack!).
: 
: I can understand that ack is seldomly needed but we can 
: certainly improve
: targets (make them less expensive) by having it.
: 
: I can understand also that data (for real applications) could 
: be rebuilt.
: 
: But you should not get the list into believing that there is a simple
: alternative.
: 
: 
: Julo
: 
: 
:                                                               
:                                  
:                     "Rod Harrison"                            
:                                  
:                     <rod.harrison@wind       To:     Julian 
: Satran/Haifa/IBM@IBMIL,            
:                     river.com>                
: <[email-masked]>                                
:                     Sent by:                 cc:              
:                                  
:                     [email-masked].       Subject:     RE: 
: iSCSI - positive data ack -      
:                     edu                       change proposal 
:                                  
:                                                               
:                                  
:                                                               
:                                  
:                     25-09-01 15:09                            
:                                  
:                     Please respond to                         
:                                  
:                     "Rod Harrison"                            
:                                  
:                                                               
:                                  
:                                                               
:                                  
: 
: 
: 
: Julian,
: 
:            The NOP mechanism is awkward, no question, but I 
: wasn't thinking
: it
: was something we should specify and mandate. Rather it is something
: that a target might do under extreme, and hopefully unlikely
: conditions.
: 
:            - Rod
: 
: -----Original Message-----
: From: [email-masked] [mailto:[email-masked]]On Behalf Of
: Julian Satran
: Sent: Tuesday, September 25, 2001 1:02 PM
: To: [email-masked]
: Subject: RE: iSCSI - positive data ack - change proposal
: 
: 
: Matthew,
: 
: I can fix the text and the ack for the last - we can dispense with,
: but
: unlike we gather more support we will have to drop this.   I think
: that the
: NOP mechanism is awkward but is awkward and as the target shares the
: penalty for SNAK it has no real incentive to the F bit in every PDU.
: 
: Julo
: 
: 
: 
:                     "BURBRIDGE,MATTH
:                     EW                     To:     Julian
: Satran/Haifa/IBM@IBMIL,
:                     (HP-UnitedKingdo        [email-masked]
:                     m,ex2)"                cc:
:                     <matthew_burbrid       Subject:     RE: iSCSI -
: positive data ack -
:                     [email-masked]>              change proposal
: 
:                     24-09-01 12:38
:                     Please respond
:                     to
:                     "BURBRIDGE,MATTH
:                     EW
:                     (HP-UnitedKingdo
:                     m,ex2)"
: 
: 
: 
: 
: 
: Julian
: 
: This looks good!
: 
: A couple of comments:
: 
: Please could you add a paragraph to state that a target does not
: necessarily
: need to wait for the acknowledgment of a sequence before starting
: transmission of the next sequence - for performance reasons.
: 
: In section 3.7.1 it states that "Upon receiving an Data-In PDU with
: the F
: set to 1 in a session with ErrorRecoveryLevel 1 or higher the
: initiator
: MUST
: issue a DataACK type of SNACK indicating the next expected DataSN for
: this
: task".  Is this true for all incoming data sequences including the
: final
: sequence of the transfer?
: 
: Cheers
: 
: Matthew
: 
: 
: -----Original Message-----
: From: Julian Satran [mailto:[email-masked]]
: Sent: Sunday, September 23, 2001 2:46 AM
: To: [email-masked]
: Subject: Re: iSCSI - positive data ack - change proposal
: 
: 
: Here is updated version (in the previous I had excluded the sequences
: ended
: with Status with no good reason.
: 
: Julo
: 
: (See attached file: ack.txt)
: 
: ----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 -----
: 
: 
: 
:                     Julian Satran
: 
:                                          To:     [email-masked]
: 
:                     22-09-2001           cc:
: 
:                     14:04                From:   Julian
: Satran/Haifa/IBM@IBMIL
:                                          Subject:     iSCSI - positive
: data
: ack - change
:                                           proposal
: 
: 
: 
: 
: 
: 
: 
: 
: 
: 
: Dear colleagues,
: 
: As  I mentioned earlier all the elements needed for positive data-ack
: are
: already in place.
: 
: I am suggesting the following changes to the document to reintroduce
: the
: data-ACK.
: 
: Comments?
: 
: Julo
: 
: **** Attachment ack.txt has been removed from this note on 23
: September
: 2001 by Julian Satran ****
: 
: 
: 
: 
: 
: 
: 
: