RE: iSCSI - positive data ack - change proposal

[Michael Schoberg <michael_schoberg@cnt.com>]

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:Julian_Satran@il.ibm.com]
: Sent: Tuesday, September 25, 2001 10:03 AM
: To: ips@ece.cmu.edu
: 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>                
: <ips@ece.cmu.edu>                                
:                     Sent by:                 cc:              
:                                  
:                     owner-ips@ece.cmu.       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: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
: Julian Satran
: Sent: Tuesday, September 25, 2001 1:02 PM
: To: ips@ece.cmu.edu
: 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        ips@ece.cmu.edu
:                     m,ex2)"                cc:
:                     <matthew_burbrid       Subject:     RE: iSCSI -
: positive data ack -
:                     ge@hp.com>              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:Julian_Satran@il.ibm.com]
: Sent: Sunday, September 23, 2001 2:46 AM
: To: ips@ece.cmu.edu
: 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:     ips@ece.cmu.edu
: 
:                     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 ****
: 
: 
: 
: 
: 
: 
: 
: