Re: iscsi : default iscsi mode page settings.

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

Julian,

The FirstBurstSize is governing an iscsi parameter which is : "how much un-solicited
data can the initiator send" ? I concur with Charles' suggestion that FirstBurstSize be
moved to a login key.

By doing this, we can improve scan times, due to the elimination of the mode
sense/select & avoid the side effects of shared mode pages. This allows easier use of
un-solicited data.

Regards,
Santosh

Julian Satran wrote:

> Separation of parameters was made on a (very good) sugestion made by Robert
> Snively - to keep SCSI affecting values (SCSI buffer sizes etc.) in mode
> pages and iSCSI related in key=value.
>
> Julo
>
>
>                     "Binford,
>                     Charles"             To:     IPS Reflector <ips@ece.cmu.edu>
>                     <CBinford@piru       cc:
>                     s.com>               Subject:     RE: iscsi : default iscsi mode
>                     Sent by:              page settings.
>                     owner-ips@ece.
>                     cmu.edu
>
>
>                     21-09-01 16:54
>                     Please respond
>                     to "Binford,
>                     Charles"
>
>
>
> 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.
> > > >
> > > >
> > >
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