Subject: RE: [Ips] Target Behavior Clarifications (with corrections)

From: "Pat Thaler" <[email-masked]>
Date: Tue, 18 Apr 2006 16:14:14 -0700

________________________________

From: William Studenmund [mailto:[email-masked]] 
Sent: Tuesday, April 18, 2006 2:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ips] Target Behavior Clarifications (with corrections)

 <snip> 

	2) What should the target behavior be if the initiator sends it
more data than MaxBurstLength?

	3) What should the target behavior be if the initiator sends
more data than FirstBurstLength?

	<JC> I have two options here:

	a)    As per the spec: The target reports the "Incorrect amount
of data" condition if during data output the total data length to output
is greater than FirstBurstLength and the initiator sent unsolicited
non-immediate data but the total amount of unsolicited data is different
than FirstBurstLength. The target reports the same error when the amount
of data sent as a reply to an R2T does not match the amount requested.
(0B/0C/0D - Write Error, Incorrect Amount of Data). This should work.

	The only issue here is that the definition of the sense code
does not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR
- NOT ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says.

I'd say go with what the RFC says. 
<PAT> When we wrote that, IMO, we were mainly addressing the case where
the initiator didn't send enough data because when the command starts we
need to know how much unsolicited data there will be so we can construct
the first R2T. There really is no reason that the initiator should be
sending more than was requested. I have no problem with deciding to do
b) instead of a).

	b)    Treat this as a really bad error and assume that I have an
initiator that does not play well and drop the session and kill the
command.

	I am leaning towards (b). Help!!!

I think (a) is enough. Actually, I think it's not (a) or (b), but (a) or
(a) and (b); I think you really need to do the processing in (a). Even
if you slam the session down, there are internal processing consequences
of (a). :-)

Take care,

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

---

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 24 Apr 2006 04:03:27 -0400

In most cases I feel that if the initiator is going to violate the spec then the connection should just be dropped (a reject or UA could still be used before the drop). I feel this way because to continue after a protocol error will probably lead to other problems that may in fact be more serious.

Also I prefer a reject because these errors are usually detected at the iSCSI layer and for the iSCSI layer to give a UA means more logic to understand the SCSI semantics.

For something like the errors you have mentioned the initiator is not going to correct itself and do it right the 2nd time.

Eddy
  ----- Original Message ----- 
  From: Pat Thaler 
  To: William Studenmund ; [email-masked] 
  Cc: [email-masked] 
  Sent: Tuesday, April 18, 2006 7:14 PM
  Subject: RE: [Ips] Target Behavior Clarifications (with corrections)

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

   <snip> 
    2) What should the target behavior be if the initiator sends it more data than MaxBurstLength?

    3) What should the target behavior be if the initiator sends more data than FirstBurstLength?

    a)    As per the spec: The target reports the "Incorrect amount of data" condition if during data output the total data length to output is greater than FirstBurstLength and the initiator sent unsolicited non-immediate data but the total amount of unsolicited data is different than FirstBurstLength. The target reports the same error when the amount of data sent as a reply to an R2T does not match the amount requested. (0B/0C/0D - Write Error, Incorrect Amount of Data). This should work.

    The only issue here is that the definition of the sense code does not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR - NOT ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says.

  I'd say go with what the RFC says. 
  <PAT> When we wrote that, IMO, we were mainly addressing the case where the initiator didn't send enough data because when the command starts we need to know how much unsolicited data there will be so we can construct the first R2T. There really is no reason that the initiator should be sending more than was requested. I have no problem with deciding to do b) instead of a).

    b)    Treat this as a really bad error and assume that I have an initiator that does not play well and drop the session and kill the command.

  I think (a) is enough. Actually, I think it's not (a) or (b), but (a) or (a) and (b); I think you really need to do the processing in (a). Even if you slam the session down, there are internal processing consequences of (a). :-)

  Take care,

  Bill

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

---

From: Paul Koning <[email-masked]>
Date: Mon, 24 Apr 2006 09:44:12 -0400

>>>>> "Eddy" == Eddy Quicksall <[email-masked]> writes:

 Eddy> In most cases I feel that if the initiator is going to violate
 Eddy> the spec then the connection should just be dropped ...

I agree.  If the other side doesn't do what the spec says, why keep
talking?  There's no reason to believe that will help matters.

The other argument is that error paths for obscure errors should be
simple, otherwise they are likely to be buggy.  Introducing the risk
of bugs into an iSCSI implementation for the sake of supporting broken
partners it not a good tradeoff.

	  paul