Subject: [Ips] ABORT TASK vs ABORT TASK SET

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 2 May 2005 14:52:43 -0400

For ABORT TASK SET, the target must wait for all outstanding tags to be responded to.

10.6.2:
         b) Waits for all target transfer tags to be responded to and
            for all affected tasks in the task set to be received.

But that is not mentioned for ABORT TASK. I'm wondering what the rational was for ABORT TASK SET but not ABORT TASK. If the rational is to cover possible race conditions at the initiator (e.g., still transmitting/receiving data but also getting a TMF Complete) then it would seem that the same race should be with ABORT TASK.

Eddy

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: William Studenmund <[email-masked]>
Date: Mon, 2 May 2005 15:49:36 -0700

On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote:

> But that is not mentioned for ABORT TASK. I'm wondering what the 
> rational was for ABORT TASK SET but not ABORT TASK. If the rational is 
> to cover possible race conditions at the initiator (e.g., still 
> transmitting/receiving data but also getting a TMF Complete) then it 
> would seem that the same race should be with ABORT TASK.

My take on this was that you send an ABORT TASK when you know you want 
to kill a task. Chances are you know a lot about what's going on with 
it, so you will be able to clearly deal with internal state issues.

My take on ABORT TASK SET is that while you may use it when you know a 
lot about what's going on, you may also use it when you detect an 
internal consistency error. Think of it as a panic button. You press it 
when you're in trouble.

Take care,

Bill

---

From: Julian Satran <[email-masked]>
Date: Wed, 4 May 2005 01:14:54 +0300

The rational is that Abort task has
to be sent on the connection on which the task was issued and then it is
easy to assure serialization.

That is not the case with task set.

Regards,

Julo

William Studenmund <[email-masked]>

Sent by: [email-masked]

02/05/2005 17:49

To

"Eddy Quicksall" <[email-masked]>

cc

[email-masked]

Subject

Re: [Ips] ABORT TASK vs ABORT TASK SET

On May 2, 2005, at 11:52 AM, Eddy Quicksall wrote:

> For ABORT TASK SET, the target must wait for all outstanding tags
to

> be responded to.

>          b) Waits for all
target transfer tags to be responded to and

when you're in trouble.

Take care,

Bill_______________________________________________

Ips mailing list

[email-masked]

---

From: "gwendal grignou" <[email-masked]>
Date: Wed, 4 May 2005 01:28:06 -0700

Julian,

You have a valid point for Abort Task, but what about LUN RESET?

It can impact tasks on all connections of the session where the TASK
Management Request has been sent [I am not talking about other sessions],
but according to the iSCSI RFC, the initiator that issued the LUN RESET is
not bound to send an answer for all outstanding tags. It just says:

"For the LOGICAL UNIT RESET function, the target MUST behave as
dictated by the Logical Unit Reset function in [SAM2]."

Couldn't we have a race condition? Depending on the timing, the target may
or may not received DataOut PDUs with F bit or DataACK for outstanding tags
impacted by the LUN RESET in same the session where the LUN RESET has been
issued, but issued on different connections...

Do you expect the target to send a NOP In on all other connections to
"collect" all remaining SNACK and DataOUT PDUs?

Regards,
Gwendal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian
Satran
Sent: Tuesday, May 03, 2005 3:15 PM
To: William Studenmund
Cc: [email-masked]; Eddy Quicksall; [email-masked]
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

The rational is that Abort task has to be sent on the connection on which
the task was issued and then it is easy to assure serialization. 
That is not the case with task set. 

Regards, 
Julo 

Take care,

---

From: "Eddy Quicksall" <[email-masked]>
Date: Wed, 4 May 2005 13:03:12 -0400

Julian,

I may have missed this but I can't find anything in the spec that says it must be synchronized ... i.e., that the initiator must not continue to send data PDU's for the task after issueing the ABORT TASK.

Did I miss something?

Eddy
  ----- Original Message ----- 
  From: Julian Satran 
  To: William Studenmund 
  Cc: [email-masked] ; Eddy Quicksall ; [email-masked] 
  Sent: Tuesday, May 03, 2005 6:14 PM
  Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

  The rational is that Abort task has to be sent on the connection on which the task was issued and then it is easy to assure serialization. 
  That is not the case with task set. 

  Regards, 
  Julo 

        William Studenmund <[email-masked]> 
        Sent by: [email-masked] 
        02/05/2005 17:49 
       To "Eddy Quicksall" <[email-masked]>  
              cc [email-masked]  
              Subject Re: [Ips] ABORT TASK vs ABORT TASK SET 

  Take care,

------------------------------------------------------------------------------

---

From: Julian Satran <[email-masked]>
Date: Wed, 4 May 2005 12:31:44 -0500

The initiator can be in one of two states:

abort is finished - the using the ITT
for data packets is no legal (by initiator)

initiator has not yet sensed the abort
as being ended - then the target will discard the data if it has already
executed the abort or process them if not.

In any case  there is no race neither
at initiator nor at target due to the synchronization of abort after the
task.

Julo

"Eddy Quicksall"
<[email-masked]>

04/05/2005 12:03

To

Julian Satran/Haifa/IBM@IBMIL, <[email-masked]>

cc

Subject

Julian,

I may have missed this but I can't find anything in the
spec that says it must be synchronized ... i.e., that the initiator must
not continue to send data PDU's for the task after issueing the ABORT TASK.

Did I miss something?

Eddy

----- Original Message -----

From: Julian
Satran

To: William
Studenmund

Cc: [email-masked]
; Eddy
Quicksall ; [email-masked]

Regards,

Julo

02/05/2005 17:49

To

"Eddy Quicksall"
<[email-masked]>

cc

[email-masked]

Subject

to

when you're in trouble.

Take care,

Ips mailing list

[email-masked]

Ips mailing list

[email-masked]

---

From: "Eddy Quicksall" <[email-masked]>
Date: Wed, 4 May 2005 13:47:28 -0400

For ABORT TASK SET the target must wait for all commands effected by the TMF to be received. But what if the very reason for the TMF was because a bad connection is preventing a command from reaching the target? Even if the immediate bit is set on the TMF, the target must wait. This would lead to a dead lock for the session.

Does the following apply to a bad connection (not just to a data digest error) too? That would overcome the dead lock. But then how long does the target wait? If it is too long, the target may get a WARM/COLD RESET. If it is too short, the command may still arrive later.
  In case all or part of the response sequence is not
  received (due to digest errors) for a valid TTT ... [the target] may drop the connection ...

Eddy
  ----- Original Message ----- 
  From: Julian Satran 
  To: William Studenmund 
  Cc: [email-masked] ; Eddy Quicksall ; [email-masked] 
  Sent: Tuesday, May 03, 2005 6:14 PM
  Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

  Regards, 
  Julo 

       

  Take care,

---

From: "Eddy Quicksall" <[email-masked]>
Date: Wed, 4 May 2005 13:56:54 -0400

For the first bullet, I agree this is common sense. But I don't see it in the RFC.

For the second bullet, it looks like a race as to if the target is in the process of sending the response (so the initiator has not sensed it as ended) but the target perceives it as ended. Is it understood that the target does not see it as ended until it gets an ExpStatSN indicating the initiator now sees it as ended?

Eddy
  ----- Original Message ----- 
  From: Julian Satran 
  To: Eddy Quicksall 
  Cc: [email-masked] 
  Sent: Wednesday, May 04, 2005 1:31 PM
  Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

    a.. abort is finished - the using the ITT for data packets is no legal (by initiator) 
    b.. initiator has not yet sensed the abort as being ended - then the target will discard the data if it has already executed the abort or process them if not.

  In any case  there is no race neither at initiator nor at target due to the synchronization of abort after the task. 

  Julo 

        "Eddy Quicksall" <[email-masked]> 
        04/05/2005 12:03 
       To Julian Satran/Haifa/IBM@IBMIL, <[email-masked]>  
              cc  
              Subject Re: [Ips] ABORT TASK vs ABORT TASK SET 

  Julian, 

  Did I miss something? 
    
  Eddy 
  ----- Original Message ----- 
  From: Julian Satran 
  To: William Studenmund 
  Cc: [email-masked] ; Eddy Quicksall ; [email-masked] 
  Sent: Tuesday, May 03, 2005 6:14 PM 
  Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET 

  Regards, 
  Julo 

              

  Take care,

---

From: "Eddy Quicksall" <[email-masked]>
Date: Wed, 4 May 2005 16:42:12 -0400

