RE: iSCSI: aborting an immediate command with ABORT TASK

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

I think that whole confusion is the result of some missing words.
The missing words are the that you cannot have RefCmdSN reffer to something
equal or higher than the ABORT TASKS CmdSN.
It is implied in the section 2 text (about the scope of commands) but not
explicit. I will add a word about ASAP.

the text I suggest for 9.5.5 is:

       For the ABORT TASK function, initiators MUST always set this to the
       CmdSN of the task identified by the Referenced Task Tag field.
       Targets must use this field as described in section 9.6.1 when the
       task identified by the Referenced Task Tag field is not with the
       target. RefCmdSN MUST be lower than the Task Management Request
       CmdSN field (in serial arithmetic sense).


As for immediate commands and RefCmdSN - my comment was that a missed
immediate command is missed forever!
The RefCmdSN will not help you when it is missing since an immediate commad
does not generate a hole!

Julo



                                                                                                                                                
                      Eddy Quicksall                                                                                                            
                      <eddy_quicksall@i        To:       Julian Satran/Haifa/IBM@IBMIL                                                          
                      vivity.com>              cc:       "'Black_David@emc.com'" <Black_David@emc.com>, ips@ece.cmu.edu, owner-ips@ece.cmu.edu, 
                                                tonyb@cybernetics.com                                                                           
                      05/09/02 16:38           Subject:  RE: iSCSI: aborting an immediate command with ABORT TASK                               
                                                                                                                                                
                                                                                                                                                
                                                                                                                                                



I don't see that fact when I read the spec. 9.5.5 RefCmdSN implies that the
RefCmdSN may be used if the Referenced Task Tag (ITT) is not with the
target anymore. And, I think that is David and Tony's point.

I may have missed it someplace ... can you please point out where it says
or implies "an immediate is aborted based on ITT"?

Eddy
      -----Original Message-----
      From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
      Sent: Thursday, September 05, 2002 9:23 AM
      To: Eddy Quicksall
      Cc: 'Black_David@emc.com'; Eddy Quicksall; ips@ece.cmu.edu;
      owner-ips@ece.cmu.edu; tonyb@cybernetics.com
      Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


      No need - it works always as it is. An immediate is aborted based on
      ITT or not at all.
      Add to it the fact that they are on the same connection and
      immediates are not reassigned
      and everything works AS IS.
      What am I missing?

      Julo

                                                                           
   Eddy Quicksall                                                          
   <eddy_quicksall@iviv         To:        Julian Satran/Haifa/IBM@IBMIL,  
   ity.com>             Eddy Quicksall <eddy_quicksall@ivivity.com>        
                                cc:        "'Black_David@emc.com'"         
                        <Black_David@emc.com>, ips@ece.cmu.edu,            
   05/09/02 16:02       owner-ips@ece.cmu.edu, tonyb@cybernetics.com       
                                Subject:        RE: iSCSI: aborting an     
                        immediate command with ABORT TASK                  
                                                                           
                                                                           
                                                                           




      How about another bit in the abort that says it is aborting an
      immediate command and hence does not advance the window?

      Eddy
      -----Original Message-----
      From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
      Sent: Thursday, September 05, 2002 9:00 AM
      To: Eddy Quicksall
      Cc: 'Black_David@emc.com'; ips@ece.cmu.edu; owner-ips@ece.cmu.edu;
      tonyb@cybernetics.com
      Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


      I don't think we want to. The TM made immediate are done so with good
      reason - to allow expedited consideration.
      And there are no known scenarios (to us) in which it does not work.

      Julo
                                                                           
   Eddy Quicksall                                                          
   <eddy_quicksall@ivivity.co        To:        "'Black_David@emc.com'"    
   m>                         <Black_David@emc.com>, tonyb@cybernetics.com 
   Sent by:                                                                
   owner-ips@ece.cmu.edu             cc:        ips@ece.cmu.edu            
                                     Subject:        RE: iSCSI: aborting   
                              an immediate command with ABORT TASK         
   05/09/02 15:46                                                          
                                                                           
                                                                           





      Can we say that aborts with the immediate bit only abort commands
      with the
      immediate bit? And then say that the window is not advanced under
      that
      situation?

      Eddy

      -----Original Message-----
      From: Black_David@emc.com [mailto:Black_David@emc.com]
      Sent: Thursday, September 05, 2002 2:51 AM
      To: tonyb@cybernetics.com
      Cc: ips@ece.cmu.edu
      Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


      This thread's taken a while to sort through, but there
      does appear to be a problem in here.

      > If the missing command was non-immediate, then yes, the plug-in
      avoids
      > having to resend the missing command.  But, if the missing command
      was
      > immediate, then there is no hole to plug.  In this case, the spec
      requires
      > the target to plug a hole which does not exist, which is the
      problem that
      I
      > am trying to point out.

      I'm working off of -15.  Section 2.2.2.1 contains the following
      statements:

                     CmdSN always contains the number to be
          assigned to the next Command PDU.

       Commands meant for immediate delivery are marked with an immediate
       delivery flag; they MUST also carry the current CmdSN.

      So suppose CmdSN is 7, and the initiator sends an immediate command
      with CmdSN 7 and then decides to abort it, and sends TASK ABORT as
      an immediate command (CmdSN is 7 and not advanced).  Suppose the TASK
      ABORT crosses the response to successful completion of the immediate
      command on the wire.  At this point the following text in Section
      9.6.1 applies:

         b)  if the Referenced Task Tag does not identify an existing task
         but if the CmdSN indicated by the RefCmdSN field in the Task Man-
          agement function request is within the valid CmdSN window
      (between
          MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received
          and return the "Function complete" response.

      7 is still the CmdSN of the next non-immediate command to be sent,
      so it is within the window (ExpCmdSN is also 7).  Following these
      directions, the Target considers CmdSN 7 to be received, and advances
      its window.  Now, when the initiator sends its next non-immediate
      command (CmdSN=7), its CmdSN is outside the window, and the target
      bit-buckets the command instead of executing it.

      This went awry because the task to be aborted was (implicitly)
      identified by its CmdSN, and not its Task Tag resulting in an attempt
      to abort an immediate command actually clobbering the next non-
      immediate one.  I think Tony gets credit for finding another problem.

      While I'm in here, it also appears that the text describing the
      mapping of iSCSI task management response codes to SCSI service
      responses needs to change to map 1 (Task does not exist) to
      FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with
      Section 6.2 of SAM-2.

      Thanks,
      --David
      ---------------------------------------------------
      David L. Black, Senior Technologist
      EMC Corporation, 42 South St., Hopkinton, MA  01748
      +1 (508) 249-6449            FAX: +1 (508) 497-8018
      black_david@emc.com       Mobile: +1 (978) 394-7754
      ---------------------------------------------------