Re: iSCSI: current UNH Plugfest

["Julian Satran" <Julian_Satran@il.ibm.com>]

Bob,

Good work.

My comment in text.

Regards,
Julo




"Robert D. Russell" <rdr@mars.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu
30-10-01 02:44
Please respond to "Robert D. Russell"

 
        To:     ips@ece.cmu.edu
        cc: 
        Subject:        iSCSI: current UNH Plugfest

 


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

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774

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

1. Situation: the very first command sent on a new connection is a
   login.  However, the I bit is not set.  What should the target do?

   Interpretation 1:
   According to section 8.3 page 127 of draft 8,
   "Explicit violations of the PDU layout rules stated in this document
   are format errors."
   "When a target or an initiator receives an iSCSI PDU with a format
   error, it MUST reset all transport connections in the session
   immediately ..."
   This is a format error so section 8.3 applies.  Therefore, the target
   should simply close the connection without sending anything to the
   initiator.

   Interpretation 2:
   This is a login command that contains an error caused by the
   initiator.  Therefore, the target should send back a login response
   with a status code of 0x0200 and then close the TCP connection.

+++ I will change 3.13.5 to explicitly say that class 2 does not cover 
format errors).

2 - Initiator Error (not a format error) - indicates that the initiator 
likely caused the error. This MAY be due to a request for a resource for 
which the initiator does not have permission.  The request should not be 
tried again.

++++
2. Situation: on the first login command in operational parameter 
negotiation
   stage, the initiator sends the keys InitialR2T=yes and ImmediateData=no
   and the target agrees with these values.  Therefore, according to the
   table on page 182 of draft 8, both sides agree that unsolicited data
   is disallowed.  These keys are then followed, either later in the keys
   associated with this same login command or in a subsequent login 
command
   belonging to the same login phase, with the key FirstBurstSize=6.
   What should the target do?

   Interpretation 1:
   FirstBurstSize indicates "the maximum amount of unsolicited data an
   iSCSI initiator may send to the target during the execution of a
   single SCSI command, in units of 512 bytes."  However unsolicited data
   is now disallowed, so FirstBurstSize is irrelevant.  Therefore, no
   response is necessary -- the key is just ignored.

   Interpretation 2:
   In section 2.2.4 on page 30 of draft 8 it says "For numerical
   negotiations, the responding party MUST respond with the required key."
   Since FirstBurstSize is a numerical key, the target MUST respond with
   a numeric value ("reject" is not allowed for numerical keys), even if
   the value is irrelevant and will not be used.

++++

I suggest adding the "irrelevant" and 0r constants to 2.2.4 as follows:

During login and thereafter some session or connection parameters are 
negotiated through an exchange of textual information.

The initiator starts the negotiation through a Text/Login request and 
indicates when it is ready for completion (by setting to 1 and keeping to 
1 the F bit in a Text/Login request).

All negotiations are stateless - i.e. the result MUST be based only on 
newly exchanged values.

The general format of text negotiation is:

Originator-> <key>=<valuex>
Responder-> <key>=<valuey>|NotUnderstood

The value can be a number, a single literal constant a Boolean value (yes 
or no) or a list of comma separated literal constant values.

In literal list negotiation, the originator sends for each key a list of 
options (literal constants which may include "none") in its order of 
preference.

The responding party answers with the first value from the list it 
supports and is allowed to use for the specific originator.

The constant "none" MUST always be used to indicate a missing function. 
However, none is a valid selection only if it is explicitly offered. 

If a responder is not supporting, or not allowed to use with a specific 
originator, any of the offered options, it may use the constant "reject". 

If a specific key is not relevant for the current text negotiation the 
responder may answer with the constant "irrelevant".

The constants "none", "reject" and "irrelevant" are reserved and must be 
used only as described here. 

For numerical and single literal negotiations, the responding party MUST 
respond with the required key and the value it selects, based on the 
selection rule specific to the key, becomes the negotiation result.  If a 
key is irrelevant in the current negotiation, the responder may use the 
special numeric constant 0r.
Selection of a value not admissible under the selection rules is 
considered a protocol error and handled accordingly. 

For Boolean negotiations (keys taking the values yes or no), the 
responding party MUST respond with the required key and the result of the 
negotiation when the received value does not determine that result by 
itself.  The last value transmitted becomes the negotiation result.  The 
rules for selecting the value to respond with are expressed as Boolean 
functions of the value received and the value that the responding party 
would select in the absence of knowledge of the received value.
 
