iSCSI-07: recovery

[sandeepj@research.bell-labs.com (Sandeep Joshi)]

Comments/questions on new Appendix F and related Section 7.x
These are arranged sequentially down the appendix.

-Sandeep

1) Page 173: What is the usage of nextCmdSN in the Connection 
   structure ?

   If it is being used to check gaps, something like this 
   seems more appropriate to the Session and not Connection.

2) Page 174: Within-command recovery
   Initiator algo for Recover-Data-If-Possible

   The step of sending an abort here could be skipped if 
   the initiator knew that task has already completed at the 
   target.   This avoids an extra task cmd & response 
   (Function-complete)

   The initiator knows the task has completed if this routine 
   is invoked on an expDataSN mismatch in a SCSI Response 
   (middle of page 175)

3) Top of Page 175: Within-command recovery 
   Initiator algo for Receive-a-In-PDU

   When SoFarInOrder is False, and current DataSN is expected 
   (its the next) then the action seems to be "discard; return".
   Is this correct ?  So when does one *accept* the next 
   DataSN (say 9) in the presence of outstanding missing data 
   PDUs (say 4-6)

4) Page 175-176: Within-command recovery 
   Initiator algo for Receive-a-In-PDU

   The psuedo-code under "Connection.SoFarInOrder is TRUE"
   could be moved to Within-Connection recovery since the logic 
   applies to all other PDUs (not just SCSI response) sent from 
   target bearing statSNs.

5) Page 177 : Within-command recovery
   Target algo for Receive-a-In-PDU
  
   Please confirm, can the target use R2T for digest errors on 
   unsolicited bursts ?   If yes, can we add an explicit statement 
   to this effect.  Neither Section 7.4.(a) nor this section 
   seem to imply otherwise but just want to confirm.

6) Page 177 : Within-command recovery
   Target algo for Receive-a-In-PDU

   Bottom of the case for "if (CurrentPDU.type=DATA)"
   we have "if (TCB.activeR2Ts=0) Build-and-send-Status()"

   This needs an extra predicate as follows..
     "If TCB.Response=DeliveryFailure && TCB.ActiveR2Ts=0"

   This is correct in Transfer-Context-Timeout-Handler.

7) Page 179 : Within-connection recovery
   Initiator algo for Recover-Status-If-Possible

   Typo error..  "note the missing statSNs in TCB"
   should be     "note the missing statSNs in Connection"

   statSN list is per-connection state.

8) Page 180: Within-Connection recovery
   Initiator algo for Command-Acknowledge-Timeout-Handler
   
   This function seems like a better fit for the previous 
   section on "within-command-recovery" and could be moved 
   over there.

9) Page 184 : Within-Session recovery
   Target algo for Receive-A-In-PDU

   It does not cover the case of receiving a login-restart 
   (implicit logout).  This would have the same action as 
   "logout.reason=recoveryRemove"