Re: iSCSI: current UNH Plugfest

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

> +++ I think this is the correct interpretation and we will fix the wording
> in section 8 to say this. I suggest:
> 
> - During Login, any failure in negotiation MUST be considered as the login
> process failure and the login phase must be terminated. If the failure is
> detected by the target, it must reject the login with the appropriate
> code. The connection must be terminated by the initiator.

I agree.  However, I suggest the following with a minor change (and
leaving out the last sentence).

- During Login, any failure in negotiation MUST be considered as the
login
  process failure and the login phase must be terminated. If the failure
is
  detected by the target, it must terminate the login with the
appropriate
  login response status code.

Regards.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


Julian Satran wrote:
> 
> Bob,
> 
> Comments in text.
> 
> Thanks,
> Julo
> 
> "Robert D. Russell" <rdr@mars.iol.unh.edu>
> Sent by: owner-ips@ece.cmu.edu
> 31-10-01 02:06
> Please respond to "Robert D. Russell"
> 
> 
>         To:     ips@ece.cmu.edu
>         cc:
>         Subject:        Re: iSCSI: current UNH Plugfest
> 
> 
> 
> Attached are some new issues that arose during the iSCSI plugfest at
> UNH on Tuesday 29-Oct-2001.
> (Note: these issues do not take into account any modifications or
> clarifications that occured in the standard due to the issues raised
> on Monday.)
> 
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
> 
> -----------------------------------------------------------------------------
> 
> 1. Situation: as the first command on a new TCP connection, the initiator
>    sends a login with T=1, CSG=1, NSG=3, and valid InitiatorName,
> TargetName,
>    and SessionType keys.  However, there is also a valid key having an
>    invalid value, such as MaxConnections=abcd (i.e., not a number after
> the
>    '=') or MaxConnections4 (i.e., missing the '=').
>    What should the target do?
> 
>    Interpretation 1:
> 
>    According to section 3.10.4 page 82 of draft 8 (page 83 of draft 8a),
>       "Any other key not understood by the target may be ignored by the
>       target without affecting basic function.  However the Text Response
>       for a key that was not understood MUST be key=NotUnderstood."
> 
>    Two things have to be clarified:
>    1. Does this section also apply to keys received in a login?
>    2. Can "NotUnderstood" also apply to "values of keys" that are not
>       understood, even if the key word itself is understood?
> +++
> 1.NotUnderstood appears also in the negotiation section so it applies to
> login.
> I will remove it from the text section
> 2.It does not apply to values
> +++
> 
>    If the answer to these 2 of these questions is "yes", then the
> appropriate
>    response would seem to be for the target to just ignore the key and
> send
>    back MaxConnections=NotUnderstood as part of its next login response.
> 
> 
>    Interpratation 2:
> 
>    According to section 8.7 page 129 of draft 8 (page 130 of draft 8a),
>       "A negotiation failure is considered one or both of the following:
>       - None of the choices or the stated value is acceptable to one
>       negotiating side. ..."
>    Clearly this stated value ("abcd") is not acceptable to the target.
>    Therefore, the following rule on page 129, draft 8 (page 130, draft 8a)
>    applies:
>       "- During Login, any failure in negotiation MUST be considered
>       as the login process failure and the connection must be dropped."
> 
>    Therefore, the target should just drop the connection without sending
>    any login response back to the initiator.
> 
>    Interpretation 3:
> 
>    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 think this is the correct interpretation and we will fix the wording
> in section 8 to say this. I suggest:
> 
> - During Login, any failure in negotiation MUST be considered as the login
> process failure and the login phase must be terminated. If the failure is
> detected by the target, it must reject the login with the appropriate
> code. The connection must be terminated by the initiator.
> 
>  +++
> 
> 2. Situation: on the first login command in operational parameter
> negotiation
>    stage, the initiator sends no operational keys, thereby telling the
> target
>    that it accepts all the default values for these keys.  However, the
> target
>    wants to negotiate the value of MaxConnections, so in the login
> response
>    it sends back "MaxConnections=3" (for example).  Should the initiator
>    send a response to this key or not?
> 
>    The statement in section 2.2.4 on page 30 of draft 8 and 8a:
>    "For numerical (and single literal) negotiations, the responding party
> MUST
>    respond with the required key.(...)"
>    makes it clear that the responding party MUST respond.  However, in
> this
>    situation, it is not clear who the responding party is.
> 
> +++ we are using the term offering and responding to distinguish them from
> initiator and target and explicitly say (in 2.2.4) that the target may
> offer keys
> +++
> 
>    Interpretation 1:
> 
>    By not explicitly sending this key in the login command, the initiator
>    is implicitly offering the default value and therefore is the offering
>    party and the target is the responding party.  The conclusion is that
>    the initiator does not have to send a response to this key from the
>    target.
> 
> +++ there is no implicit ofering of defaults. A default is accepted only
> if the two parties are silent.
> 
> +++
>    Interpretation 2:
> 
>    The target is the offering party because it is the party that
> explicitly
>    stated the key for the first time during these negotiations.  The
>    conclusion is that the initiator MUST send a response to this key from
> the
>    target.
> 
>    NOTE 1: If interpretation 1 is correct, it would seem to imply that the
>    target MUST respond to every key whether or not it is present in the
>    login from the initiator, even if it does not want to change the
> default
>    value.  The reason is that a missing key is an implicit offer of the
>    default value, and the responding party MUST respond.  Is this a
> correct
>    interpretation?
> 
>    NOTE 2: The following statements in section 2.2.4 page 29 of draft 8a:
> 
>         Originator-> <key>=<valuex>
>         Responder-> <key>=<valuey>|NOtUnderstood
> 
>    seem to imply that the originator is the party (initiator or target)
> that
>    explicitly offers a key, and that omitting a key is not an implicit
> offer
>    of that key with the default value.  However, even in the revised draft
> 8a
>    there is no definition of "Originator" and/or "Responder" that would
>    make this clear.  Adding to the standard these definitions, and an
>    explicit statement that "a missing key does not constitute an implicit
>    offer of the default" would help eliminate misunderstandings.  In
>    addition, including an example of this situation (where an initiator
>    omits a key and the target offers the key) would be a big help.
> 
> +++ will do +++
> 
> 3. Some of the login phase examples given in Appendix A of both draft 8
> and
>    8a do not follow the rule in section 3.12.4 page 87 of draft 8 (page 88
>    of draft 8a):
>       "The next stage value is valid only when the T bit is 1 and is
>       reserved otherwise."
>    and the rule in section 3 page 48 of draft 8 (page 49 of draft 8a):
>       "Any reserved fields and values MUST be 0 unless specified
> otherwise."
> 
>    If these rules are applied, all examples having T=0 should also
>    have NSG=0.  Presently all of them with T=0 also have NSG=1 or NSG=3.
> 
> +++ Will fix the examples +++
> 
> 4. Situation: The initiator and target have successfully completed the
>    login phase for a discovery session and are now in full feature phase.
>    The initiator sends a text command containing the single key:
>    "SendTargets=".  What response is expected from the target?
> 
>    Interpretation 1:
> 
>    According to the explanation on page 188 of draft 8 (page 189 of
>    draft 8a):
>    "If no target name is specified, the session should respond with
>    addresses only for the target to which the session is logged in.
>    This MUST be supported on operational sessions, and MAY NOT
>    return targets other than the one to which the session is logged in."
> 
>    However, for a discovery session there is no target per se (the
>    initiator does not specify a TargetName= during login), so the
>    target therefore follows the rule on page 188 of draft 8 (page 189
>    of draft 8a):
> 
> +++
> That is not strictly correct. You may use discovery to determine the
> addresses and portal groups for a specific target - i.e. you may give a
> target-name. If you give a target name that is all you get. If don't give
> a name you get all the targets you are allowed to get to.
> ++++
> 
>    "A SendTargets response MAY contain no target names, if there are no
>    targets for the requesting initiator to access."
>    and sends back a Text Response with no keys in it.
> 
>    Interpretation 2:
> 
>    In a discovery session, the key "SendTargets=" makes no sense and
> should
>    be treated by the target in the same manner as the key
> "SendTargets=all".
> 
> 5. Some common error situations:
> 
>    1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02),
>       some targets are not including the SenseLength as the first 2
>       bytes in the data segment.  Although the format of the data segment
>       is clear from the diagram in section 3.4.6 on page 62 of draft 8
>       (page 63 of draft 8a), the last entry in the diagram for the SCSI
>       Response PDU on page 58 of draft 8 (page 59 of draft 8a) is
>       misleading because it mentions only the Sense Data and Response
>       Data and omits the Sense Length.  It would therefore be helpful
>       if the last entry in the diagram on page 58 were changed to
> explicitly
>       reference the diagram on page 62, as in:
> 
>          Data Segment -- see section 3.4.6 (optional)
> +++ will do +++
> 
>    2) - after sending a CmdSN on an initial login, some initiators are
>       incrementing it before sending their first non-immediate command.
>       (i.e., if the initial login contains CmdSN=123, they are sending
>       CmdSN=124 on the first non-immediate command after the login phase).
>       Section 3.12.10 on page 89 of draft 8 (page 90 of draft 8a) is
>       clear that in this example the first non-immediate command should
>       carry CmdSN=123, not 124.  This was an issue at the July plugfest
>       and apparently some implementations have not been updated to conform
>       to the draft 8 standard in their handling of CmdSN.