headers
William Studenmund | 1 Apr 2004 04:09

Re: iSCSI: clarification? data-in PDU->command status bit


On Mar 31, 2004, at 2:28 PM, brown, david1 (eng) wrote:

> The language in the iSCSI spec is clear.  The last paragraph of 
> section 3.2
> says that there is no difference between a status and a response.  The 
> last
> paragraph of 3.5.1.5 says that you don't send a response when the 
> data-in
> PDU contains a status.

We must have a different idea of what clear means. Note also that we
were talking about section 10.7.3, not section 3.2 or 3.5.

> Besides, if the developer thought for even a moment about why something
> called StatSN was counting something called a Response PDU, he or she 
> would
> realize that sending a separate response would mangle the StatSN 
> count.  If
> the developer thought about the logic behind phase collapse, he or she 
> might
> realize that the status/response is bundled in with the data PDU in 
> order to
> avoid the need to send it separately.
>
> Even if we assume the developer made the mistake despite reading the 
> specs
> carefully, that doesn't mean the specs are at fault.  It looks like the
> developer ran through at least two red lights and two yellow lights; 
> that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel F. Smith | 1 Apr 2004 21:33
Picon
Favicon

Re: iSCSI: clarification? data-in PDU->command status bit

What you, and very likely other implementors, might like to author is an
Internet Draft with the title "Implementation considerations for iSCSI (RFC
xxxx)" where items that are not explicitly clear are laid down.  IDs are
easy to make and, as far as I know, there are no requirements as to
authorship.  That way the ID can be kept up to date as a kind of
implementors' FAQ while the standard is unchanging.

Daniel Smith
--
IBM Almaden Research Center, K01F/E2, 650 Harry Road, San Jose
CA 95120-6099 USA Phone: +1(408)927-2072

William Studenmund scribed the following, on or around Wed, Mar 31, 2004 at 06:09:41PM -0800:
> 
> On Mar 31, 2004, at 2:28 PM, brown, david1 (eng) wrote:
> 
> >The language in the iSCSI spec is clear.  The last paragraph of 
> >section 3.2
> >says that there is no difference between a status and a response.  The 
> >last
> >paragraph of 3.5.1.5 says that you don't send a response when the 
> >data-in
> >PDU contains a status.
> 
> We must have a different idea of what clear means. Note also that we
> were talking about section 10.7.3, not section 3.2 or 3.5.
> 
> >Besides, if the developer thought for even a moment about why something
> >called StatSN was counting something called a Response PDU, he or she 
> >would
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luben Tuikov | 2 Apr 2004 09:43
Picon
Favicon

RE: iSCSI: clarification? data-in PDU->command status bit

I couldn't agree more.

Plus SAM-2 is prerequisite to any attempt at implementing or even reading
and understanding iSCSI.

I understand that there _could_ be some confusion to someone totally
unfamiliar with SCSI and iSCSI, but we cannot accomodate for all those
"confusions" -- we might as well copy SAM-2 right in (and then there'd
still be confusions :-) ).

The spec is consistent, and for completeness SAM-2 is a prerequisite --
iSCSI need not be changed for this.

--

-- 
Luben

P.S. From SAM-2's perspective, why would someone send status for a task
twice when the task's lifetime ended when the 1st status was received?
From iSCSI's perspective, StatSN window has moved, as DJ pointed out.

--- "brown, david1  (eng)" <brown_david1 <at> emc.com> wrote:
> The language in the iSCSI spec is clear.  The last paragraph of section 3.2
> says that there is no difference between a status and a response.  The last
> paragraph of 3.5.1.5 says that you don't send a response when the data-in
> PDU contains a status.  
> 
> Besides, if the developer thought for even a moment about why something
> called StatSN was counting something called a Response PDU, he or she would
> realize that sending a separate response would mangle the StatSN count.  If
> the developer thought about the logic behind phase collapse, he or she might
(Continue reading)

Permalink | Reply | 574 comments |
headers
Luben Tuikov | 2 Apr 2004 22:03
Picon
Favicon

