Subject: iSCSI: Clarification (again) for Task Management Commands

From: "Somesh Gupta" <[email-masked]>
Date: Fri, 9 Nov 2001 13:54:33 -0800

Resend to add iSCSI tag. Sorry for missing it.

On page 67 of the 8-92.txt draft (section 3.5.1), it
says

"For all the tasks covered by the task 
management response (i.e., with CmdSN not higher than the task 
management command CmdSN), additional responses MUST NOT be delivered 
to the SCSI layer after the task management response."

If there is a multiple connection session,
a status for a command impacted by the task
management command (say ABORT TASK SET) could
be stuck in the pipe on one connection, while
the ABORT TASK SET completes on another
connection.

How does the initiator iSCSI enforce the rule above?
Seems to be the equivalent of sending the impacted
commands on other connections in a zombie state,
and not having a very good idea of how to get out.

Similarly Section 9.4 provides additional rules,
but seems to leave a hole open with regards to
status already in flight on other connections.

Any clarifications would be appreciated.

Somesh

---

From: [email-masked]
Date: Fri, 9 Nov 2001 22:25:07 -0500

Somesh,

What do you have in mind?  In practice, completion of any
command sent after the aborted "zombies" serves as a "flushing"
event for the connection on which that command is sent; if
the Initiator is reasonably busy, I think the "flushing"
occurs fairly quickly.

An initiator can also selectively fall back to the FCP-like
technique of explicitly issuing a task abort for the "zombie"
it wants to recover on the appropriate connection.

Thanks,
--David

> -----Original Message-----
> From: Somesh Gupta [mailto:[email-masked]]
> Sent: Friday, November 09, 2001 10:26 PM
> To: [email-masked]; [email-masked]
> Subject: RE: iSCSI: Clarification (again) for Task Management Commands
> 
> 
> David,
> 
> In iSCSI the multiple connection/session construct 
> adds significant complexity in determining whether
> a response for a command (on a different connection
> than the one on which the task management command
> was sent) impacted by the task management command will
> be received or not - and when?
> 
> On a single connection, or similar links, when the
> response for the task management command is
> received (or after a fixed additional time), no
> responses will be received for the commands aborted
> by the task management command.
> 
> However, with multiple connections there is no
> such "flushing" event on connections other than the
> one on which the task management command was sent.
> 
> I would hope that the protocol would address this
> situation - the current response seems to be be to
> put the task tag and some associated resources in
> a zombie state for an unspecified amount of time.
> 
> Somesh
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Friday, November 09, 2001 6:53 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: iSCSI: Clarification (again) for Task 
> Management Commands
> > 
> > 
> > Somesh,
> > 
> > The language in question reflects fairly direct requirements
> > language to be found in SAM-2's description of SCSI Task Management.
> > FCP goes to serious lengths with FC sequence aborts to make sure
> > this behaves as required.
> > 
> > For iSCSI, if responses to the aborted commands show up 
> unexpectedly,
> > they have to be discarded.  How the Initiator keeps track of that
> > is the Initiator's problem - keeping track of the CmdSN of the
> > Abort Task Set may be useful.
> > 
> > --David
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > [email-masked]       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > > -----Original Message-----
> > > From: Somesh Gupta [mailto:[email-masked]]
> > > Sent: Friday, November 09, 2001 4:55 PM
> > > To: IPS
> > > Subject: iSCSI: Clarification (again) for Task Management Commands
> > > 
> > >

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 10 Nov 2001 17:22:36 +0200

David,

I think that readers will want to consider 9.4 as an  implementation 
alternative.

Julo

[email-masked]
Sent by: [email-masked]
10-11-01 04:53
Please respond to Black_David

        To:     [email-masked], [email-masked]
        cc: 
        Subject:        RE: iSCSI: Clarification (again) for Task Management Commands

Somesh,

For iSCSI, if responses to the aborted commands show up unexpectedly,
they have to be discarded.  How the Initiator keeps track of that
is the Initiator's problem - keeping track of the CmdSN of the
Abort Task Set may be useful.

--David

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 10 Nov 2001 17:27:35 +0200

