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

[Ajit Aryan <digital_aryan@yahoo.com>]

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

Julian Satran wrote:

>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                                                                       
>                      <ni1d@arrl.net>          To:       ips@ece.cmu.edu                                
>                      Sent by:                 cc:                                                      
>                      owner-ips@ece.cmu        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
>