Subject: iSCSI : login keys & mode page settings

From: Santosh Rao <[email-masked]>
Date: Tue, 17 Apr 2001 17:19:27 -0700

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.

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.

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.

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.

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 ?

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

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

---

From: [email-masked]
Date: Thu, 19 Apr 2001 18:59:18 +0200

The mechanism are not exactly redundant.

Julo

Stephen Bailey <[email-masked]> on 19/04/2001 15:34:01

Please respond to Stephen Bailey <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: iSCSI : login keys & mode page settings

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

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: [email-masked]
Date: Fri, 20 Apr 2001 20:32:17 -0400

I'm not sure -- this sounds somewhat like the
old principle of not asking why there's a hole
in one's foot when one has aimed the gun at
it and pulled the trigger.  For the tape
example, if some tape driver changes a
Target iSCSI parameter that disrupts that
driver's own tape I/O in a fashion that the
driver can't recover from, I think it's
clear where the fault lies.  If one Initiator
can damage another in this fashion, then we
may indeed have a problem.

Comments?,
--David

> -----Original Message-----
> From:	Santosh Rao [SMTP:[email-masked]]
> Sent:	Friday, April 20, 2001 8:09 PM
> To:	[email-masked]
> Cc:	[email-masked]
> David,
> Some clarification on the basis for classifying login keys as LO would
> also be helpful. Should login keys that can disrupt I/O on their change
> be allowed to be non-LO ?
> 
> Thanks,
> Santosh
> 
> [email-masked] wrote:
> > 
> > Without getting into the technical details of the
> > discussion, I have a couple of observations:
> > 
> > (A) The issue of whether to allow mode page
> >         access to and modification of iSCSI parameters
> >         will need to be taken up at the interim
> >         meeting.  IMHO, access seems like a good
> >         idea, so that SCSI-generic code that doesn't
> >         know specifically about iSCSI can find
> >         what it expects where it expects it, but
> >         I'm unsure about modification because it
> >         may carry a risk of code that's iSCSI-unaware
> >         getting something wrong.  The mode page
> >         commands should be transparent to iSCSI.
> > 
> > (B) The mode page and text key mechanisms have
> >         to access the same data.  Section 3 of the
> >         -06 version says this, but needs some editing
> >         to enforce it by using "MUST" or its equivalent
> >         (cf. RFC 2119).  This is to prevent an
> >         implementation from having two instances of
> >         the same parameter - one for the mode page and
> >         one for the text keys - which would be a bad
> >         thing.
> > 
> > --David
> > 
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > [email-masked]       Mobile: +1 (978) 394-7754
> > --------------------------------------------------- << File: Card for
> Santosh Rao >>

---

From: [email-masked]
Date: Sat, 21 Apr 2001 17:32:55 +0200

[email-masked] on 20/04/2001 19:12:04

Please respond to [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: iSCSI : login keys & mode page settings

+++ I would like to point out that there are three mode pages that have
parameters that are either completely protocol specific (LU & Port) or with
semantics that are protocol specific(disconnect/reconnect). Code that is
completely iSCSI unaware must not touch protocol specific parameters.

The setting is is more delicate issue and our solution just bring the
"negotiation" into modern age.  It is not radically better but it gives
some uniformity to iSCSI driver and target logic.

I would have suggested removing mode set access for those parameters but
this is hard to enforce in a port/miniport of high-level/low-level code
structure.  :-)

+++

+++ I will try to - although boldface is forbiden in text-only :-) +++
--David

---

From: [email-masked]
Date: Mon, 23 Apr 2001 13:36:07 +0300

Comment in text

Julo

Santosh Rao <[email-masked]> on 21/04/2001 02:42:25

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

To:   [email-masked]
cc:

[email-masked] wrote:

> 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.
>
> +++ Parameter changes originate from SCSI and iSCSI only enables another
> mechanism to convey them.
> This is an implementation issue +++

Julian,

From reading the spec, it is difficult to arrive at the above conclusion
that there currently exists only 1 layer allowed to make the changes,
albeit through 2 different mechanisms. If the changes are intended to
always originate from the SCSI layer (and I'm not sure why this should
be the case), then, would it not be more apt for the SCSI ULP to use a
mode select which is the mechanism available at this layer, rather,
than, invent down calls into the iSCSI layer to map to an equivalent
login/text key setting.

Again, I would like to request that the setting of these control options
be made from 1 layer only.

> 4)
> > If such a level of dual control is provided, the iSCSI login
> Are we in agreement on the above ?
>
> +++ No +++

Could you please throw light on the basis for LO classification ? If
some key negotiation after a login causes disruption of all outstanding
I/O (keeping in mind its impact on tape type of devices), should'nt such
a key be not made LO (?)

IMHO, any negotiation key change that can disrupt I/O must be restricted
to login time negotiation only. (LO). This would prevent potential iSCSI
windows for disruption of tape I/O.

+++ LO stands for Leading only and
as for the general principle - that is motherhood and I agree that I/O
shoulde not be disrupted.
The exact mechanisms to achieve this are a more complicated issue.
As we can have several logins possible in a session - even with one
connection I thought that
that I sort of placed whatever can be disruptive in the LO category
(stronger than login-only).
If there are more please we can discuss each case +++

> 5)
> > If these operational parameters are allowed to be set through iSCSI
> +++ I don't know - I would rather think not +++
> 6)
> > Should saved page settings be allowed thru iSCSI ?
> +++ I don't know - I would rather think not +++

I agree with the above. Perhaps, the draft could explicitly state the
same. (Then again, setting these options through 1 mechanism alone would
solve this issue.)

+++ let's hear other opinions too +++

- Santosh
 - santoshr.vcf