Actually, SAM-2 basically says this under section 5.6. Sorry about the confusion.

Eddy
  ----- Original Message ----- 
  From: Eddy Quicksall 
  To: Julian Satran 
  Cc: [email-masked] 
  Sent: Wednesday, May 04, 2005 1:56 PM
  Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

  Eddy
    ----- Original Message ----- 
    From: Julian Satran 
    To: Eddy Quicksall 
    Cc: [email-masked] 
    Sent: Wednesday, May 04, 2005 1:31 PM
    Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

    Julo 

         

    Julian, 

    Did I miss something? 
      
    Eddy 
    ----- Original Message ----- 
    From: Julian Satran 
    To: William Studenmund 
    Cc: [email-masked] ; Eddy Quicksall ; [email-masked] 
    Sent: Tuesday, May 03, 2005 6:14 PM 
    Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET 

    Regards, 
    Julo 

                

    Take care,

----------------------------------------------------------------------------

----------------------------------------------------------------------------

---

From: Julian Satran <[email-masked]>
Date: Wed, 4 May 2005 15:59:09 -0500

What would you want to see in the RFC
- you are not supposed to use an ITT that you report as aborted.

The only thing needed for the second
is for the target to ignore any data it receives after reporting the end
of abort (and that is what I would consider obvious).

Julo

"Eddy Quicksall"

04/05/2005 12:56

To

Julian Satran/Haifa/IBM@IBMIL

cc

<[email-masked]>

Subject

For the first bullet, I agree this is common sense. But
I don't see it in the RFC.

For the second bullet, it looks like a race as to if the
target is in the process of sending the response (so the initiator has
not sensed it as ended) but the target perceives it as ended. Is it understood
that the target does not see it as ended until it gets an ExpStatSN indicating
the initiator now sees it as ended?

Eddy

----- Original Message -----

From: Julian
Satran

To: Eddy
Quicksall

Cc: [email-masked]

In any case  there is no race neither at initiator nor at target due
to the synchronization of abort after the task.

Julo

"Eddy Quicksall"

04/05/2005 12:03

To

Julian Satran/Haifa/IBM@IBMIL,
<[email-masked]>

cc

Subject

Julian,

I may have missed this but I can't find anything in the spec that says
it must be synchronized ... i.e., that the initiator must not continue
to send data PDU's for the task after issueing the ABORT TASK.

Did I miss something?

Eddy

----- Original Message -----

From: Julian
Satran

To: William
Studenmund

Cc: [email-masked]
; Eddy

Regards,

Julo

02/05/2005 17:49

To

"Eddy Quicksall"

cc

[email-masked]

Subject

to

when you're in trouble.

Take care,

Ips mailing list

[email-masked]

Ips mailing list

[email-masked]

Ips mailing list

[email-masked]

---

From: Julian Satran <[email-masked]>
Date: Wed, 4 May 2005 15:59:09 -0500

Yes - that would be a decent implementation
choice. Julo

"Eddy Quicksall"

04/05/2005 12:47

To

"William Studenmund" <[email-masked]>,
Julian Satran/Haifa/IBM@IBMIL

cc

<[email-masked]>, <[email-masked]>

Subject

For ABORT TASK SET the target must wait for all commands
effected by the TMF to be received. But what if the very reason for the
TMF was because a bad connection is preventing a command from reaching
the target? Even if the immediate bit is set on the TMF, the target must
wait. This would lead to a dead lock for the session.

Does the following apply to a bad connection (not just
to a data digest error) too? That would overcome the dead lock. But then
how long does the target wait? If it is too long, the target may get a
WARM/COLD RESET. If it is too short, the command may still arrive later.

In case all or part of the response sequence is
not

received (due to digest errors) for a valid TTT ... [the target]
may drop the connection ...

Eddy

----- Original Message -----

From: Julian
Satran

To: William
Studenmund

Cc: [email-masked]
; Eddy

Regards,

Julo

02/05/2005 17:49

To

"Eddy Quicksall"

cc

[email-masked]

Subject

to

when you're in trouble.

Take care,

Ips mailing list

[email-masked]

Ips mailing list

[email-masked]

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 5 May 2005 18:42:31 -0400

I guess this deserves an answer. The RFC is explicit in so many places that people take the absence of a fact as the presence of the opposite (not well said but I think you know what I mean).

