Subject: Re: UNH Plugfest

From: "Julian Satran" <[email-masked]>
Date: Tue, 12 Feb 2002 10:33:18 +0200

Bob,

Comments in text -

Thanks,
Julo

"Robert D. Russell" <[email-masked]>
12-02-02 02:49

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        UNH Plugfest

Julian:

Attached are some of the issues that arose during the first day
of the iSCSI plugfest at UNH on Monday 11-February-2001.

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

--------------------------------------------------------------------------

1a)The following operational keys are labeled with "Use: ALL" and have
   session-wide applicability:
       InitialR2T
       BidiInitialR2T
       ImmediateData

   This means that they can be negotiated during the login phase for
   any connection in a session, as well as during full feature phase on
   any connection in a session, but at the successful conclusion of that
   negotiation, the results apply immediately to all connections in
   the session.

   The question is: "What is the rationale for making these 3 keys
   session-wide instead of connection-specific?"

   Phrased another way, the question is: "Would it not be better if these
   keys were connection-specific instead of session-wide?"

   In particular, it appears that dynamic changes to these values on one
   connection can have an effect on outstanding commands on other
   connections that requires considerable complication in implementations
   to handle correctly, yet the benefit is not obvious from the standard.

   Could someone please supply a rationale for keeping these keys
   session-wide?

+++

Those key convey propoerties that are specific to the SCSI target (not 
iSCSI transport).
Using R2T means not allocating SCSI buffers for unsolicited commands (that 
you have no idea on what connection they will be comming).

+++

1b)A related issue is that the values negotiated for InitialR2T and
   ImmediateData are intimately intertwined, as evidenced by the
   table accompanying the description of ImmediateData in Appendix D.

   However, InitialR2T has a specific restriction (in the description
   of InitialR2T in Appendix D): "Once InitialR2T has been set to 'no',
   it cannot be set back to 'yes'. BidiInitalR2T has the same restriction.
   But ImmediateData does not have this restriction.

   The question is: "Why doesn't ImmediateData have a similar 
restriction?"

   In particular, this restriction on (Bidi)InitialR2T limits the
   possibilities for (re)negotiation at any time on any connection
   mentioned in 1a above, because once unsolicited data PDUs have been
   negotiated off, they can never be negotiated on again, effectively
   eliminating InitialR2T from all further negotiations.

   Could someone please supply a rationale for allowing ImmediateData to
   be negotiated on/off at any time on any connection but not InitialR2T?

+++

We saw no reason to force the targets to handle the "uncertainty" related 
to the transition from No to Yes of R2T (i.e., when can the target remove 
resources related to the unsolicited data).  We saw a need for a yet-to-no 
transition (speed increase) but none for a no-to-yes.
Immediate data on the other hand has a very restricted and well-defined 
resource need - a single PDU asociated with the command and there is no 
uncertainty in the transition (or very limited).

+++
2. Section 3.11.3 discusses the use of the Target Transfer Tag in the Text
   Response pdu.  It says that when the target has more work to do, it
   MUST set the Target Transfer Tag to some value other than 0xffffffff.
   When the target does not have more work to do, the standard does not
   say what value the Target Transfer Tag should have.  There are 2
   possibilities:

   a. If the target must set the Target Transfer Tag to 0xffffffff,
      then the standard should state this explicitly.
   b. If the target can set the Target Transfer Tag to any value
      (or leave it undefined) then it appears that there is no need to
      reserve 0xffffffff for the Target Transfer Tag at all, and there
      is no need to require a value other than 0xffffffff when F = 0
      (any value will work fine).
+++
The value 0xfffffff should be used exclusively to covey a "soft reset" 
i.e., while the target has more work to do the initiator wnats to start 
fresh
I will try to make clear in the text that if there is no more work to do 
it MUST be set to 0xffffffff

+++

3. Section 3.8.3 limits the value of the Desired Data Transfer Length in
   an R2T to at most MaxBurstSize.  What is the rationale for this?
   An R2T is sent by the target to the initiator, so why can't the
   target specify any size it wants in the R2T?  The target already
   uses R2Ts to control the flow of Data-Out PDUs from the initiator,
   so why impose this restriction on the R2Ts?

   Could someone please explain the benefit to this limitation on R2Ts?

+++ Is this a plugfest question or one of your own?  For your own 
questions the channels are always open.  The MaxBurstSize is there to 
enable the initiator to share resources between several executing commands 
and limit the number of "pending buffers" a target will have to keep
in case one of the Data Out PDUS is damaged and transfer to a device is 
not possible.

