Re: iSCSI : login keys & mode page settings

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

julian_satran@il.ibm.com wrote:

> +++ I don't know what version you are reading - both 5.91and 92 have them.
> +++

Julian,

Thanks for the clarification. (My comments were written up prior to the
release of 5.9x and it IS difficult to keep up on the reading what with
daily new releases of the
draft !).

Some additional discussion below.

> 
> 3) On a side note, the EnableCmdRN  & CmdRN fields should be re-named to
> EnableCRN and CRN to reflect the same semantics and context as the CRN
> defined in SAM-2 and FCP-2.
> 
> +++ what's in a name... +++

Consistency for one ! (Any strong reasons not to call this CRN, as SAM
and FCP do ?)


> 5) On a more fundamental note, should iSCSI allow for 2 levels of
> control of I-T[-L] nexus operational parameters thru both the mode
> select/sense scsi mechanisms and iSCSI login key mechanisms ?
> 
> +++ It is all about function - several people felt that the (primitive)
> negotiation element in the text commands is better than trying to set a
> parameter to an unacceptable value and finding this out through a mode
> sense
> ++++

Fundamentally, the login key mechanism allows negotiation at the scope
of a session while the mode select allows negotiation at the scope of a
LUN. For most of the parameters listed below (other than EnableCmdRN),
these are set on a per-session basis.

Based on that, it is more optimal to negotiate once using a login key
than set it on a per-LUN basis. 

However, having allowed 2 mechanisms to set these values, iSCSI MUST
then comment on the need to synchronize their settings in the 2 layers
and also comment on the need to trigger a UNIT ATTENTION when changed
through the login key mechanism.

> Ex :
> a) Change thru iSCSI login key should result in an up call to update the
> SCSI ULP.
> b) Change made thru mode select should result in a down call to update
> iSCSI LLP.
> c) Change thru iSCSI login key should result in an up call to SCSI ULP
> to cause a UNIT ATTENTION indicating "Mode Parameters Changed".
> 
> +++ I view the ULP as the source for generating the text comands through a
> new interface (give some credit to implementers). Whenever this is not the
> case the SCSI will use the old mode set commands.
> ISCSI will not set parameters by its own  +++

That would be rather starange violation of layering. Why does the ULP
need to drive transport layer settings and if it did need to do so, why
would it use a transport mechanism rather than a mode select (?).

Also, if you believe iSCSI will not set parameters on its own, this
should be stated explicitly in the draft. The draft is allowing for 2
mechanisms to control these settings without advocating the need to
synchronize b/n them and generate UA when changes are done thru login
keys.

> 
> 6) If such a level of dual control is provided, the iSCSI login
> keys listed above be made LO (leading only) to allow for changes to
> operational parameters only during session login. This is to
> minimize/eliminate disruption of ongoing I/O activity that occurs due to
> the generation of a UNIT ATTENTION CHECK CONDITION when any change is
> made to the above paramters.

Are we in agreement on the above ? 


>8) If these operational parameters are allowed to be set thru iSCSI
> login and they also impact mode page settings, iSCSI spec should
> describe the scope of the mode page setting in terms of whether this
> setting is a saved page setting or not ?
> 
> 9) Should saved page settings be allowed thru iSCSI ?

I did not see any comments on the above issues (?).
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard