Re: iSCSI 05.txt is out

[Matt Wakeley <matt_wakeley@agilent.com>]

Matt Wakeley wrote:
> 
> 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
                                    ^d
> 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.
                                       ^ info

> 
> >
> > 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