Re: iSCSI 05.txt is out

[Matt Wakeley <matt_wakeley@agilent.com>]

Venkat Rangan wrote:

> Page 12:
> Remove the sentence:
> "A large difference between StatSN and ExpStatSN may indicate a failed
> connection."
> 
> This may have made sense when StatSN and ExpStatSN are session-wide. Now
> that it is per-connection, this may not be valid. As was pointed out in the
> "Holes in StatSN" thread, ExpStatSN may be "stuck" at a low value when a
> single PDU encountered a Digest Error, followed by several well-formed PDUs.

So, if the connection is not frames (markers, etc), it must still be
terminated in order to recover.  And if it is framed, there will not be a
"stuck" low value...

> Page 24 - Section 2.1
> Add: The length of the PDU SHALL include any padding bytes added.

Agreed.  There is very little padding and how it is conveyed.

> 
> This raises a question as to whether it may be useful to include a two-bit
> "Fill Bytes" field in the header (BHS and AHS) which indicates the number of
> bytes that were added. Without this, it may be harder for the receiver to
> know how many bytes are part of the data. Fibre Channel has the Fill Byte
> specifier in its F_CTL part of the header.
> 
> Page 25:
> This may be covered in another thread.
> 
> What does the first Next-Qualifier (at byte 0) describe? Is it the BHS or
> the header following the BHS? If a PDU has a single BHS and a single AHS, is
> the sequence WN-BHS-AHS or is it WN-BHS-WN-AHS?

(since Julian did not reply), the next qualifier always describes the header
after the following header (I know, it can be confusing - that's why all this
discussion and David Black's message on examples, more info was posted).


> 
> Page 25 and 26:
> The text next to the bit description and the headers in the text for
> sections 2.2.2.1 to 2.2.2.3 appear to be inconsistent.  An example is
> "read-data transfer" vs. "Read Data" "Long Data" vs. "Long Data Transfer"
> 
> Also, 2.2.2.3 appears to have text about Long Data Header that probably
> belongs in section 2.2.2.2 (or I am confused about how WN is supposed to
> work.)
> 
> Page 43
> Section 2.7
> The PDU diagrams should not show "Digests if any..." etc. It should be
> covered by NQ and corresponding AHS.
> 
> Page 44
> Section 2.7.2
> The requirement of having to specify a valid LUN as part of WRITE Data (and
> NOP-Out) may pose unnecessary overhead for Target processing. The fact that
> Targets are now REQUIRED to reject errant initiators who may place a LUN
> inconsistent with the one sent in the CommandPdu means that targets should
> save the LUN against each context entry for the task. This was discussed
> earlier, and I think we said that unless the folks who originally wanted it
> spoke up, we will remove it. Note that Fibre Channel does not have this
> feature, and its original purpose can be accomplished by using Target
> Transfer Tag.

I completely agree.

> If we still want it, targets should be given the option of negotiating this
> so that it can operate in a mode where a LUN specified as part of WRITE data
> will be ignored (as opposed to rejected).
> 
> Section 2.17
> The following text:
> "Within a connection, outstanding R2Ts MUST be fulfilled by the initiator in
> the order in which they were received."
> 
> implies that R2Ts for the same WRITE command may be sent by the target on
> multiple connections?

No. See 1.2.5: "the target MUST return R2T, if any, and the status over
the same TCP connection that was used to deliver the SCSI command."

What this means is that if the initiator receives R2T for command 1, followed
by R2T for command 2, it must send the data for command 1 before command 2.  I
don't know why this is a requirement, it seems like an unnecessary
restriction.

> Since this is not possible, all R2Ts for a command are
> always on a single connection, so I am not sure how the above sentence
> should be interpreted.

-Matt Wakeley
Agilent Technologies