RE: iscsi : default iscsi mode page settings.

["Binford, Charles" <CBinford@pirus.com>]

Santosh,  I fully agree with the intent of your comments.  One small
problem, however, is you argue for FirstBurstSize = 0.  Based on your other
comments I believe you are saying first burst should be disabled.  SPC-2
(and I see nothing in iSCSI to change this) defines firstBurstSize of 0 to
mean "no limit".  I believe that is exactly the opposite of what your are
arguing for.  The mode page field of firstFirstSize does not have or need
the concept of zero blocks allowed because the feature is is enabled /
disabled via other methods; process login parameters in FCP, initialR2T and
ImmediateData text parameters.

So, we have the problem of how does a host that wants to use immediate or
unsolicited data know how much he can send.  Options I see are:
- define a default value for the mode page (current method in iSCSI spec).
  As I argued in previous posting, I believe this breaks basic mode page
concepts of SCSI.

- force the host to issue a mode sense before the first command with
Data-Out.
  Not desirable, as Santosh argued in another email.

- specify the amount of data the host send before the R2T during login as a
text parameter
  What I prefer.

If we go with the last choice, then one has the question of what to do with
firstBurstSize in the mode page. Two options come to mind:
- reflect the login specified value in firstburstsize during mode sense.
  Memory says this is how it used to be?

- do nothing with it.  Let iSCSI say that parameter in the mode page has no
meaning for the iSCSI protocol.  Move the "firstBurstSize" concept to the
iSCSI login/text parameters and let it stay there, don't try to tie it in to
the mode pagan at all.  (my preferred choice)


Charles Binford
Pirus Networks
316.315.0382 x222


-----Original Message-----
From: Santosh Rao [mailto:santoshr@cup.hp.com]
Sent: Thursday, September 20, 2001 6:44 PM
To: IPS Reflector
Subject: RE: iscsi : default iscsi mode page settings.


All,

I think we need to discuss the 2 issues of login key defaults & mode page
defaults seperately :

1) Defaults on login keys :
===================
I am in favor of defining conservative defaults. Those initiators needing
additional features should be prepared to do the additional work of
negotiating those keys. It should'nt be the other way around.
Thus, default settings should be :

MaxConnections = 1
FMarker = "no"
InitialR2T = "yes"
BidiInitialR2T = "yes"
ImmediateData = "no"
DataPDULength = 16
MaxOutstandingR2T = 1
DataPDUInOrder = "yes"
ErrorRecoveryLevel = 0
SessionType = "normal"

I'd like to propose one more change that the LogoutLoginMinTime &
LogoutLoginMaxTime login keys be removed from the login keys.

This is because these key values are only relevant for an initiator re-login
following a target originated logout or connection drop (signalled through
an async message). The async message does contain these values and thus, it
provides no additional value to negotiate these during login.

Also to be noted is that LogoutLoginMinTime & LogoutLoginMaxTime are most
likely properties of the target device (how long array "xyz" goes out to
lunch during certain infamous conditions) as opposed to a value that can be
negotiated on a per-initiator basis.


2) Defaults on iscsi mode pages :
========================
Typically, no protocol defaults are specified for mode page settings.
Initiators should be able to function correctly without having to do either
mode select or mode sense. Any initiator that needs advanced settings should
be prepared to do the extra work of issuing mode sense/select to enable
these features. It should NOT be the other way around. (i.e. simple
initiators should NOT have to first issue a mode select in order to ensure
proper operation of their sessions).

If the draft does wish to profile a set of recommended defaults for the
iscsi, these should be conservative, where they affect the operation of
those initiators that do not wish to perform mode select.

In particular, the following defaults are required, if it is decided to
recommend a profile of default mode page settings :

Disconnect-Reconnect Mode Page
--------------------------

   * EMDP = 0

   * MaximumBurstSize = 512 units (as it currently defined. Targets can
     request less data in its R2T and send shorter data-in sequences, if
     mode select is not used by initiators to reduce this value.)

   * FirstBurstSize = 0

The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to use
solicited data MUST first perform mode sense/select operations to query/set
these values. The above default setting of 128 is  in-appropriate since :

a) it can cause erroneous behaviour for those initiators that do not perform
mode select to explicitly turn it off, since targets for which un-solicited
data is enabled but not used may reject/abort the I/O.

b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data is
allowed for every logged-in initiator and they have no control over turning
this off, since mode select is an initiator-driven operation.
Closing the command window causes performance drops and is not a very
satisfactory solution to this problem.

Logical Unit Control Mode Page
========================
This mode page definition can be removed from the iscsi draft since it
governs per-LUN state information and LUN state is the realm of the
SCSI ULP. In particular, it is the SCSI ULP that decides whether to
enable/disable CRN, since CRN is generated by the SCSI ULP.

Thus, it is un-clear why the "Enable CRN" is negotiated at a protocol level
& not at a SCSI ULP mode page such as the Control Mode Page. (??).

Could anybody comment on why CRN (a ULP feature) needs to be enabled in an
iscsi protocol mode page ?
Perhaps, for FCP it made sense to negotiate something like "Enable CRN" in
FCP specific mode pages, since early revisions of FCP did'nt specify the CRN
field in FCP_CMD IU and so, the "Enable Precise Delivery" (EPDC) bit was
required to be queried/set using mode sense/select, prior to using CRN.

Since iscsi supports CRN in its scsi command pdu from its initial rev, I
don't see why "Enable CRN" is needed to be done at the iscsi protocol level.
(?).

Regards,
Santosh



"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:

> I vote for making the exchange of some text parameters MANDATORY, with no
> defaults.
>
> Marj
>
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@Brocade.COM]
> > Sent: Thursday, September 20, 2001 10:48 AM
> > To: 'Sanjeev Bhagat (TRIPACE/Zoetermeer)'; 'Santosh Rao'; IPS
> > Reflector
> > Subject: RE: iscsi : default iscsi mode page settings.
> >
> >
> > It is true that default mode settings for Mode Pages
> > are usually arranged between buyer and vendor for
> > maximum convenience in the buyer's systems.  It is
> > generally true that any setting of a Mode Page will
> > allow the protocol to operate correctly, except a few,
> > notably the first burst size parameter if
> > ImmediateData is set to yes.
> >
> > On the other hand, some of the iSCSI text keyed
> > parameters MUST be known before the protocol will
> > operate correctly.  ImmediateData is certainly
> > one of those.  As a result, you have two choices:
> >
> >    a) Make the negotiation of all such parameters
> >       MANDATORY during the login and after any
> >       reset that may change them,  or;
> >
> >    b) Define a default state that will be guaranteed
> >       unless and until the parameter has been explicitly
> >       changed.
> >
> > Your choice.
> >
> > Bob
> >
> > > -----Original Message-----
> > > From: Sanjeev Bhagat (TRIPACE/Zoetermeer)
> > [mailto:sbhagat@tripace.com]
> > > Sent: Thursday, September 20, 2001 6:59 AM
> > > To: 'Santosh Rao'; IPS Reflector
> > > Subject: RE: iscsi : default iscsi mode page settings.
> > >
> > >
> > > Santosh,
> > >
> > > Where did you find these SCSI Mode page settings? At least I
> > > could not find
> > > it in SAM-2 document? The mode select command is available in
> > > SPI documents
> > > but they are meant for particular SCSI device and not for
> > > iSCSI device?
> > >
> > > Be it whatever the case I would like to ask why the default value of
> > > MaximumBurstSize is 512 units and why is the default value of
> > > FirstBurstSize
> > > 128 units. remember each unit is 512 bytes as defined in iSCSI 7.9x
> > > revisions so setting the default value of FirstBurstSize to
> > > 128 units means
> > > 65536 bytes or 64K Bytes and similarly the value of
> > > Maximumburstsize is 256K
> > > Bytes. Is it Ok to have the FirstBurstsize of 64KB??
> > >
> > > Sanjeev
> > >
> > > -----Original Message-----
> > > From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > > Sent: Thursday, September 20, 2001 2:04 AM
> > > To: IPS Reflector
> > > Subject: iscsi : default iscsi mode page settings.
> > >
> > >
> > > All,
> > >
> > > Speaking on the subject of default settings, some questions
> > on recent
> > > changes to the iscsi mode select pages......
> > >
> > > 1) Section 3 of rev 7.94 of the iscsi draft attempts to call
> > > out default
> > > values for the iscsi  mode pages. Per my understanding, there are no
> > > defaults for SCSI mode pages, and all the setting are assumed to be
> > > disabled, unless explicitly turned on/enabled through a mode select.
> > >
> > > IOW, the keys in scsi mode pages are defined to be enabling certain
> > > features and the default settings are that these features are
> > > turned off
> > > unless a mode select is explicitly used to enable them.
> > >
> > > However, the iscsi mode pages seems to be using the opposite
> > > policy and
> > > is advertising default settings for mode pages, that too,
> > > agreesive ones
> > > at that! IOW, an initiator implemenation has to explicitly
> > > issue a mode
> > > select to disable/turn_off features rather than issue a
> > mode select to
> > > turn them on.
> > >
> > > Here's a few examples :
> > >
> > >    * default MaximumBurstSize : 512 units
> > >    * default EMDP : 1 (i.e. modify data pointers is enabled
> > by default
> > > !)
> > >    * default FirstBurstSize : 128 units. (i.e. initiators MUST use
> > > solicited
> > >      data, unless they explicitly turn it off using mode
> > > select, since,
> > > not
> > >      sending solicited data when it has been negotiated
> > > implies a target
> > > may
> > >      abort the I/O.
> > >
> > > I suggest that in keeping with the scsi mode pages, NO
> > > default settings
> > > be advertised for any iscsi mode
> > > pages. i.e. all defaults are conservative (set to 0), unless
> > > explicitly
> > > turned on thru a mode select.
> > >
> > > Comments ?
> > >
> > > Regards,
> > > Santosh
> > >
> > > "Mallikarjun C." wrote:
> > >
> > > > Matthew,
> > > >
> > > > I completely agree that the default should be "no"!  I
> > pointed this
> > > > out sometime ago myself.  Apart from what you point out,
> > the default
> > > > setting for "ImmediateData" seems to be at variance with the
> > > > conservative default for "InitialR2T" ("yes").
> > > >
> > > > Julian, could you please consider this request?
> > > >
> > > > Regards.
> > > > --
> > > > Mallikarjun
> > >
> > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote:
> > > > >
> > > > > Julian,
> > > > >
> > > > > Appendix D24 (ImmediateData) does not describe the result of
> > > negotiation if
> > > > > the two sides differ. I presume that since the default is "yes",
> > > then only
> > > > > if both sides agree to "no" is immediate data turned
> > off.  Please
> > > can this
> > > > > be stated.
> > > > >
> > > > > Additionally, I feel that the default value for
> > > ImmediateData should
> > > be
> > > > > "no".
> > > > >
> > > > > Similarly, there is no statement on MaxOutstandingR2T.
> > Presumable
> > > the
> > > > > minimum is selected.
> > >
> > >
> >