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

From: [email-masked]
Date: Fri, 20 Apr 2001 08:07:59 +0200

Santosh,

answers in text.

And again - please tone down your notes.

Julo

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

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

To:   [email-masked], Julian Satran/Haifa/IBM@IBMIL
cc:   Stephen Bailey <[email-masked]>, David Black
      <[email-masked]>
Subject:  Re: iSCSI : login keys & mode page settings

Stephen Bailey wrote:
>
> > +++ 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

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

+++ I will if you will stop SCREAMING. And rememember that I am not bound
to by any rules other than respect for the individual +++

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

+++ it is called iSCSI LU control mode page the same way as FCP call it.
And this is one of those instances in which the tone of your note is
irritating to say the least.
+++

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.

+++ We have required ACA to be supported by all new iSCSI targets and
several
actions require the target to enter ACA state.
It was brought to our attention that many initiators will not react
properly to a
target entering ACA state (not do the reset).
The EnableACA bit and key are meant to enable an initiator to control this
iSCSI specific ACA behaviour.  This behaviour is related to asynchronous
events and is not controlled by the NACA CDB bit.

++++

2)
> 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 ?)

+++ No strong reason except the fact that iSCSI - has its own naming style
- but I've changed
this.
+++

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

4)
> 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 ?

+++ No +++
5)
> If these operational parameters are allowed to be set through 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 ?
>
+++ 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 +++
6)
I did not see any comments on the above issues (?).

- Santosh
 - santoshr.vcf

---

From: Santosh Rao <[email-masked]>
Date: Fri, 20 Apr 2001 12:11:12 -0700

Julian,

Would the following not satisfy the requirements for dealing with this
ACA issue :

1) Initiators determine the target support for ACA through the NACA bit
in the INQUIRY response. (Assuming iSCSI targets have implemented ACA in
good faith, this would be supported.)

2) Initiators set the NACA bit in the CDBs of commands that need strong
ordering. (This could be a small subset of the I/O traffic to one or
more LUNs within the session and not required for all the I/Os in that
session.)

3) Any exception condition on a SCSI I/O, for which the NACA bit was set
results in ACA being established. 
Thus, ACA would only be applied if some I/O traffic that required strong
ordering was affected by the exception condition.

4) Since the initiator is ACA capable based on its usage of the NACA
bit, it should also be capable of performing the desired Clear ACA to
recover from this condition.

Such an approach would only apply ACA and its corresponding recovery
when some strongly ordered I/O encountered an exception condition,
rather than applying ACA on a session granularity.

To summarize, the above approach allows :
- ACA to be turned on/off for a subset of I/Os headed to a LUN
- ACA based recovery only used where needed.
- Keeps iSCSI ACA un-aware and rightly so, since this is a property of
the SCSI ULP.
- Avoids applying ACA recovery on a session granularity.

What am I missing here (?). Why is an EnableACA needed ?

- Santosh

[email-masked] wrote:

> All references to

 +++ We have required ACA to be supported by all new iSCSI targets and
 several
 actions require the target to enter ACA state.
 It was brought to our attention that many initiators will not react
 properly to a
 target entering ACA state (not do the reset).
 The EnableACA bit and key are meant to enable an initiator to control
this
 iSCSI specific ACA behaviour.  This behaviour is related to
asynchronous
 events and is not controlled by the NACA CDB bit.
 
 ++++

---

From: Santosh Rao <[email-masked]>
Date: Fri, 20 Apr 2001 16:42:25 -0700

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. 

> Are we in agreement on the above ?

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.

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

- Santosh

---

From: Ralph Weber <[email-masked]>
Date: Fri, 20 Apr 2001 14:19:18 -0700

I like what Santosh is proposing and have big time reservations
about this hack EnableACA bit.  The cases the Julian is trying
to cover with the EnableACA bit should be covered via the
proposal Ed Gardner is supposed to bring to T10 to make Unit
Attention "sticky" and turn things like BUSY status into
CHECK CONDITIONs.

There is one tiny nit in Santosh's proposal.  The bit in the
standard INQUIRY data is called NormACA, not NACA.  NACA is
the bit in the CDB, only.

Thanks.

Ralph...