Subject: iSCSI : Login Phase Problems

From: Santosh Rao <[email-masked]>
Date: Tue, 23 Jan 2001 23:18:30 -0800 (PST)

Julian & All,

Problem :
=========
The login phase is intended to be driven by the initiator and it is the
one to decide if only a Login PDU is sufficient or it needs a Login + Text
PDU. The initiator needs a mechanism to indicate to the target that a Text
command will [or will not] follow the login command.

However, by placing the "F" bit in the login response and NOT the login
command, the iSCSI login phase opens up a number of questions :

 Reference
 ========
 Section 4, 4.1 of rev 03 iSCSI draft.
 
 The login phase is negotiated as follows :
 ===========================================
 Initiator			 Target
 ===========================================
 1) Login    ----------->
                   <---------- 1) Login response of "accept login"
                                                 with F=0
 2) Text    ------------>
               <-----------  2) Text Response
             :
             :
            <------------  3) Login Response of "accept login"
                                                with F=1
 
 Issues :
 ========
 1) Without a communication from the initiator on whether it intends to
 follow the login command with a text command, the target may send back a
 login accept with the "final" (F) bit set, when the initiator was still
 interested in negotiating more keys.

 2) The target may send back an interim login accept ("F" bit is not set),
 expecting the initiator to continue negotiation with a text command. The
 initiator may have no further keys to negotiate and so, does nothing.
 When is the login phase then deemed to be complete ? (i.e. what causes
 the tgt to do a final login accept (F bit set)).

 3) If multiple Text commands are to be allowed in the login phase, how
 does a target know that the initiator is done with all its key
 negotiations and has sent all its text commands ? 
 If multiple Text commands are NOT allowed in the login
 phase, then, the draft MUST state this explicitly.

 It is the initiator that drives the Login/Text negotiations and 
 hence, it is the initiator that must decide whether a login 
 is sufficient or a login will be followed by a text phase.
 
 Therefore, the "F" bit currently in the login response should actually
 be in login command. The initiator is the master of the login phase and
 it should drive the login + text phases.

 Solution :
 ==========
 Case I (only login command used )
 ---------------------------------

 Initiator			Target
 ======================================
 Login(F bit set) ------>
		  <-----  Login Accept (F bit set)

Case (II) (login + text commands used in login phase)
-----------------------------------------------------
 Initiator			Target
 ======================================
 Login(F bit NOT set) ------>
		      <----- Login Accept (F bit NOT set)
Text (F bit NOT set)  ------> 
		      <----- Text Response
		      :
		      :
Text (F bit set)      ----->
		      <---- Text Response
		      <---- Login Response (F bit set)

Comments ?
 
Regards,
Santosh

-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################

---

From: Joshua Tseng <[email-masked]>
Date: Wed, 31 Jan 2001 16:12:00 -0800

JP,

<snip...snip>

> What is being achieved by preparing the target to expect a 
> text command after
> login ?
> 
> It is the responsibility of the initiator to negotiate before 
> getting into
> serious stuff - If it does serious stuff without 
> negotiations, or before
> negotiations the defaults will take effect.
> 
> I don't see a reason to change this.
> 
> -JP
> 

If this is the case, then we need a statement in the spec
that says the target MUST support all defaults that are defined
in Appendix C, as it might not be given an opportunity to
change the defaults.

Are you sure this is how we want to proceed?  Wouldn't it be
wise to support targets that need to change the defaults?
For example, what of an iSCSI proxy target on an iSCSI-FC
gateway that wants to use 16-bit task tags?

Josh