So, I figured the RFC could say something like "The initiator MUST NOT transfer any data after it has seen the response to the TMF and the target MUST NOT and can free its resources after it has seen the completion of the TMF by virtue of ExpStatSN" (but a bit more elegant wording).

Eddy
  ----- Original Message ----- 
  From: Julian Satran 
  To: Eddy Quicksall 
  Cc: [email-masked] 
  Sent: Wednesday, May 04, 2005 4:59 PM
  Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET

  What would you want to see in the RFC - you are not supposed to use an ITT that you report as aborted. 
  The only thing needed for the second is for the target to ignore any data it receives after reporting the end of abort (and that is what I would consider obvious). 

  Julo 

        "Eddy Quicksall" <[email-masked]> 
        04/05/2005 12:56 
       To Julian Satran/Haifa/IBM@IBMIL  
              cc <[email-masked]>  
              Subject Re: [Ips] ABORT TASK vs ABORT TASK SET 

    
    
  Eddy 
  ----- Original Message ----- 
  From: Julian Satran 
  To: Eddy Quicksall 
  Cc: [email-masked] 
  Sent: Wednesday, May 04, 2005 1:31 PM 
  Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET 

  Julo 

              

  Julian, 

  Did I miss something? 
   
  Eddy 
  ----- Original Message ----- 
  From: Julian Satran 
  To: William Studenmund 
  Cc: [email-masked] ; Eddy Quicksall ; [email-masked] 
  Sent: Tuesday, May 03, 2005 6:14 PM 
  Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET 

  Regards, 
  Julo 

              

  Take care,

---

From: Julian Satran <[email-masked]>
Date: Thu, 5 May 2005 21:38:29 -0500

I ahve a hard time understanding why
this is necessary. ITT is the primary indicator of a task existence (that
is specified). It is also obvious (and specified) that ITT must be a valid
value in output packets. All the rest follows.

Julo

"Eddy Quicksall"

05/05/2005 17:42

To

cc

<[email-masked]>

Subject

I guess this deserves an answer. The RFC is explicit in
so many places that people take the absence of a fact as the presence of
the opposite (not well said but I think you know what I mean).

So, I figured the RFC could say something like "The
initiator MUST NOT transfer any data after it has seen the response to
the TMF and the target MUST NOT and can free its resources after it has
seen the completion of the TMF by virtue of ExpStatSN" (but a bit
more elegant wording).

Eddy

----- Original Message -----

From: Julian
Satran

To: Eddy
Quicksall

Cc: [email-masked]

What would you want to see in the RFC - you are not supposed to use an
ITT that you report as aborted.

The only thing needed for the second is for the target to ignore any data
it receives after reporting the end of abort (and that is what I would
consider obvious).

Julo

"Eddy Quicksall"

04/05/2005 12:56

To

cc

<[email-masked]>

Subject

For the first bullet, I agree this is common sense. But I don't see it
in the RFC.

For the second bullet, it looks like a race as to if the target is in the
process of sending the response (so the initiator has not sensed it as
ended) but the target perceives it as ended. Is it understood that the
target does not see it as ended until it gets an ExpStatSN indicating the
initiator now sees it as ended?

Eddy

----- Original Message -----

From: Julian
Satran

To: Eddy
Quicksall

Cc: [email-masked]

Julo

"Eddy Quicksall"

04/05/2005 12:03

To

cc

Subject

Julian,

Did I miss something?

Eddy

----- Original Message -----

From: Julian
Satran

To: William
Studenmund

Cc: [email-masked]
; Eddy

Regards,

Julo

02/05/2005 17:49

To

"Eddy Quicksall"

cc

[email-masked]

Subject

to

when you're in trouble.

Take care,

Ips mailing list

[email-masked]

Ips mailing list

[email-masked]

Ips mailing list

[email-masked]

Ips mailing list

[email-masked]

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 06 May 2005 17:28:27 -0700

Gwendal,

You raise an interesting question.

 > "collect" all remaining SNACK and DataOUT PDUs?

We required the TTT drainage in the spec because it makes target 
implementations simpler and it generally minimizes the chances for bugs. 
   It turns out that the drainage behavior is beneficial for iSCSI/iSER 
as well.  I do not believe however that it is strictly required for 
correctness (assuming a correct target implementation).  But.....