Re: iSCSI: clarification? data-in PDU->command status bit

--- William Studenmund <wrstuden <at> wasabisystems.com> wrote:
> 
> I believe you (and a few others) missed the point of misunderstanding.
> The misunderstanding I was referring to was not that you can't send
> status twice, it was that you can't send a SCSI Command Response
> PDU that doesn't carry status; 
> sending status is the sole purpose of the PDU.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I believe that this statement (underlined above) is pretty clear to
everyone, or at least it _should_ be pretty clear to an engineer.
I don't think an _engineer_ can miss it.

I think this thread didn't start with this misunderstanding. I believe it
started with the fact that a broken target sent SCSI status twice, 1st as
part of READ and 2nd as part of SCSI Response.

> Thus once you've sent status, the PDU is neither needed
> nor appropriate. As the SCSI Command Response PDU is an iSCSI
> concept, no amount of reference to SAM-2 will help the situation.

Returning status and response _is_ a SAM thing.  iSCSI as an interconnect
has to accomodate it and stipulate how it implements it.

The reference in SAM-2 is 5.1 Service Response, and 5.3.1 Status, those
are exactly iSCSI 10.4.2 and 10.4.3.

The iSCSI reference is 3.2, first paragraph, 3.1 second last paragraph and
3.5.1.2 SCSI Response for exact mapping and of course 10.4 SCSI Response.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Black_David | 2 Apr 2004 18:55

RE: iSCSI: clarification? data-in PDU->command status bit

> Adding a "MUST" will make things clear.

This will be done.  Thanks, --David (with WG chair hat on).

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: William Studenmund [mailto:wrstuden <at> wasabisystems.com] 
> Sent: Wednesday, March 31, 2004 5:00 PM
> To: Julian Satran
> Cc: Black_David <at> emc.com; ips <at> ietf.org; David.Weibel <at> Sun.COM
> Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command 
> status bit
> 
> 
> On Mar 31, 2004, at 9:33 AM, Julian Satran wrote:
> 
> 
> > read the errata - julo
> 
> Uhm, Julian, this whole thread has been in response to the errata. I
> fail to see how "read the errata" will change my mind.
> 
> "If Status is sent with the data it MUST not be sent again  
> with a SCSI
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Studenmund | 2 Apr 2004 23:51

Re: iSCSI: clarification? data-in PDU->command status bit

On Apr 2, 2004, at 12:01 PM, Luben Tuikov wrote:

> --- William Studenmund <wrstuden <at> wasabisystems.com> wrote:
>>
>> I believe you (and a few others) missed the point of misunderstanding.
>> The misunderstanding I was referring to was not that you can't send
>> status twice, it was that you can't send a SCSI Command Response
>> PDU that doesn't carry status;
>> sending status is the sole purpose of the PDU.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I believe that this statement (underlined above) is pretty clear to
> everyone, or at least it _should_ be pretty clear to an engineer.
> I don't think an _engineer_ can miss it.

I actually just reviewed the spec, and it can be missed. It's never
spelled out. It's strongly inferred, but it's never stated (that there
is no reason for the PDU without status).

> I think this thread didn't start with this misunderstanding. I believe 
> it
> started with the fact that a broken target sent SCSI status twice, 1st 
> as
> part of READ and 2nd as part of SCSI Response.

I agree that we are talking about a target that sent status as part
of a READ and then sent a SCSI Response. However the initial
part of this thread indicated to me that the confusion was about what
the SCSI Response PDU was (not) needed for. If the confusion
had been that status was being sent twice, then all of the references
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Studenmund | 2 Apr 2004 19:17

Re: iSCSI: clarification? data-in PDU->command status bit


On Apr 1, 2004, at 11:43 PM, Luben Tuikov wrote:

> I couldn't agree more.
>
> Plus SAM-2 is prerequisite to any attempt at implementing or even 
> reading
> and understanding iSCSI.
>
> I understand that there _could_ be some confusion to someone totally
> unfamiliar with SCSI and iSCSI, but we cannot accomodate for all those
> "confusions" -- we might as well copy SAM-2 right in (and then there'd
> still be confusions :-) ).
>
> The spec is consistent, and for completeness SAM-2 is a prerequisite --
> iSCSI need not be changed for this.

I believe you (and a few others) missed the point of misunderstanding.
The misunderstanding I was referring to was not that you can't send
status twice, it was that you can't send a SCSI Command Response
PDU that doesn't carry status; sending status is the sole purpose of
the PDU. Thus once you've sent status, the PDU is neither needed
nor appropriate. As the SCSI Command Response PDU is an iSCSI
concept, no amount of reference to SAM-2 will help the situation.

To be honest, I am puzzled as to why this argument has gone on so long.
This misunderstanding made it into code that was put up for interop
testing. The other side of the interop testing didn't feel sufficiently
bolstered as to just quote a section number to resolve the issue. When
raised on this list, a number of us said, "Yes, that can be made
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eddy Quicksall | 3 Apr 2004 21:08
Picon

Re: iSCSI: clarification? data-in PDU->command status bit

How could you send a SCSI Response without either sending status or target
failure?

If you want to clear something up, how about clearing this up too?

   If a SCSI Response PDU does not arrive before the session is

   terminated, the SCSI service response is SERVICE DELIVERY OR TARGET

   FAILURE.

"If a SCSI Response PDU...". In the case of Data In carrying status, a SCSI
Response PDU has not been sent so the sentence leads to ambiguity (actually
that is also OK if one were to use some common sense).

   A non-zero response field indicates a failure to execute the command

   in which case the Status and Sense fields are undefined.

Why is this referring the "Sense field". There is no such field in the PDU.
It probably should be changed to "Status and Flags fields are undefined".

Eddy

----- Original Message ----- 
From: "William Studenmund" <wrstuden <at> wasabisystems.com>
To: "Luben Tuikov" <ltuikov <at> yahoo.com>
Cc: "Black, David" <Black_David <at> emc.com>; <ips <at> ietf.org>;
<David.Weibel <at> Sun.COM>; "brown, david1 (eng)" <brown_david1 <at> emc.com>;
"Julian Satran" <Julian_Satran <at> il.ibm.com>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eddy Quicksall | 4 Apr 2004 02:47
Picon

Re: What iSNS servers are available for interop testing?

There is an open source version but the last I tried it, it was not up to
date. The location is: http://sourceforge.net/projects/linuxisns/ An
alternative site is http://www.nishansystems.com/iSNS/index.html

The Microsoft server can be found on their web site and it works.

Eddy
----- Original Message ----- 
From: <kevin_lemay <at> agilent.com>
To: <ips <at> ietf.org>
Sent: Thursday, March 25, 2004 1:50 PM
Subject: [Ips] What iSNS servers are available for interop testing?

I am looking for iSNS servers for interop testing with our client.

Please let me know if you have a current iSNS server that you would be
willing to share.

Thank you,

Kevin Lemay

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

_______________________________________________
Ips mailing list
Ips <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Studenmund | 5 Apr 2004 02:19

Re: iSCSI: clarification? data-in PDU->command status bit


On Apr 3, 2004, at 11:08 AM, Eddy Quicksall wrote:

> How could you send a SCSI Response without either sending status or 
> target
> failure?

You can't. The point of this hasn't been that you can, but that people
can get to thinking you can.

> If you want to clear something up, how about clearing this up too?
>
>
>
>    If a SCSI Response PDU does not arrive before the session is
>    terminated, the SCSI service response is SERVICE DELIVERY OR TARGET
>    FAILURE.
>
>
>
> "If a SCSI Response PDU...". In the case of Data In carrying status, a 
> SCSI
> Response PDU has not been sent so the sentence leads to ambiguity 
> (actually
> that is also OK if one were to use some common sense).

That too needs fixing. And it can even more strongly lead to the 
erroneous idea
you always need a SCSI Response PDU. I am though unsure if we still
have time. Julian? David?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane