Re: iscsi : iscsi parameter default values

[Santosh Rao <santoshr@cup.hp.com>]

Eddy,

My comments inline.

Thanks,
Santosh


Eddy Quicksall wrote:
> 
> Would all cases look like these? (If I made a mistake, please correct it).
> 
> Note that I am attempting to use the rule specified as:
> 
>  The negotiation MAY
>  proceed only up to the point where both parties can unequivocally
>  compute the result; continuing beyond this point is OPTIONAL.
> 
> And my interpretation of the rule is that when a responder gets a binary
> value, it can compare that against the default and can therefore compute the
> result and therefore does not need to respond if the result is what he
> wants.
> 
> Am I correct in my interpretation?
> 
> Eddy
> 
> Default ImmediateData="yes"
> ===========================
> Initiator wants immediate data & target supports it.
> ---------------------------------------------------
> 
> I -> T : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> yes * yes = yes

Correct. 

> 
> Initiator does not want immediate data & target supports it.
> -----------------------------------------------------------
> 
> I -> T : ImmediateData="no".
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> no * yes = no

Correct. 

> 
> Initiator wants immediate data & target does not support it.
> -----------------------------------------------------------
> 
> I -> T : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : ImmediateData="no".
>          (CSG=Operational, NSG=FFP). T=1
> 
> yes * no = no


IMO, the above is in violation of the below rule found in Section 5.1 :

"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. "

Thus, when a target cannot accept the defaults, it must float its own
values for the keys and in this case, it cannot perform a phase change,
[since it did not forego operational negotiation.]

Hence, per the current draft wording, I believe the above case would be
:
> I -> T : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : ImmediateData="no".
>          (CSG=Operational, NSG=Operational). T=0
  I -> T : (no key sent)
            (CSG=Operational, NSG=FFP). T=1
  T -> I : (no key sent).
	    (CSG=Operational, NSG=FFP). T=1
> 
> yes * no = no


However, I do believe the above rule is flawed and should be modified. A
target must be allowed to perform a phase change any time it has no more
operational keys to negotiate and this should apply regardless of
whether defaults are sent or keys are explicitly sent. This should not
be dependent on whether the target had to forego operational
negotiation, whether it sent an empty login response or sent keys back ,
etc.


> 
> Initiator does not want immediate data & does not target support it.
> -------------------------------------------------------------------
> 
> I -> T : ImmediateData="no".
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> no * yes = no

Correct. 


> 
> Default ImmediateData="no"
> ==========================
> Initiator wants immediate data & target supports it.
> -----------------------------------------------------------
> 
> I -> T : ImmediateData="yes"
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)
> 
> yes * no = no

If the target supports immediate data it would send back a key
indicating the same.

Thus, the above should be :

I -> T : ImmediateData="yes"
	 (CSG=Operational, NSG=FFP). T=1

T -> I : ImmediateData="yes"
	 CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)

yes * yes = yes

Note the difference in the target's phase change since in this case, all
key exchanges were explicit and the above "flawed" rule did not apply. I
suggest we make the modification suggested to the rule to enforce more
consistent target behaviour. 


> 
> Initiator does not want immediate data & target supports it.
> --------------------------------------------------------------
> 
> I -> T : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : (no key sent)
>          (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)
> 
> no * no = no

Correct.

> Initiator wants immediate data & target does not support it.
> -----------------------------------------------------------
> 
> I -> T : ImmediateData="yes".
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> yes * no = no

Correct.

> 
> Initiator does not want immediate data & does not target support it.
> -------------------------------------------------------------------
> 
> I -> T : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> no * no = no

Correct.


On a seperate note, I believe the following changes are required in the
login process :

1) All these rules about both sides having to compute the result of the
negotiation are complicating the login procedure. Why not just follow
the standard practice of letting the target pick the negotiation result
and send it back in its response ? This allows for several advantages
like less code (only 1 side computing the result), ease of debugging
(target state is known to initiator), etc.

2) (1) also simplifies the case where responder silently drops a key
instead of responding to each key that was sent. I think a response from
the target for each key sent by the initiator is more explicit and
simpler. 

3) The draft should state that the initiator is the originator and the
target is the responder for ALL security and operational keys. (either
due to the use of defaults or mandated keys).




> 
> Eddy
> 
> -----Original Message-----
> From: Santosh Rao [mailto:santoshr@cup.hp.com]
> Sent: Monday, October 01, 2001 7:16 PM
> To: John Hufferd
> Cc: ips@ece.cmu.edu
> Subject: Re: iscsi : iscsi parameter default values
> 
> John Hufferd wrote:
> >
> > I think your logic reverses if the support wanted is yes and the
> target is
> > supporting yes.
> 
> How so ?
> 
> Here are the scenarios when initiator wants to use immediate data and
> target supports it, first with default ImmediateData set to "yes" and
> then, with default Immediatedata set to "no". In both cases, a single
> login handshake occurs. The only difference being that when
> ImmediateData defaults to "yes", the key need not be sent in either
> direction, whereas when it defaults to no, the ImmediateData key travels
> in both directions in the login payload.
> 
> (FFP = FullFeaturePhase).
> 
> Default ImmediateData="yes"
> ---------------------------
> Initator wants immediate data & targets supports it.
> ----------------------------------------------------
> 
> I -> T : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : (no key sent).
>          (CSG=Operational, NSG=FFP). T=1
> 
> Default ImmediateData="no"
> --------------------------
> Initiator wants immediate data and target supports it.
> -----------------------------------------------------------
> 
> I -> T : ImmediateData="yes"
>          (CSG=Operational, NSG=FFP). T=1
> 
> T -> I : Immediatedata="yes"
>          (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)
> 
> Same number of handshakes in both cases. The only difference is that the
> key is not sent in the first case, and key is explicitly exchanged in
> the 2nd case.
> 
> > If they say No they clearly do not care about extra handshakes sense
> R2T is
> > all they have and it requires extra handshakes.
> 
> Hmm.... The way I see it, an initiator that does not use ImmediateData
> is a simple initiator and is more interested in seeing a simpler login
> (completed in a single login req/rsp) than one that does support
> ImmediateData.
> 
> Those implementations that can do the extra work of supporting
> ImmediateData can well do the extra work of negotiating for its use.
> 
> Regards,
> Santosh

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