Subject: Re: iSCSI : login keys & mode page settings

From: [email-masked]
Date: Wed, 18 Apr 2001 16:18:25 +0200

Santosh,

Comments in text.

Julo

Santosh Rao <[email-masked]> on 18/04/2001 02:19:27

Please respond to Santosh Rao <[email-masked]>

To:   IPS Reflector <[email-masked]>
cc:   T10 Reflector <[email-masked]>
Subject:  iSCSI : login keys & mode page settings

All/Julian,

The iSCSI draft is lacking sufficient description on the subject of mode
page settings specific to iSCSI, their corresponding iSCSI login keys
and the interactions between these 2 mechanisms. Specific comments
enclosed below in that regard :

1) The iSCSI draft needs to describe the layout of the protocol specific
mode pages, namely, disconnect-reconnect mode page, protocol specific
lun page and protocol specific port page as applicable to iSCSI. Such a
figurative and textual description should be along the lines of that in
FCP-2 Section 10.

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

2) Specifically, the iSCSI draft lacks the description of the layout of
the protocol specific lun page and in its absence, then describes a
field from this page called
EnableCmdRn. This field is non-existent in the SPC-2 description of this
page in Section 8.3.10.

+++ See above - this is a protocol specific page
+++

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

4) The EnableCmdRN login key should be removed from the list of iSCSI
login keys as this is a per-LUN key and iSCSI login keys have the scope
of a session. IOW, EnableCmdRN should be negotiated through a mode
select only and not through iSCSI login.

+++ I realized this and you are reading old stuff !!+++

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
++++

Ex :
---------------------------------------------------------------------
iSCSI login key         SCSI mode page parameter
---------------------------------------------------------------------
DataPDULength           - Max Burst Size (Disc-reconn mode page)
FirstBurstSize          - First Burst Size (disc-reconn mode page)
InDataOrder             - EMDP (disconn-reconn mode page)
EnableCmdRN             - Enable CRN (LUN control mode page)

If such control is to be allowed at both the SCSI ULP and iSCSI
transport layers, a communication mechanism should be defined to
synchronize the state of these operational parameters across the 2
layers when a change is made in either layer through its corresponding
mechanisms.

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  +++

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.

7) If only 1 mechanism of control is desired, which of the following
alternatives is desirable :
i) Only settable thru mode select and seen thru mode sense
Pros :
------
- Allows 1 mechanism of control.
- Removes the need for synchronization of these values across SCSI ULP &
iSCSI.

Cons :
------
- Requires setting for all LUNs to enable for the entire session.

ii) Settable thru iSCSI and also settable/viewable thru mode sense.
Pros :
------
- flexible and allows control thru both scsi & iSCSI.
Cons :
------
- Can lead to synchronization overheads.
- Needs SP(save page) setting also to be communicated in synching iSCSI
login to mode page values.

iii) Only settable thru iSCSI and viewable thru mode sense.
Pros:
-----
- Single mechanism of modification avoiding synchronization issues in
setting.
Cons :
------
- Denies traditional mechanism of modification. (mode sense).
- May break existing applns if enforced thru SPC-2.
- Requires changes to SPC-2.
- iSCSI compliance requires changes in SCSI ULP for SPC-2 compliance of
the change to not use mode select for parameter changes that are shared
with iSCSI.

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 ?

- Santosh
 - santoshr.vcf

---

From: Santosh Rao <[email-masked]>
Date: Wed, 18 Apr 2001 10:50:38 -0700

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

> +++ what's in a name... +++

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

> parameter to an unacceptable value and finding this out through a mode

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.

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

> made to the above paramters.

Are we in agreement on the above ? 

> 9) Should saved page settings be allowed thru iSCSI ?

I did not see any comments on the above issues (?).

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 19 Apr 2001 09:34:01 -0400

> parameter to an unacceptable value and finding this out through a mode

Several other people seem to have felt that it was better not to have
redundant mechanisms for manipulating this sort of parameter.  How do
you decide?

Steph

---

From: Santosh Rao <[email-masked]>
Date: Thu, 19 Apr 2001 09:59:36 -0700

Julian,

I would prefer a single mechanism as opposed to multiple redundant
mechanisms to set negotiation elements. (Reduce/eliminate options.). In
addition, I have the following concerns [some of which I have raised
repeatedly and have NOT gotten a reply. I would appreciate if you could
kindly comment on ALL of these.] :

1) The draft makes repeated references to a "iSCSI LUN Control Mode
Page". There is NO such page per SPC-2. The references must be changed
to "iSCSI protocol specific LUN page".

2) The new daily release of the draft (5.92 when I last checked) has now
introduced EnableACA as a negotiable login key. All references to
EnableACA are redundant and should be removed for the following reasons
:

a) An initiator knows whether a target supports ACA from the NACA bit in
the INQUIRY response. When a target indicates support for ACA, the
initiator can use it by setting the NACA bit in the CDBs it sends. There
is NO need for any sort of negotiation of this behaviour above and
beyond what is already provided thru SCSI mechanisms.

b) The ACA is a SCSI ULP concept and iSCSI should not be negotiating its
use or lack thereof. This is done thru the NACA bit in CDBs.

c) (As a side note, the description of EnableACA on pg 127 refers to its
presence in the lun control mode page, but it is actually present in the
protocol specific port page.)

d) ACA is a LUN-level (more an I/O level) control option. It MUST NOT be
negotiated on a per-session basis. SCSI allows initiators to request ACA
behaviour on a per I/O basis through the use of NACA bit in the CDBs.

2) 
> On a side note, the EnableCmdRN  & CmdRN fields should be re-named to

3) However, having allowed 2 mechanisms to set negotiation elements,
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.
Again, I would vote for only 1 mechanism for setting these control
options, rather than have to define communication schemes b/n the ULP
and LLP to keep their values in synch and generate UNIT ATTENTION. 

4)
> If such a level of dual control is provided, the iSCSI login

5)
> If these operational parameters are allowed to be set thru iSCSI

6) 
> Should saved page settings be allowed thru iSCSI ?

- Santosh