Subject: Re: ISCSI: need to fix handling of partial data transfers

From: "Julian Satran" <[email-masked]>
Date: Thu, 14 Mar 2002 13:11:12 +0200

I was under the impression that all over SCSI an initiator sending less
data than requested by a target is tolerable.
from a SCSI point if view but it is not always tolerable at device level.
I will change the wording to better convey this - i.e. choosing another
error code for failing on the FirstBurstSize and not meeting the Desired
Data Length ( "Not Enough Data" instead of "Protocol Error") and attach the
corresponding SCSI error status and sense (as we did with data errors).
Is this acceptable?

Julo

                      Paul Koning                                                                       
                      <[email-masked]>          To:       [email-masked]                                
                      Sent by:                 cc:                                                      
                      [email-masked]        Subject:  ISCSI: need to fix handling of partial data    
                      .edu                      transfers                                               

                      13-03-02 19:11                                                                    
                      Please respond to                                                                 
                      Paul Koning                                                                       

Here's a point I mentioned before, but it got mixed up in the debate
over the "PDU sector alignment" proposal and wasn't resolved.  So here
it is again, standalone.

There are several places in the protocol where one end specifies a
quantity of data that it would like to see.  Currently, the spec
allows the amount of data transfered to be less than what was asked
for, BUT it also allows the recipient of that data to complain
("Protocol error") if what is received is less than what was asked
for.

In other words, the spec explicitly allows conforming implementations
that do not interoperate.

I do not believe this makes any sense.  Failure to interoperate due to
an implementation bug I can understand: if that happens you fix the
code.  But it is not at all reasonable for the spec to permit one end
to send a sequence of protocol messages, and then permit the other end
to reply to that CONFORMING sequence with the reply "Protocol error".

In particular:

R2T specifies Desired Data Transfer Length.  Section 9.8 allows the
initiator to reply with less than that amount, and it then allows the
target to call that a protocol error.

Similarly, section 9.3.5 allows an initiator to send less than
FirstBurstSize unsolicited data even when the total transfer length is
more than that, yet it allows the target to reject such transfers.

These need to be changed.  There are two possible fixes:

1. Tighten up the initiator rules to require the initiator to send
precisely the requested amount (i.e., Desired Data Transfer Length in
response to R2T, and the negotiated FirstBurstSize as unsolicited
data) rather than an arbitrary amount <= that amount.  In other words,
in the 4th paragraph of 9.3.5 change "SHOULD" to "MUST"; in the 3rd
paragraph of 9.8  change "MUST not exceed" to "MUST exactly equal" and
before "If the last PDU..." insert "The total amount of data sent by
the initiator must exactly equal the Desired Data Transfer Length."

2. Alternatively, tighten up the target rules, requiring the target to
accept as valid and correct transfers less than the amount requested.
In other words, in the 4th paragraph of 9.3.5 replace the last
sentence by "The target MUST accept a command for which the Expected
Data Transfer Length is higher than the FirstBurstSize and for which
the initiator sent less than the FirstBurstSize unsolicited data."; in
the 3rd paragraph of 9.8 change "If the last PDU..." to "If the last
PDU (marked with the F bit) is received before the Desired Data
Transfer Length is transferred, a target MUST accept that as a valid
response to the R2T PDU."

On grounds of simplicity I prefer solution 1, but I can support either
as a valid fix of the current problem.

    paul

---

From: Ajit Aryan <[email-masked]>
Date: Thu, 14 Mar 2002 17:52:21 +0530

Sounds good.
But I felt, "Not Enough Data" sounds generic.
Can we make it. "Insufficient Data Received" ??
Comments?
Aryan

---

From: Paul Koning <[email-masked]>
Date: Thu, 14 Mar 2002 09:55:08 -0500

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

 Julian> I was under the impression that all over SCSI an initiator
 Julian> sending less data than requested by a target is tolerable.
 Julian> from a SCSI point if view but it is not always tolerable at
 Julian> device level. 

I'm not sure that this is true.  Looking at the SCSI specs for
guidance, I find a few words on this topic in SAM-2 (section 5.4.3,
"Data transfer protocol services").  This mentions as one of the
transfer parameters "Byte count requested by device server: number of
bytes to be moved by the data transfer request".  It doesn't say
"maximum number of bytes...".  Also, the confirmation primitives for
the Send Data-In and Receive Data-Out primitives both indicate
completion, but do not indicate an actual byte count, which again
suggests that the actual byte count is supposed to match the requested
byte count.

 Julian> I will change the wording to better convey
 Julian> this - i.e. choosing another error code for failing on the
 Julian> FirstBurstSize and not meeting the Desired Data Length ( "Not
 Julian> Enough Data" instead of "Protocol Error") and attach the
 Julian> corresponding SCSI error status and sense (as we did with
 Julian> data errors).  Is this acceptable?

It's better than what we have now, because the status code you
proposed no longer implies that there's a bug in the implementation.

I still don't like it much.  It's very ugly to have options in the
protocol where, in the middle of a long session, you suddenly get a
reject from the other side because you did something the protocol
allows that the other end doesn't support (and is allowed not to
support). 

It would be far better to resolve this one way or the other and take
away the unnecessary interoperability failures.  So I much prefer
either to require the initiator to do exactly what the target asked
for (as implied by SAM-2) or, failing that, to require the target to
accept shorter responses from the initiator -- as I proposed before.

But if we're going to use this third approach, which is to leave in
the option to reject, it would be much better if that is announced at
login so the initiator will know what the target wants, and can adjust
what it sends accordingly -- or can abandon the login if it is unable
to comply with the target's requirements.

     paul