rfc-editor | 2 May 20:17 2005

RFC 4018 on Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)


A new Request for Comments is now available in online RFC libraries.

        RFC 4018

        Title:      Finding Internet Small Computer Systems Interface
                    (iSCSI) Targets and Name Servers by Using Service
                    Location Protocol version 2 (SLPv2)
        Author(s):  M. Bakke, J. Hufferd, K. Voruganti, M. Krueger,
                    T. Sperry
        Status:     Standards Track
        Date:       April 2005
        Mailbox:    mbakke <at> cisco.com, jlhufferd <at> comcast.net,
                    kaladhar <at> us.ibm.com, marjorie_krueger <at> hp.com,
                    todd_sperry <at> adaptec.com
        Pages:      23
        Characters: 48498
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ips-iscsi-slp-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4018.txt

The iSCSI protocol provides a way for hosts to access SCSI devices
over an IP network.  This document defines the use of the Service
Location Protocol (SLP) by iSCSI hosts, devices, and management
services, along with the SLP service type templates that describe the
services they provide.

This document is a product of the IP Storage Working Group of the
(Continue reading)

Eddy Quicksall | 2 May 20:52 2005
Picon
Picon

ABORT TASK vs ABORT TASK SET

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
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
William Studenmund | 3 May 00:49 2005

Re: 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.
>  
> 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.

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
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Julian Satran | 4 May 00:14 2005
Picon

Re: 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 <wrstuden <at> wasabisystems.com>
Sent by: ips-bounces <at> ietf.org

02/05/2005 17:49

To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI <at> comcast.net>
cc
ips <at> ietf.org
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.
>  
> 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.

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_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

Attachment (PGP.sig): application/octet-stream, 264 bytes
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
gwendal grignou | 4 May 10:28 2005

RE: ABORT TASK vs ABORT TASK SET

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: ips-bounces <at> ietf.org [mailto:ips-bounces <at> ietf.org] On Behalf Of Julian
Satran
Sent: Tuesday, May 03, 2005 3:15 PM
To: William Studenmund
Cc: ips <at> ietf.org; Eddy Quicksall; ips-bounces <at> ietf.org
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 <wrstuden <at> wasabisystems.com> 
Sent by: ips-bounces <at> ietf.org 
02/05/2005 17:49 
To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI <at> comcast.net> 
cc
ips <at> ietf.org 
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.
>  
> 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.

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_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

Eddy Quicksall | 4 May 18:59 2005
Picon
Picon

negotiating more than once

The top of page 55 says this:
 
   Reject or Irrelevant are legitimate negotiation options where allowed
   but their excessive use is discouraged.  A negotiation is considered
   complete when the acceptor has sent the key value pair even if the
   value is "Reject", "Irrelevant", or "NotUnderstood.  Sending the key
   again would be a re-negotiation and is forbidden for many keys.
Take this case:
 
  The initiator says ImmediateData=OK. The target says ImmediateData=Reject.
 
The negotiation is now finished. Since ImmediateData defaults to YES and if the target can't take immediate data then what is the target to do? The only thing would be to close the connection.
 
Does anyone disagree? How about "does anyone agree"?
 
Eddy
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Eddy Quicksall | 4 May 19:03 2005
Picon
Picon

Re: ABORT TASK vs ABORT TASK SET

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 -----
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 <wrstuden <at> wasabisystems.com>
Sent by: ips-bounces <at> ietf.org

02/05/2005 17:49

To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI <at> comcast.net>
cc
ips <at> ietf.org
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.
>  
> 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.

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_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Julian Satran | 4 May 19:31 2005
Picon

Re: ABORT TASK vs ABORT TASK SET


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" <eddy_quicksall_iVivity_iSCSI <at> comcast.net>

04/05/2005 12:03

To
Julian Satran/Haifa/IBM <at> IBMIL, <ips <at> ietf.org>
cc
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET





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: ips <at> ietf.org ; Eddy Quicksall ; ips-bounces <at> ietf.org
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 <wrstuden <at> wasabisystems.com>
Sent by: ips-bounces <at> ietf.org

02/05/2005 17:49


To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI <at> comcast.net>
cc
ips <at> ietf.org
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.
>  
> 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.

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_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Eddy Quicksall | 4 May 19:47 2005
Picon
Picon

Re: ABORT TASK vs ABORT TASK SET

 
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 -----
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 <wrstuden <at> wasabisystems.com>
Sent by: ips-bounces <at> ietf.org

02/05/2005 17:49

To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI <at> comcast.net>
cc
ips <at> ietf.org
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.
>  
> 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.

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_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
Eddy Quicksall | 4 May 19:56 2005
Picon
Picon

Re: ABORT TASK vs ABORT TASK SET

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 -----
Sent: Wednesday, May 04, 2005 1:31 PM
Subject: Re: [Ips] ABORT TASK vs ABORT TASK SET


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" <eddy_quicksall_iVivity_iSCSI <at> comcast.net>

04/05/2005 12:03

To
Julian Satran/Haifa/IBM <at> IBMIL, <ips <at> ietf.org>
cc
Subject
Re: [Ips] ABORT TASK vs ABORT TASK SET





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: ips <at> ietf.org ; Eddy Quicksall ; ips-bounces <at> ietf.org
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 <wrstuden <at> wasabisystems.com>
Sent by: ips-bounces <at> ietf.org

02/05/2005 17:49


To
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI <at> comcast.net>
cc
ips <at> ietf.org
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.
>  
> 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.

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_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips

Gmane