ISCSI: need to fix handling of partial data transfers

[Paul Koning <ni1d@arrl.net>]

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