Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit

From: "Daniel F. Smith" <[email-masked]>
Date: Thu, 1 Apr 2004 11:33:54 -0800

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
> >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
> >doesn't mean a fifth light would help.
> 
> "Fault" is far stronger a term than I had in mind. I do not think the 
> spec is at "fault,"
> I think there is a point where it can be made more clear. A number of 
> other
> persons have agreed.
> 
> >Besides, such an amendment to the spec at this stage would set a bad
> >precedent.  Should we alter the spec each time some device in beta-test
> >violates the spec, as long as the developer says it's just a
> >misunderstanding?
> 
> Note: this moment is our last chance to change the spec. After the 
> author's
> "48 hours" is done, the iSCSI RFC is done. Any changes require a new
> RFC.
> 
> I see no problem with making a minor, clarifying change at this point 
> in time.
> After all, I thought that was the point.
> 
> I think that any change should be considered on a case-by-case basis. 
> The
> fact that one change was or wasn't made should not impact other changes.
> And if the change makes the spec clearer, in general, why wouldn't we 
> do it?
> 
> [I do concede that we may want to not make the change now just to 
> reduce the
> number of changes, but that is a different criteria :-)  ]
> 
> >If you could find one other person on this mailing list who honestly
> >misunderstood the implications of sending status with a data PDU, it 
> >would
> >strengthen the argument considerably.
> 
> I don't think that criteria is a good one. My concern with it is that 
> it requires
> persons on this list to share the confusion. I'm more concerned with 
> people
> who aren't on the list. The persons who will be using iSCSI in one, 
> two, three,
> or ten years. _I_ am not confused on this point (no SCSI Command 
> Response
> needed with phase-collapsed read), however I can see a place (mentioned
> before) where someone could, unluckily, come away with an incorrect 
> understanding.
> Given that, I can see how either proposed change would improve clarity.
> 
> Take care,
> 
> Bill

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

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 1 Apr 2004 23:43:51 -0800 (PST)

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)" <[email-masked]> 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.  
> 
> 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
> Even if we assume the developer made the mistake despite reading the specs
> developer ran through at least two red lights and two yellow lights; that
> misunderstood the implications of sending status with a data PDU, it would
> DJ Brown
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of William
> Studenmund
> Sent: Wednesday, March 31, 2004 5:00 PM
> To: Julian Satran
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
> Response PDU as this would violate SCSI rules (a single ...."
> 
> David's concern is confusion over "with  a SCSI Response PDU". You (and I
> and DLB and most of the folks on the list) know that means you don't send a
> PDU; you just removed the need. A few people new to the spec, though, seem
> to think you still need to send the SCSI Response PDU, just that it isn't
> carrying SCSI status. Or something like that.
> 
> Adding a "MUST" will make things clear.
> 
> I'd suggest (if we can still make the change) something like:
> 
> "If Status is sent with the data it MUST not be sent again (SCSI Response
> PDU MUST not be sent) as this would violate SCSI rules (a single ...."
> 
> Take care,
> 
> Bill
>

---

From: Luben Tuikov <[email-masked]>
Date: Fri, 2 Apr 2004 12:03:04 -0800 (PST)

--- William Studenmund <[email-masked]> 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.

Also it is important to understand _why_ "once you've sent status,
the PDU is neither needed nor appropriate".

> To be honest, I am puzzled as to why this argument has gone on so long.

I agree, it should've ended immediately as "broken implementation of
a target -- tell them to fix it".

I think that most of those misunderstandings are due to ppl not paying
enough attention or not reading the whole spec.  Some of them just read
the PDU description and off they go implementing iSCSI.

> 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 
> better."
> We are (or were earlier this week) in a period when such small, 
> clarifying
> changes are appropriate. So why not make it better?

I really don't see why whenever someone implements a buggy iSCSI
Target/Initiator, it is immediately the fault of the iSCSI spec. In fact
I contend that 99.9% if the time it's the other way around.

-- 
Luben

---

From: William Studenmund <[email-masked]>
Date: Fri, 2 Apr 2004 09:17:57 -0800

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.

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Sat, 3 Apr 2004 14:08:22 -0500

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" <[email-masked]>
To: "Luben Tuikov" <[email-masked]>
Cc: "Black, David" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "brown, david1 (eng)" <[email-masked]>;
"Julian Satran" <[email-masked]>
Sent: Friday, April 02, 2004 12:17 PM
Subject: Re: [Ips] iSCSI: clarification? data-in PDU->command status bit

---

From: William Studenmund <[email-masked]>
Date: Sun, 4 Apr 2004 17:19:02 -0700

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

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

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

I'd suggest something like "If SCSI Status (either SCSI Response PDU or
DATA IN with status) ...".

> It probably should be changed to "Status and Flags fields are 

Indeed.

Take care,

Bill