+++

4. Section 3.7.1 says that the Data-In pdus sent by the target to satisfy
   a SCSI read command can be split into sequences each terminated by
   a pdu having F=1.  The standard does not seem to require that this
   be done.  However, if it is done, then the description of MaxBurstSize
   in Appendix D limits these sequences to at most MaxBurstSize bytes.

4a.The first question is: "What is the benefit for allowing the
   Data-In pdus to be split into sequences?"

   It appears that doing so forces a dual role on the F-bit -- as end of
   sequence and as end of all input -- and complicates the interpretation
   of this bit in the initiator.  This feature seems to be necessary to
   change direction in bidirectional transfers, but are there other uses
   for this?

+++ End of all input is the satus or Response - no ambiguity +++

4b.The second question is: "Is the target required to split Data-In pdus
   into sequences?"

   If so, this should be made explicit in the standard, and the rationale
   for this should also be given.

+++ It is required and the rational is in 2.4.1.5 (version 10). The 
rational is direction change and Ack if required +++

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 14 Feb 2002 17:11:41 -0500 (EST)

Julian:

The last several days at the UNH plugfest have uncovered no major
issues relating to the standard.

One thing that was observed was that a number of implementations are
dealing with SCSI-2 systems, because most of the world (i.e., Windows)
is still based on SCSI-2.  The iSCSI standard clearly references the
SCSI-3 specifications.  However, perhaps we should consider how iSCSI
could be used with SCSI-2.

In particular, there is the issue of LUNs.  Some implementers are
expecting some SCSI-2 CDBs to carry a LUN number in the 3 high-order
bits of byte 1 in the CDB, and are not setting/using the LUN field
in the iSCSI PDU.  This is clearly wrong, although if both target and
initiator do it, then they interoperate with each other but not with
standard-conformant implementations.

Of course, there may be (and probably are) additional issues (besides
the LUN issue) that may arise.  However, it still might be useful to
warn implementers that this is an issue, and perhaps to suggest a
"conversion rule" that would allow SCSI-2 to interoperate with iSCSI.

One possibility for such a rule follows:

If an iSCSI initiator has to send a SCSI-2 PDU containing a LUN,
it should extract the LUN from the 3 high-order bits of CDB byte 1
and send that in the iSCSI LUN field (unless, of course, it has some
other means of obtaining the LUN value independent of the CDB, in which
case it should send that value in the iSCSI LUN field).

If an iSCSI target receives a SCSI-2 PDU containing a LUN, then if
the iSCSI LUN field is 0 it should extract the LUN value from the
3 high-order bits of CDB byte 1 (which in the SCSI-3 case should always
be 0 anyway) and use that as the LUN value;
if the iSCSI LUN field is not 0 then it should use that as the LUN value.

At first glance this rule seems to allow an initiator and/or a target
to interoperate with both SCSI-2 and SCSI-3 systems.

Comments?

Bob Russell, UNH
Rod Harrison, Wind river

---

From: Santosh Rao <[email-masked]>
Date: Thu, 14 Feb 2002 18:48:23 -0800 (PST)

Bob & Rod,

The LUN field in the SCSI CDB is not used in SCSI-2 devices either. It was
used in SCSI-1 devices. SCSI-2 mandates the use of the IDENTIFY message (for
parallel scsi) to identify the LUN for a given SCSI command.

For other SCSI transports like FC, etc the LUN is encapsulated in the
PDU or IU that carries the SCSI Command. (ex : FCP_CMD, iscsi scsi command pdu,
SRP_CMD, etc).

The SCSI LUN Addressing information for each SCSI command is conveyed from the
SCSI ULP to the SCSI LLP in some per I/O control block passed down from the
SCSI ULP to the SCSI LLP.  (ex : scb, scsi_pkt, Srb, etc).

Are there any O.S. SCSI implementations out there that do not do this and 
instead, send the LUN in the SCSI CDB (?). 

In any case, this sort of recommendation on where the LLP should get its LUN 
addressing information from should belong to the SCSI driver writer's guide 
of that O.S. and not in a protocol specification, IMHO.

Regards,
Santosh

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: "Robert D. Russell" <[email-masked]>
Date: Fri, 15 Feb 2002 08:25:57 -0500 (EST)

> instead, send the LUN in the SCSI CDB (?).

Apparently!

Bob Russell