----- Forwarded by Julian Satran/Haifa/IBM on 10-11-01 17:28 -----

Julian Satran
10-11-01 17:26

        To:     <[email-masked]>
        cc: 
        From:   Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI: Clarification (again) for Task Management Commands

Read 9.4 for one implementation - Julo

"Somesh Gupta" <[email-masked]>
Sent by: [email-masked]
10-11-01 05:26
Please respond to somesh_gupta

        To:     <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: iSCSI: Clarification (again) for Task Management Commands

David,

Somesh

---

From: "Somesh Gupta" <[email-masked]>
Date: Mon, 12 Nov 2001 17:46:05 -0800

Julian,

Section 9.4 does (or so I can figure)
leave the sort of hole mentioned
below uncovered. On a multiple connection session,
the status for any of the commands effected by
the task management command could already be in
transit on any of the connections by the time the
task management command is received by the target,
and its reception is acknowledged - and then
received by the initiator.

The barrier works well for a single connection
because the command sequence number for the task
management command makes sure that there is nothing
stuck in the "pipe". However, there could be status
"stuck" in the other pipes.

The mechanism David indicated might be the only
way to be sure, which however might require a NOP
on each connection to ensure there is nothing
in the pipe.

Somesh

> From: Julian Satran [mailto:[email-masked]]
> Sent: Saturday, November 10, 2001 7:26 AM
> To: [email-masked]

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 14 Nov 2001 08:38:58 +0200

Somesh,

9.4 makes sure that even commands that dod not arrive yet at the target 
will not generate any additional responses.
The words I added to task management are meant only to clarify how an 
implementation is supposed to handle status that might be still in flight 
- i.e. initiator must mark the task as aborted but keep it patiently (to 
avoid an ITT reuse) untill status arrives (or is certain not to arrive 
anymore).

Julo

14-11-01 04:36

        To:     <[email-masked]>
        cc: 

Julian,

This is probably based more on my ignorance than anything else.
However I would appreciate any clarification that you could
add.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Julian Satran
> Sent: Tuesday, November 13, 2001 9:59 AM
> To: [email-masked]
> I assume you may want to reread 9.4. It works well on any number of
> connections and it handles all commands for which there is a "delivery
> uncertainty". For commands for which the delivery is certain - i.e, they
> have an instantiated Task Block at both initiator and target there is no
> uncertainty either and the implementation of "no more statuses" does not
> raise any special issues wherever their statuses are. The initiator
> portion of the state has to be marked as aborted and kept in place until
> the status arrives.  To clarify this implementation detail I have added
> some words to the relevant part of the Task Management request:

  My reading of SAM-2 indicates that the following 2 things (applicable
  to the commands sent by the initiator which sent the Task Management
  Commands)

  "that a response for a command affected by a Task Management Function
   will not be returned after the response for the Task Management
   Function is returned"

  and the second one is that

  "for commands that have been delivered to the SCSI entity, it is not
   certain whether the response will be returned or not - except that
   the rule above must be valid"

  If my understanding is correct, then I believe there is a hole
  even in 9.4 - and I will take the time to create a scenario.
  If my understanding is not correct, then based on what the
  right mechanism is, I will take another look.

>
> For all these functions, if executed, the Task Management Function
> Response MUST be returned using the Initiator Task Tag to identify the
> operation for which it is responding. All those functions apply to the
> referenced tasks regardless if they are proper SCSI tasks or tagged 
iSCSI
> operations.  Task management commands must be executed as if all the
> commands having a CmdSN lower or equal to the task management CmdSN have
> been received by the target (i.e., have to be executed as if received 
for
> ordered delivery even when marked for immediate delivery).  For all the
> tasks covered by the task management response (i.e., with CmdSN
> not higher
> than the task management command CmdSN), additional responses MUST NOT 
be
> delivered to the SCSI layer after the task management response. This
> requirement implies that the initiator must keep around state until the
> status is received from the target for an aborted task and the
> target MUST
> deliver to the initiator good status for an aborted task.
>
> Julo
>
>
>
>
> 13-11-01 03:46
>         To:     "IPS" <[email-masked]>
>         cc:
unexpectedly,