Re: iscsi : iscsi parameter default values

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

Santosh,

I see now where you took your rules from. Those where meant to be only examples but I will reformulate the offending paragraph as:

An initiator that can operate without security and with all the operational parameters taking the default values issues the Login with the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase. If the target is also ready to forego security and can finish its LoginOperationalNegotiation the Login response  has T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase in the next stage.

Regards,
Julo

Santosh Rao <santoshr@cup.hp.com> Sent by: santoshr@cup.hp.com 01-10-01 23:36 Please respond to Santosh Rao

To:        Julian Satran/Haifa/IBM@IBMIL         cc:                 Subject:        Re: iscsi : iscsi parameter default values

Julian,

The login section is somewhat contradictory b/n the wording you point
out below and the following wording :

"An initiator that can operate without security and with all the
operational parameters taking the default values issues the Login with
the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG
set to FullFeaturePhase. If the target is also ready to forego security
and LoginOperationalNegotiation the Login response is empty and has T
bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to
FullFeaturePhase in the next stage."

Per the above wording, the target can :
- only set T bit to 1 and change phase from Operational to
FullFeaturePhase if it has no keys to send back.

Thus, when a target is unable to function with a default key setting, it
will need to originate a key, remain in operational phase and respond
with T=0.

From the above wording, it appears that while the key negotiation has
ended (per your wording below), the login remains in Operational Phase
due to the target having to return NSG=Operational (per the above
wording). Hence, the scenario/example I sent earlier is  valid, per the
above wordings in the draft rev 08.

I suggest the following that the above wording be re-phrased to allow
the target to change phase any time it is done with its keys and has no
more parameters to send. (i.e. it can set T=1 and still send back
parameters. Login response need not be empty.)

Regards,
Santosh


Julian Satran wrote:
> 
> Santosh,
> 
> I assume that you know by now but here is the key anyhow:
> 
> Robert,
> 
> The I and T are required to send enough messages so that every one of
> them will be able to evaluate the result with new data (stated
> explicitly  with an example in 2.2.4
> 
> In "numerical" negotiations, the offering and responding party state a
> numerical value. The result of the negotiation is key dependent;
> frequently the lower or the higher of the two values is used.
> 
> For numerical negotiations, the responding party MUST respond with the
> required key.
> 
> Binary negotiations (for keys taking the values yes or no) are a
> restricted form of numerical negotiations and the result is a key
> dependent Boolean function of the two inputs. The negotiation MAY
> proceed only up to the point where both parties can unequivocally
> compute the result; continuing beyond this point is OPTIONAL (e.g., if
> the function is AND and one of the parties says "no" then this may end
> the negotiation).
> 
> This is one of the reasons of selecting a computed value.
> 
> You introduce an exchange not needed.
> The behavior you want is supported but not mandated.
> I will introduce explicit wording in 09.
> 
> Julo
> 
>   Santosh Rao
>   <santoshr@cup.hp.com>                 To:        Julian
>   Sent by: santoshr@cup.hp.com  Satran/Haifa/IBM@IBMIL
>                                         cc:
>   01-10-01 19:08                        Subject:        Re: iscsi :
>   Please respond to Santosh Rao iscsi parameter default values
> 
> 
> 
> Julian,
> 
> Could you please comment on why the examples are incorrect and what
> are
> the login hand-shakes for the scenarios suggested.
> 
> Thanks,
> Santosh
> 
> Julian Satran wrote:
> >
> > ... the debate would be of some interest if the examples where
> > correct.
> >
> > But unfortunately they are not.
> >
> > Julo
> >
> >   Santosh Rao
> >   <santoshr@cup.hp.com>                   To:        ips@ece.cmu.edu
> >   Sent by: owner-ips@ece.cmu.edu          cc:
> >                                           Subject:        Re: iscsi
> :
> >   01-10-01 18:18                  iscsi parameter default values
> >   Please respond to Santosh Rao
> >
> >
> > All,
> >
> > As the one who started this thread, please allow me to raise one
> > important consideration to this discussion.
> >
> > This discussion has gone down the path of whether immediate data
> > boosts
> > performance and is implementable or whether it is so demanding that
> it
> > is not feasible to implement.
> >
> > I believe the decision on what the default value must assume for
> this
> > parameter must be based on what is going to be the simplest for the
> > login process and which setting minimizes the overheads involved for
> > completion of login.
> >
> > The reason for applying the above criteria is that it provides the
> > benefit of completing login negotiation in a single handshake and in
> > most cases, where initiator goes with the defaults, allows no
> > negotiation to be required whatsoever. [in the case where no
> security
> > is
> > being negotiated.]. This has the significant benefit of boosting
> iscsi
> > interoperability, since it has been seen that login is one of the
> most
> > painful areas of iscsi.
> >
> > With the above in mind, let us consider the 2 cases, Immediate data
> > default to "yes" & "no" (assuming neither side is interested in
> > security) :
> >
> > In the first case (default immediate data="yes') :
> > --------------------------------------------------
> > - Initiator wishes to use immediate data. Target does not support
> it.
> >
> > I -> T : (no key is sent. default assumed for immediate data).
> >                  (CSG=Operational, NSG=FullFeaturePhase). T=1
> >
> > T -> I : ImmediateData="no" (tgt does not support imm data.)
> >                  (CSG=Operational,NSG=Operational). T=0
> >
> > I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1
> >         (no keys to negotiate.
> >          negotiation completed at initiator.
> >          only phase change taking place.)
> >
> > T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1
> >         (target completes phase change.
> >          both sides move to FFP.)
> >
> > Thus, in the above model, there's an extra dummy login handshake,
> when
> > the default ImmediateData is "yes" but targets don't support it for
> > the
> > sole purpose of completing the login phase change.
> >
> > Now, take the case of default ImmediateData set to "no" :
> > ---------------------------------------------------------
> > - Initiator wants to use immediate data. target does not support it.
> > (same scenario as above).
> >
> > I -> T : ImmediateData="yes"
> >         (CSG=Operational. NSG=FullFeaturePhase.). T=1
> >
> > T -> I : ImmediateData="no"
> >                  (CSG=Operational. NSG=FullFeaturePhase). T=1
> >
> > - Initiator does not want to use immediate data.
> >
> > I -> T : (no key is sent. defaults assumed).
> >         (CSG=Operational. NSG=FullFeaturePhase). T=1
> >
> > T -> I : (targets can accept all defaults since they
> >                   are conservative.)
> >                  (CSG=Operational, NSG=FullFeaturePhase). T=1
> >
> >
> > Thus, as you can see from the above, the login process involves the
> > least number of exchanges when the default for ImmediateData is
> chosen
> > to be "no", as opposed to a default of "yes".
> >
> > It DOES NOT matter whether some believe ImmediateData is useful and
> > feasible or some believe it is useful but not feasible, or yet some
> > others believe it is not useful.
> >
> > What MUST govern this decision is which default allows for the
> > simplest
> > login operation.
> >
> > >From the above, it seems to me like a default of "no" for
> > ImmediateData
> > allows login to be completed in a single handshake in the case where
> > initiators wishes to use immediate data or not, and in the case
> where
> > target supports immediate data or not.
> >
> > Therefore, I request the group to please consider setting the
> > ImmediateData default to "no" and vote for the setting of "no". This
> > decision benefits BOTH the camp of immediate data users and
> non-users,
> > since both benefit from minimized steps in the login process.
> >
> > Thanks,
> > Santosh
> >
> >

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################