Specifically, the two cases in which responses are OPTIONAL are:

- The Boolean function is "AND" and the value "no" is received. The 
outcome of the negotiation is "no".
- The Boolean function is "OR" and the value "yes" is received. The 
outcome of the negotiation is "yes".

Responses are REQUIRED in all other cases, and the value chosen and sent 
by the responder becomes the outcome of the negotiation.

If a specific key is not relevant for the current Boolean negotiation the 
responder may answer with the constant "irrelevant".

Any key not understood is answered with "NotUnderstood".

The value "?" with any key has the meaning of enquiry and should be 
answered with the current value or "NotUnderstood".

Target requests are not limited to respond to key=value pairs as offered 
by the initiator.  The target may offer key=value pairs of its own. 

+++++

3. Situation: As the first command on a new connection the initiator
   sends a valid login command with SessionType=discovery, CSG=0, NSG=3,
   and T=1.  The target responds with CSG=0, NSG=1 and T=1.  So both
   sides are now in the operational parameter negotiation stage.
   Question: what parameters can they negotiate in this stage for a
   discovery session, and what should be done if other, irrelevant,
   parameters are negotiated?

   Interpretation 1:
   The only relevant operational parameters in a discovery session seem to
   be those related to markers (FMarker, RFMarkInt, SFMarkInt), error
   recovery (ErrorRecoveryLevel) and vendor specific keys.
   If this is true, what should one side do when the other side attempts
   to negotiate other operational parameters in a discovery session?

   Interpretation 2:
   Even the relevant operational parameters in a discovery session given
   above have very marginal utility.  It would be easier to just
   disallow all operational parameter negotiation in a discovery session.

+++ 

I assume that the "irrelevant" item solves this issue as well.

+++

4. Contradiction in draft 8.
   In section 3.13.5 on page 92 it says that in a login response:
   "for a non-zero Status-Class the T, CSG & NSG fields MUST be 0."
+++

That has been removed - it was a a residue from an intermediate proposal

+++
   In section 5.1 on page 112 it says that in a login response with
   login reject (i.e., Status-Class non-zero): "The T bit of the
   response MUST be set to 1 and the CSG and NSG are ignored."

++++

I will change ignored to reserved

+++
   One of these has to be changed.  Note also that the second statement
   just given (from page 112) is inconsistent with the statement 
   in section 3.12.4 on page 87 that for login requests:
   "the next stage value is valid only when the T bit is 1 and is
   reserved otherwise."  One would expect the standard to have the
   same rule for the way the T, NSG and CSG fields are handled in
   both login request and login response.
+++
The reject is peculiar - there is no present nor future in it :-)

+++

5. Clarification suggested:
   In section 3.13.4 on page 91 of draft 8 it says:  "For the first
   Login Response (the response to the first Login Request) this is
   the starting status Sequence Number for the connection (the next
   response of any kind will carry this number + 1)."
   If the login phase requires more than one login-request/login-response
   exchange, this rule implies that the second (third, fourth, ...)
   login-response should be incrementing StatSN.
   Nobody was doing this, although it seems clear that the standard 
requires
   it.  Perhaps there needs to be a slight addition to the wording of this
   section so it reads:
   "For the first Login Response (the response to the first Login Request)
   this is the starting status Sequence Number for the connection (the 
next
   response of any kind, including the next login response if any in the
   same login phase, will carry this number + 1)."

+++
I will add the text.
+++

6. Situations where frequent errors or misunderstandings occured, although
   the draft seems clear:
   1.  - StatSN must be incremented in Login Phase (point 5 above)
   2.  - CmdSN must not be incremented CmdSN in Login Phase
   3.  - it is okay to transmit the first command of the Login Phase
         with the CSG set to 1. It is also okay for the target to reject 
it
         and to close the connection. 
   4.  - If the Initiator transmits its first command of the Login Phase
         with the T bit set, its okay for the target to transmit a 
response
         with T = 0, even though there is no example in the draft
         demonstrating it. 
   5.  - Stage Transitions from 0 to 3 are valid according to the spec
         although this is not specifically stated in the draft. 
+++ 
Stage transition 0-3 is enabled specifically by the table in 5 pg 114
+++