IP Storage (ips)

rfc-editor | 2 May 2005 20:17

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)

headers

Eddy Quicksall | 2 May 2005 20:52

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

headers

William Studenmund | 3 May 2005 00:49

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

headers

Julian Satran | 4 May 2005 00:14

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, 193 bytes

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

headers

gwendal grignou | 4 May 2005 10:28

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

headers

Eddy Quicksall | 4 May 2005 18:59

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

headers

Eddy Quicksall | 4 May 2005 19:03

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 -----

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

headers

Julian Satran | 4 May 2005 19:31

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

headers

Eddy Quicksall | 4 May 2005 19:47

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 -----

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

headers

Eddy Quicksall | 4 May 2005 19:56

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 -----

From: Julian Satran

To: Eddy Quicksall

Cc: ips <at> ietf.org

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

3	September 2012
3	March 2012
4	February 2011
6	January 2011
1	June 2010
2	October 2009
4	September 2009
2	August 2009
9	June 2009
3	May 2009
11	April 2009
33	March 2009
8	February 2009
1	January 2009
8	November 2008
1	October 2008
19	September 2008
3	August 2008
6	June 2008
5	May 2008
17	April 2008
3	March 2008
1	February 2008
15	January 2008
15	December 2007
7	November 2007
9	October 2007
16	September 2007
18	August 2007
15	July 2007
15	June 2007
15	May 2007
52	April 2007
8	March 2007
16	February 2007
85	January 2007
54	December 2006
28	November 2006
44	October 2006
27	September 2006
43	August 2006
23	July 2006
26	June 2006
37	May 2006
36	April 2006
41	March 2006
22	February 2006
30	January 2006
42	December 2005
42	November 2005
33	October 2005
107	September 2005
92	August 2005
32	July 2005
55	June 2005
52	May 2005
20	April 2005
70	March 2005
40	February 2005
4	January 2005
18	December 2004
35	November 2004
120	October 2004
119	September 2004
124	August 2004
92	July 2004
78	June 2004
90	May 2004
69	April 2004
46	March 2004
111	February 2004
121	January 2004
26	December 2003
82	November 2003
26	October 2003
65	September 2003
70	August 2003
77	July 2003
67	June 2003
51	May 2003
122	April 2003
55	March 2003
107	February 2003
177	January 2003
61	December 2002
32	November 2002
96	October 2002
171	September 2002
229	August 2002
474	July 2002
624	June 2002
537	May 2002
485	April 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31