The other two elements of the approach (receiving all commands before 
acting, and confirming all StatSN acks before sending the final 
response) are required for correctness depending on the scope of the TMF 
request.  Your question made me realize that the spec doesn't state this 
explicitly in regards to LU Reset, and Target Resets.  This is 
concerning to me.  I do not like the possibility of a naive (but 
technically compliant) multi-connection target implementation allowing 
the LU Reset TMF response to pass the "success" task responses of the 
same I_T_L nexus on other connections.

As an aside, I also noticed in reading bullet (b) of target behavior 
("Waits for all target transfer tags to be responded to and...") that it 
is probably more than what's strictly needed.  I believe waiting for all 
TTTs for the I_T_L nexus in question should suffice for task set TMFs.

I think it'd be a good idea to elaborate on LU Reset, and the two 
flavors of Target Reset in a formal IETF doc.

Thanks!

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 31 May 2005 16:23:50 -0700

Responding to my own comment (since I seem to have done such a fine job 
of "aborting" this email thread).....

> flavors of Target Reset in a formal IETF doc.

I am concerned that the current lack of detailed specification would
allow targets that might even cause silent data corruptions to qualify 
as RFC 3720-compliant.

Here are what I believe to be semantics applicable to all TMF requests
that can potentially terminate multiple tasks.  I do not know the IETF 
process well enough here, but I suggest that we consider this text 
replacing the existing section 10.6.2 in RFC 3720 - so the new text can 
cover all the TMFs that can impact multiple tasks.  This is basically a 
superset of the current 10.6.2 semantics.

Comments are welcome.

Mallikarjun

-----------------------------------------------------------------------

10.6.2.  Task Management Actions on Requests Affecting Multiple Tasks

The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, 
TARGET WARM RESET, and TARGET COLD RESET Task Management function 
requests consists of the following sequence of actions in the
specified order on each of the entities.

The initiator:
a) Issues ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT RESET/TARGET
    WARM RESET/TARGET COLD RESET request.
b) Continues to respond to each target transfer tag received
    for the "affected" (*) tasks.
c) Receives any responses that the target may provide for some
    tasks among the affected tasks (may process them as usual
    because they are guaranteed to be valid).
d) Receives the task management response, thus concluding
    all the tasks in the set of affected tasks.

The Target:

a) Receives the ABORT TASK SET/CLEAR TASK SET/LOGICAL UNIT
    RESET/TARGET WARM RESET/TARGET COLD RESET request.
b) Waits for all currently valid target transfer tags of the
    affected tasks to be responded.
c) Based on the CmdSN ordering, waits (concurrent with the
    wait in step (b)) for all commands of the affected tasks
    to be received.  In the case of target-scoped requests
    (i.e. TARGET WARM RESET and TARGET COLD RESET), all the
    commands that are not received, as at the end of step (b),
    in the command stream however can be considered to have
    been received with no command waiting period - i.e. the
    entire CmdSN space upto the CmdSN of the task management
    function can be "plugged" (refer section 6.9 on how aborting
    a specific task can implicitly plug the CmdSN of the task
    being aborted) at the end of step (b).
d) Propagates the TMF request to and receives the response
    from the target SCSI layer.
e) Takes note of last-sent StatSN on each of the connections
    in the iSCSI session(s) (one or more) sharing the affected
    tasks, and waits for acknowledgement of each StatSN (may
    solicit for acknowledgement by way of a NOP-In). If some
    tasks originate from non-iSCSI I_T_L nexi then the means by
    which the target insures that all affected tasks have
    returned their status to the initiator are defined by the
    specific non-iSCSI transport protocol(s).
f) Sends the task set management response to the issuing
    initiator.

[*] "affected" tasks:
       ABORT TASK SET: All outstanding tasks for the I_T_L nexus
                       identified by the LUN field in the ABORT TASK SET
                       task management function.
       CLEAR TASK SET: All outstanding tasks in the task set for the LU
                       identified by the LUN field in the CLEAR TASK SET
                       task management function.
       LOGICAL UNIT RESET: All outstanding tasks from all initiators for
                       the LU identified by the LUN field in the LOGICAL
                       UNIT RESET task management function.
       TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from
                       all initiators across all LUs that the issuing
                       session has access to on the SCSI target device
                       hosting the iSCSI session.