Subject: iscsi : default iscsi mode page settings.

From: Santosh Rao <[email-masked]>
Date: Wed, 19 Sep 2001 17:04:24 -0700

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.

---

From: "Binford, Charles" <[email-masked]>
Date: Thu, 20 Sep 2001 10:32:35 -0400

I agree that iSCSI should not be calling out defaults for mode page field
values.  For example 3.1.1 says "The default value assumed for a new iSCSI
session (I_T nexus) is 512 units."  

This is counter to the way SCSI mode pages work.  If a SCSI initiator issues
a mode select to a mode page with the SAVE option enable, the "value assumed
for a new iSCSI session ..." (with the initiator) had better be the saved
value.  A transport such as iSCSI can't redefine how the upper layer
operates.  SCSI mode pages have a well defined behavior involving Current,
Saved, and Default pages.

I would prefer iSCSI to be silent on the "default value" of any mode page
field.  In SCSI (regardless of the transport) the default value of any given
mode page field is up to the target vendor.  Initiators choose to either a)
accept the default, b) temporarily change the current setting by issuing a
mode select (without save), or c) change the current setting via mode select
with the Save option, requesting the target to remember the new value after
any resets, power cycles, or in the case of iSCSI, new "sessions".

Also, on a related note, version 7-93

Appendix D. Login/Text Operational Keys
22 ImmediateData

Contains the folling text:
"This field sets the D field in the Disconnect-Reconnect mode page. The
value one of the D field means ImmediateData=no."

First, there is no 'D' field.  

Second, this appears to be the last text parameter that tries to modify a
mode page.  I agree with the move to separate text parameters from mode
pages and feel that there is no need for this one to be associated with any
mode page.

Charles Binford
Pirus Networks
316.315.0382 x222

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 7:04 PM
To: IPS Reflector
Subject: iscsi : default iscsi mode page settings.

All,

Here's a few examples :

Comments ?

Regards,
Santosh

negotiation if
then only
can this
be
the

---

From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]>
Date: Thu, 20 Sep 2001 20:26:15 +0200

I would say whatever is a MUST to be known for the protocol to operate
correctly must have a default value. But we can divide it in two parts

a) default login state parameters for the SCSI device and 
b) mode pages state of SCSI device. 

so this makes sure that during logon the protocol will operate correctly
with default values and thereafter the initiator can do a mode sense to read
the parameters of the device and correspondingly configure itself with the
mode parameters of the SCSI LU device.

and even if some defaults ghave to be set then EMDP should be 0 because
there are still some devices that donot support disconnect-reconnect.

Sanjeev

-----Original Message-----
From: Robert Snively [mailto:[email-masked]]
Sent: Thursday, September 20, 2001 7:48 PM
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

> From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:[email-masked]]
> 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
> 
> Sent: Thursday, September 20, 2001 2:04 AM
> To: IPS Reflector

---

From: Robert Snively <[email-masked]>
Date: Thu, 20 Sep 2001 10:47:34 -0700

Your choice.

Bob

---

From: Santosh Rao <[email-masked]>
Date: Thu, 20 Sep 2001 16:54:08 -0700

Julian Satran wrote:

> Santosh,
>
> Please help this list by pointing to the specific SCSI standards where the
> mode page settings a) forbid default values

Julian,

I can't find anything in the scsi protocol standards (SPC-2, SAM-2)  that explicitly
forbid default setting specification for mode pages. However, per my understanding, this
is not the usual practice and mode page defaults are device specific. [which is also
what Charles Binford & Bob Snively seemed to imply in their mails.)

However, even if iscsi did recommend a profile of mode page defaults in the draft, such
defaults are not to be binding on implementations and should only be suggested as a
recommendation. i.e. the draft must not require that all devices use the same values in
their default mode pages.

Further, such defaults need to allow initiators to function correctly without requiring
explicit mode sense/select. Thus, any such default must be conservative in its settings
for EMDP and FirstBurstSize. (both set to 0 by default).

> b) specify what the initial
> (power-on, connection establishment) values have  to be for any protocol.

There's a reference to this in Section 7.8.6 of SPC-2 Rev 20 (dated 18 July, 2001).

Thanks,
Santosh

>
>      Regards,
>      Julo
>
>
>                     Santosh Rao
>                     <santoshr@cup.       To:     IPS Reflector <[email-masked]>
>                     hp.com>              cc:
>                     Sent by:             Subject:     iscsi : default iscsi mode page
>                     owner-ips@ece.        settings.
>                     cmu.edu
>
>
>                     20-09-01 03:04
>                     Please respond
>                     to Santosh Rao
>
>
>
> All,
>
>  - santoshr.vcf

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 21 Sep 2001 17:57:51 +0300

I thought you where concerned about "boot duration"? julo

                    "KRUEGER,MARJOR                                                      
                    IE                    To:     IPS Reflector <[email-masked]>        
                    (HP-Roseville,e       cc:                                            
                    x1)"                  Subject:     RE: iscsi : default iscsi mode    
                    <marjorie_krueg        page settings.                                
                    [email-masked]>                                                           
                    Sent by:                                                             
                    [email-masked]                                                      
                    mu.edu                                                               

                    20-09-01 21:54                                                       
                    Please respond                                                       
                    to                                                                   
                    "KRUEGER,MARJOR                                                      
                    IE                                                                   
                    (HP-Roseville,e                                                      
                    x1)"                                                                 

I vote for making the exchange of some text parameters MANDATORY, with no
defaults.

Marj

> From: Robert Snively [mailto:[email-masked]]
> Sent: Thursday, September 20, 2001 10:48 AM

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 21 Sep 2001 12:17:48 -0400

If there's no reasonable default it makes sense to mandate exchange of at
least this one text key.

Marjorie 

> From: Julian Satran [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 7:58 AM
> To: [email-masked]

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 21 Sep 2001 19:43:25 +0300

I just forgot - I had it on my list several times.  0 means no limit -Julo

                    Santosh Rao                                                         
                    <santoshr@cup.       To:     IPS Reflector <[email-masked]>        
                    hp.com>              cc:                                            
                    Sent by:             Subject:     Re: iscsi : default iscsi mode    
                    owner-ips@ece.        page settings.                                
                    cmu.edu                                                             

                    21-09-01 19:26                                                      
                    Please respond                                                      
                    to Santosh Rao                                                      

Charles,

"Binford, Charles" wrote:

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

You raise a good point here. Note that the iscsi definition of
FirstBurstSize
in its disconnect-reconnect mode page differs from SPC-2 definition in that
it
is silent about the semantics of a 0 value for the FirstBurstSize. Perhaps,
Julian can comment on whether this was intentional to indicate that 0
implies
no buffer available, or was an omission, in which case the wording needs to
be
fixed.

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

Agreed.

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

I am in favor of this technique as well. As I have argued in the past,
dependence on the mode sense/select for iscsi session parameters is not a
good
idea for several reasons :

   * Mode Sense/Select implementation may be a shared mode page
implementation
     and this can cause strange side effects on initiators when other
     initiators establish sessions with that target port and issue mode
select.
     It can result in mode select wars between initiators if they are
     attempting to use different settings and are concurrently operating
with
     the same target port.

   * Mode Sense/Select for setting session parameters is not
architecturally as
     clean as setting these parameters through login keys, since login keys
are
     an iscsi in-band technique, applied on a per session basis and only
affect
     the specified initiator & target port in that I-T nexus.

   * Usage of mode sense followed by mode select causes an increase in I/O
scan
     times since this implies 2 extra scsi commands per session
establishment.
     Compare this with setting these parameters through the use of login
keys,
     which is done during login phase, has no side effects of affecting
other
     initiators and is a faster and more optimal method.

   * Negotiating all session parameters through login keys allows initiator
     implementations to be simpler since they can avoid having SCSI command
set
     code in the iscsi initiator drivers.

For all of the above reasons, I am very much in favor of using login keys
for
negotiating session parameters, rather than dependence on mode
select/sense.

     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
t
> the mode pagan at all.  (my preferred choice)

This is my preferred choice as well. Going with these choices will keep
initiator implementations simpler, optimize session establishment time [and
thereby, I/O scan time for initiators], avoid mode select wars and other
side
effects of shared mode pages on iscsi initiator drivers.

I would like to request folks to re-consider the use of mode sense/select
for
setting session parameters given the above listed reasons. My preference is
to
only depend on iscsi login keys and state that iscsi has no meaning for the
disconnect-reconnect mode page.

Regarding the "Enable CRN" issue, I will reply in a separate mail.

Thanks,
Santosh

     Charles Binford
     Pirus Networks
     316.315.0382 x222

     -----Original Message-----
     From: Santosh Rao [mailto:[email-masked]]
     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

     > > > > > Similarly, there is no statement on MaxOutstandingR2T.

#### santoshr.vcf has been removed from this note on September 21 2001 by
Julian Satran

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 22 Sep 2001 07:06:14 +0300

That is not my reading of the map. The unsolicited payload buffer size is a
"data sink" attribute. The data sink is the SCSI engine and not the iSCSI
layer.

Julo

                    Santosh Rao                                                         
                    <santoshr@cup.       To:     [email-masked]                        
                    hp.com>              cc:                                            
                    Sent by:             Subject:     Re: iscsi : default iscsi mode    
                    owner-ips@ece.        page settings.                                
                    cmu.edu                                                             

                    21-09-01 21:50                                                      
                    Please respond                                                      
                    to Santosh Rao                                                      

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
<[email-masked]>
>                     <CBinford@piru       cc:
>                     s.com>               Subject:     RE: iscsi : default
iscsi mode
>                     Sent by:              page settings.
>                     owner-ips@ece.
>                     21-09-01 16:54
>                     to "Binford,
>                     Charles"
other
to
> mean "no limit".  I believe that is exactly the opposite of what your are
and
> unsolicited data know how much he can send.  Options I see are:
spec).
a
with
> - reflect the login specified value in firstburstsize during mode sense.
no
> I think we need to discuss the 2 issues of login key defaults & mode page
> defaults seperately :
>
> I am in favor of defining conservative defaults. Those initiators needing
through
> an async message). The async message does contain these values and thus,
it
> 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
either
> be prepared to do the extra work of issuing mode sense/select to enable
ensure
> 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
> In particular, the following defaults are required, if it is decided to
>    * MaximumBurstSize = 512 units (as it currently defined. Targets can
>      request less data in its R2T and send shorter data-in sequences, if
> The FirstBurstSize ***MUST*** be set to 0 and any initiators wishing to
use
query/set
> these values. The above default setting of 128 is  in-appropriate since :
>
un-solicited
> b) it forces targets to ensure that 128 * 512 = 64K of un-solicited data
is
turning
level
> Could anybody comment on why CRN (a ULP feature) needs to be enabled in
an
> 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

#### santoshr.vcf has been removed from this note on September 22 2001 by
Julian Satran

---

From: "Julian Satran" <[email-masked]>
Date: Mon, 24 Sep 2001 07:25:00 +0300

It has exactly the FCP-2 meaning. Julo

                    "Elliott, Robert"                                                         
                    <Robert.Elliott@c       To:     "IPS Reflector" <[email-masked]>         
                    ompaq.com>              cc:                                               
                    Sent by:                Subject:     RE: iscsi : default iscsi mode page  
                    [email-masked]        settings.                                        
                    .edu                                                                      

                    24-09-01 02:09                                                            
                    Please respond to                                                         
                    "Elliott, Robert"                                                         

> Sent: Friday, September 21, 2001 2:27 PM

> > If an initiator cares about any settings it better run MODE SENSE
> > to set them.  In a multi-initiator environment with various kinds

(I meant both MODE SENSE and MODE SELECT)

> > of reset events occuring on the SAN, an initiator can't be sure
> > of the state of a mode page.  (see the tape problem discovered by
> > Veritas in FCP-2 public review; tape mode pages were reset without
> > the knowledge of the application, breaking backups).
>
> Isn't this all the more reason to avoid setting FirstBurstSize
> through a mode page and use a login key for this ? Shared mode
> pages can cause some strange side effects on I/Os that are
> using un-solicited data.

If there were not already a FirstBurstSize for other protocols
controlled by the mode page, I'd agree - these protocol-specific
fields shouldn't be controlled by mode pages, which can be
changed by applications at any time.  They ought to be properties
of the login session and controlled only by the iSCSI drivers.

However, it has been defined this way for other protocols, so
I think a compatible control is needed for iSCSI.  This makes
protocol bridges simpler, and will avoid confusing software that
does try to use these mode pages.  A page that appears when
a FC target is connected to a host via FC should also appear
with the same meaning when presented through an iSCSI bridge
via Ethernet.

As Sanjeev noted in another email, this mode page is LU specific
which would be hard to emulate in the login key approach.

> > > ==============================
> > > ...
> > ...
> Does the EPDC bit verify the CRN capabilities of both the target
> FCP layer and the target SCSI ULP (device server) ? One would think
> the capabilities of the 2 layers need to be checked through seperate
> bits. The device server's ability to support CRN is a SCSI ULP
> feature and seems more like a bit in the Control Mode Page.
> (does not exist today ?). The target FCP's CRN capability is
> tested through the FCP specific EPDC bit in the FCP
> specific lun control mode page.

The CRN is carried as part of the IU (aka PDU), so I think of it as
part of the iSCSI layer, not the SCSI layer.  Stuff in the CDBs
is what the SCSI layer deals with.  Enabling or disabling CRN is
done through a mode page, which is SCSI layer activity.  For
protocol-specific mode page fields (like EPDC and FirstBurstSize)
the SCSI layer has to talk to the iSCSI layer to read/write the
controls.

The disconnect-reconnect mode page has fields that can apply to
most different protocols like FirstBurstSize.  Provided the
semantics are the same, any protocol offering those features should
use the mode page to control them.

New issue
=========
iSCSI's FirstBurstSize does appear to have one difference from
that described in SPC-2 and FCP-2: iSCSI-07-90 requires the entire
transfer fit in the FirstBurstSize if enabled, while SPC-2/FCP-2
have no such restriction.  I'd like to see it work the same as
the other protocols.

iSCSI:
"It is also an error for an initiator to send more data, whether
immediate or as separate PDUs, than the SCSI limit for first
burst."

SPC-2:
"The FIRST BURST SIZE field indicates the maximum amount of data that
may be transferred to the target for a command along with the command."

FCP-2:
"...If the maximum amount of data has been transmitted, but more data
remains to be transferred, the target shall request that data with
subsequent FCP_XFER_RDY IUs."

---
Rob Elliott, Compaq Server Storage
[email-masked]

---

From: "John Hufferd" <[email-masked]>
Date: Tue, 25 Sep 2001 10:53:39 -0700

Julian.
Thank you for taking the time to express your views, in this way.  That
type of dialog can help push the debate forward.

Now let me expressed some views that I hold, and ask you to let me know
where I am wrong.

I have viewed the Buffer/Cache Manager as an independent entity that
belongs to the "Box" (or the embedded OS).  I have not viewed the
Buffer/Cache Manager as being a SCSI entity.  Instead I have viewed SCSI as
a user of the Box services called Buffer/Cache Manager.

Likewise, I have viewed the Transport as a user of this same Buffer/Cache
Manager(B/CM).

I can understand that the B/CM can have certain input and output flows that
it needs to be designed to handle.  Further I understand that part of that
design should factor in the needs of the SCSI LUs to consume Buffer Space.
But the requirements of the Transport also needs to be factored in.

As a result, I expect that there needs to be some defaults per link, and if
the Transport is to negotiate Burst values, there probably needs to be an
interface with the B/CM to ensure that the right values are negotiated.

However, it is not clear that it makes sense for the iSCSI layer to keep
polling (interfacing to) the B/CM just in case a SCSI command has changed
the Mode Pages, nor does it see reasonable for iSCSI to inspect the CDBs to
see if its mode Page items are being changed.

So if it is not affected by a SCSI command and is only handled with
Login/Text Command, then an approprate interface between the B/CM can be
used to query about the approprate values to negotiate at any specific
time.  I think this is a reasonable and approprate design.

This is why I have come to the conclusion that the burst values (other then
defaults, if any) should not be a Mode Page item.

Now it is clearly possible that I have missed something important here, so
please let me know what it is.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

Julian Satran/Haifa/IBM@[email-masked] on 09/24/2001 11:28:15 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: iscsi : default iscsi mode page settings.

Sanjeev,

We can set any of those parameters wherever you want as its clearly a
protocol prerogative.
The one thing that I am trying to avoid is having one parameter being
handled in two ways (It caused me more trouble that it was worth in the
past and required a lot of logic).
As such we have two consideration when selecting location:

   legacy
   what layer is the most affected by it

It looks to me that association of sink buffers at targets is mostly a SCSI
issue and it is dependent on the device type,  the relative speed of the
transport and device, QOS requirements at device.  Data is already in the
SCSI realm (not anymore individual PDUs but sequences that are governed by
SCSI needs and (including fairness rules between LUs attached to the same
bus). That is why we have those bursts - iSCSI does not need them - SCSI
may need them for multiplexing and buffer limitations of its own.   As far
as iSCSI is concerned bursts are just trouble.  But without them a pipe
with a limited window will serve one LU and even beyond it's real
capabilites.   The multiplexing capability is needed by SCSI and is offered
in different ways on different transports. Some "buses" have a "built-in"
multiplexing capability. TCP does not and iSCSI adds it to it by the "burst
limitation".

All this said and based on an earlier comment made by Bob Snively that this
could be a good criteria for splitting parameters between text and mode
pages - I think that the split we have now, even if not built according to
every developers wet dreams, is reasonable.

Julo

                    "Sanjeev Bhagat
                    \(TRIPACE/Zoetermee       To:     "Santosh Rao"
<[email-masked]>, John
                    r\)"                       Hufferd/San Jose/IBM@IBMUS
                    <iscsi_t10@sanjeevb       cc:     Julian
Satran/Haifa/IBM@IBMIL,
                    hagat.com>                 <[email-masked]>
                                              Subject:     Re: iscsi :
default iscsi mode page
                    25-09-01 01:58             settings.
                    Please respond to
                    "Sanjeev Bhagat
                    \(TRIPACE/Zoetermee
                    r\)"

Julian, Santosh,

Can we make all the SCSI mode page paramters be made as login keys? Why
should they be kept in a seperate mode page at all??

Sanjeev
----- Original Message -----
From: "John Hufferd" <[email-masked]>
To: "Santosh Rao" <[email-masked]>
Cc: "Julian Satran" <[email-masked]>; <[email-masked]>
Sent: Monday, September 24, 2001 10:34 PM
Subject: Re: iscsi : default iscsi mode page settings.

>
> In addition to what Santosh said,  If I understand this right,
> I think it is a problem for iSCSI to have to keep going across layers to
> determine what the values are.  Since iSCSI Target will not see the CDB
> that caused the values to change.
>
> Now if the value in the mode page is only the default, that would be a
> different issue.
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136
> Internet address: [email-masked]
>
>
> Santosh Rao <[email-masked]>@ece.cmu.edu on 09/24/2001 12:28:43 PM
>
> Sent by:  [email-masked]
>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   [email-masked]
> Subject:  Re: iscsi : default iscsi mode page settings.
>
>
>
> Julian Satran wrote:
>
> > I can sympathize with you wanting to use most of the parameters in
iSCSI
> -
> > but the values are in fact restrictions that SCSI places on iSCSI.
>
> Julian,
>
> I'm confused by your response.
>
> The SPC-2 description of Disconnect-Reconnect mode page indicates that :
> "The parameters appropriate to each protocol and their interpretation for
> that protocol may
> be specified in the individual protocol documents".
>
> FYI, SPI[-4] has chosen not to attach any semantics to FirstBurstSize for
> the pSCSI
> transport. Thus, iscsi is within its rights to declare this field as
> reserved and attach no
> meaning to it in the mode page. The FirstBurstSize can be negotiated
during
> iscsi login
> through a login key.
>
>
> > Nevertheless the discussion is rather academic because SCSI can hand
> those
> > parameters to iSCSI.
>
> Again, I'm confused by your response. The reasons I'm suggesting the use
of
> a login key
> instead of the mode page method are :
>
>    * More accurate scope (applies only to this I-T nexus).
>
>    * More optimal negotiation and reduced overhead in the establishment
of
> the I-T nexus. (2
>      less SCSI commands per I-T nexus establishment.).
>
>    * Enables faster I/O scan times due to lesser on-the-wire activity
> during I-T nexus
>      establishment.
>
>    * Allows less room for error in the I-T nexus establishment (no
> possiblity of failure to
>      establish I-T nexus due to mode sense/select command failure).
>
>    * Avoids mode select wars that can occur when target uses shared mode
> pages.
>
>    * Simpler initiator implementations since they can avoid embedding
SCSI
> command set
>      knowledge as well as code to build/parse SCSI commands. Also, they
can
> avoid extra code
>      that is required to snoop for CHECK CONDITION with (sense key=UA,
ASC
> ="mode parameters
>      changed") in order to re-issue a mode sense to determine new values
> for FirstBurstSize.
>
>    * Less code to interact with SCSI ULP application client to
co-ordinate
> the mode page
>      values b/n the ULP & LLP.
>
>    * Can use un-solicited data from the very first scsi command in the
> session.
>
> I don't consider any of the above reasons to be academic and would like
to
> know which ones
> among the above do you believe are academic and why ?
>
>
> > SCSI can handle those parameters dynamically. iSCSI may have trouble
> > handling this type of negotiation dynamically over several connections.
>
> This is exactly the kind of stuff we don't need and should actually be
> trying to avoid. What
> good does dynamically changing FirstBurstSize serve ? Dynamically
changing
> FirstBurstSize
> would only be achieved with least side-effects if :
> 1) The mode select implementation on target is not using shared mode
pages.
> 2) The initiator has quiesced I/O prior to issuing the mode select for
the
> change.
>
> Neither of the above 2 conditions would typically apply and any dynamic
> change of
> FirstBurstSize would only cause initiators to see a bunch of side-effects
> such as :
> a) Active outbound I/Os aborted by the target with a CHECK CONDITION due
to
> "not enough
> un-solicited data".
> b) UA CHECK CONDITION for "mode parameters changed".
>
> In the interests of simplification and avoiding disruption of active I/O,
> such modifications
> must be avoided as far as possible. One way to achieve that is to use a
> login key and make
> it LO.
>
>
> >
> > Resource-wise (as Bob Snively has pointed out) those are SCSI issues.
> >
> > A nice way out would be to ask T10 for a text mode negotiaton :-)
>
> Once again, I'm perplexed by your response. I'm not saying that text mode
> negotiation is the
> reason I suggest moving this to a login key. The main objective is to
> isolate such
> negotiation within the iscsi layer in an iscsi specific PDU that is a
part
> of the iscsi
> login process.
>
> Hope you will consider all of the above factors.
>
> Thanks,
> Santosh
>
> ps : [I wonder if there are any others on this list who care to voice
their
> opinion on this
> issue. (??). ]

---

From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]>
Date: Tue, 25 Sep 2001 21:04:46 +0200

Hello John I agree with you completely.

The confusion going over here is that the Buffer/Cache manager that you are
dscribing below is being thought over as a part of SCSI realm but i donot
agree with that. Specially the line from Julian "It looks to me that
association of sink buffers at targets is mostly a SCSI issue and it is
dependent on the device type,"

It is not at all a SCSI issue. An iSCSI target has to bring in the data in
proper order so that it can be transferred into LU properly. The only
association that can be thought of with a SCSI layer is that relative speed
of transfer of data from network and the transfer speed of data from SCSI
bus to SCSI device. If that is considered any sort of association then it is
an association of both the transport layer and SCSI Bus.

The reason I suggested to put all the SCSI Mode page parameter into login
keys is that the iSCSI target doesnt have to scan the commands lying within.
It doesnt have to poll whether a mode select command is going or not?? This
will make the implementation of the box described below by you much easier.
However if we think of a complete SCSI target which has box and SCSI built
in will not have to face this problem.

I would like to know the reasoning as to why is it not better to keep all
the SCSI mode page parameters not as login keys. The two main benefits of
putting FirstBurstSize only into login keys  are the following

1. the the initiator will have to make one command less to target during
login operation( it will not have to do any mode sense)
2. no snooping of command by black box implementation

if we put all other mode page parameters into login keys they will benefit
from both the above two things and it is also important to note that putting
alone Firstburstsize into login keys will not make any command less because
the initiator anyway has to make a mode sense commannd for other parameters
of SCSI mode page.

Thanks,
Sanjeev

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Tuesday, September 25, 2001 7:54 PM
To: Julian Satran
Cc: [email-masked]
Subject: Re: iscsi : default iscsi mode page settings.

Julian.

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

Sanjeev,

   legacy

Julo

                    "Sanjeev Bhagat

Julian, Santosh,

Sanjeev
----- Original Message -----
From: "John Hufferd" <[email-masked]>
To: "Santosh Rao" <[email-masked]>
Cc: "Julian Satran" <[email-masked]>; <[email-masked]>
Sent: Monday, September 24, 2001 10:34 PM
Subject: Re: iscsi : default iscsi mode page settings.

iSCSI
during
of
of
SCSI
can
ASC
co-ordinate
to
changing
pages.
the
to
part
their

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 25 Sep 2001 22:00:43 +0300

John,

I understand this but then we have to move both and First and MaxBurstSize
and we have created a problem for SCSI or BCM.

My assumption was that as the cache is mainly a SCSI design (transport uses
it only as a source and sink - transport has it's own buffers that form the
window) dependent on device characteristics it may want to control the
buffers and the traffic mix.

And the mode page table will be accessible to both - obviously with only
one of them having write rights.

Regards,
Julo

                    John                                                                    
                    Hufferd@IBMUS        To:     Julian Satran/Haifa/IBM@IBMIL              
                                         cc:     [email-masked]                            
                    25-09-01 19:53       From:   John Hufferd/San Jose/IBM@IBMUS            
                                         Subject:     Re: iscsi : default iscsi mode page   
                                         settings.(Document link: Julian Satran - Mail)     

                                                                                            

Julian.

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

Sanjeev,

   legacy

Julo

                    "Sanjeev Bhagat

Julian, Santosh,

Sanjeev
----- Original Message -----
From: "John Hufferd" <[email-masked]>
To: "Santosh Rao" <[email-masked]>
Cc: "Julian Satran" <[email-masked]>; <[email-masked]>
Sent: Monday, September 24, 2001 10:34 PM
Subject: Re: iscsi : default iscsi mode page settings.

iSCSI
during
of
of
SCSI
can
ASC
co-ordinate
to
changing
pages.
the
to
part
their

---

From: "John Hufferd" <[email-masked]>
Date: Tue, 25 Sep 2001 13:25:41 -0700

Julian,
First I think that a good design will attempt to have a Zero Copy type
buffering operation, from the time the data arrives from the Transport
through the use by SCSI.

However, perhaps this can be resolved a different way (perhaps you have
even suggested it):

Suppose the only way the Burst parameters (and maybe other transport
parameters) can be set is via the Login/Text commands, and yet let the
values be seen by either Login/Text or the Mode Page commands, perhaps all
requirements can be met, and we can get off this discussion.

In other words, iSCSI will see the values and can save it in local working
variables, while also setting the Mode Page stuff.  The implementation
would be that Transport Mode-Page items can not be set by SCSI commands.

.
.
.
John L. Hufferd

Julian Satran/Haifa/IBM@[email-masked] on 09/25/2001 12:00:43 PM

To:   [email-masked]
cc:

John,

Regards,
Julo

                    John
                    Hufferd@IBMUS        To:     Julian
Satran/Haifa/IBM@IBMIL
                                         cc:     [email-masked]
                    25-09-01 19:53       From:   John Hufferd/San
Jose/IBM@IBMUS
                                         Subject:     Re: iscsi : default
iscsi mode page
                                         settings.(Document link: Julian
Satran - Mail)

Julian.

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

Sanjeev,

   legacy

Julo

                    "Sanjeev Bhagat

Julian, Santosh,

Sanjeev
----- Original Message -----
From: "John Hufferd" <[email-masked]>
To: "Santosh Rao" <[email-masked]>
Cc: "Julian Satran" <[email-masked]>; <[email-masked]>
Sent: Monday, September 24, 2001 10:34 PM
Subject: Re: iscsi : default iscsi mode page settings.

iSCSI
during
of
of
SCSI
can
ASC
co-ordinate
to
changing
pages.
the
to
part
their

---

From: Robert Snively <[email-masked]>
Date: Tue, 25 Sep 2001 16:10:06 -0700

I hope that neither of these is necessary to the conclusion,
because 

	a)  there is explicitly a SCSI CDB to set transport mode
	page parameters (MODE SELECT, Protocol Specific Port page) 
	and 
	b)  zero copy can only be performed a Protocol DU at a time,
	since EMDP may request that SCSI data be delivered even
	though part of the data for a command is still missing.

I also hope that you do not need to implement different
characteristics for each logical unit, which is allowed by
the LUN-oriented MODE SELECT commands, but is disallowed by
the transport layer negotiation.

> 
> By the way in my view there is no SCSI (CDB) command to set 
> transport mode
> page parameters. Also a zero copy buffer operation to SCSI is 
> only possible
> if there is no missing data in the buffer.
> 
> Regards,
> Sanjeev

---

From: "John Hufferd" <[email-masked]>
Date: Tue, 25 Sep 2001 16:10:03 -0700

Sanjeev,
Zero copy is intended for the main (performance) path.  But its use in
error situations depends on the implementation, specifically the buffer
chaining technique that is in effect.

.
.
.
John L. Hufferd

"Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]> on 09/25/2001
03:06:47 PM

To:   John Hufferd/San Jose/IBM@IBMUS, Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  RE: iscsi : default iscsi mode page settings.

Julo, John J&J :),

So I see that you basically come to the point that FirstBurstSize and
MaxBurstSize field be put into the login keys. If you agree this, and if i
have to see the SCSI mode page parameters, the only odd field left out is
EMDP (enable modify data pointer). This should also be included in
login/text keys. Why should this be left out alone? The inititator will
need
to make an extra mode sense command to know this. We should either keep all
three parameters readable through mode sense command or login /text keys or
both.

By the way in my view there is no SCSI (CDB) command to set transport mode
page parameters. Also a zero copy buffer operation to SCSI is only possible
if there is no missing data in the buffer.

Regards,
Sanjeev

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Tuesday, September 25, 2001 10:26 PM
To: Julian Satran
Cc: [email-masked]
Subject: Re: iscsi : default iscsi mode page settings.

Julian,

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

John,

Regards,
Julo

                    John
                    Hufferd@IBMUS        To:     Julian
Satran/Haifa/IBM@IBMIL
                                         cc:     [email-masked]

Julian.

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

Sanjeev,

   legacy

Julo

                    "Sanjeev Bhagat

Julian, Santosh,

Sanjeev
----- Original Message -----
From: "John Hufferd" <[email-masked]>
To: "Santosh Rao" <[email-masked]>
Cc: "Julian Satran" <[email-masked]>; <[email-masked]>
Sent: Monday, September 24, 2001 10:34 PM
Subject: Re: iscsi : default iscsi mode page settings.

iSCSI
during
of
of
SCSI
can
ASC
co-ordinate
to
changing
pages.
the
to
part
their

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 26 Sep 2001 12:13:50 +0300

Sanjeev,

The point I was trying to make escaped your attention completely.   The 2
parameters we are talking about have
little bearing on the buffer/cache management. They are here to control
multiplexing. A target LU will release the bus/transport (and leave room in
the cache) for the use of other LUs.  That is why bursts are limited in
size.

Julo

                    "Sanjeev                                                                     
                    Bhagat               To:     John Hufferd/San Jose/IBM@IBMUS, Julian         
                    (TRIPACE/Zoete        Satran/Haifa/IBM@IBMIL                                 
                    rmeer)"              cc:     [email-masked]                                 
                    <sbhagat@tripa       Subject:     RE: iscsi : default iscsi mode page        
                    ce.com>               settings.                                              
                                                                                                 
                    25-09-01 21:04                                                               
                    Please respond                                                               
                    to "Sanjeev                                                                  
                    Bhagat                                                                       
                    (TRIPACE/Zoete                                                               
                    rmeer)"                                                                      

bus to SCSI device. If that is considered any sort of association then it

keys is that the iSCSI target doesnt have to scan the commands lying
within.

if we put all other mode page parameters into login keys they will benefit
from both the above two things and it is also important to note that
putting
alone Firstburstsize into login keys will not make any command less because
the initiator anyway has to make a mode sense commannd for other parameters
of SCSI mode page.

Thanks,
Sanjeev

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Tuesday, September 25, 2001 7:54 PM
To: Julian Satran
Cc: [email-masked]
Subject: Re: iscsi : default iscsi mode page settings.

Julian.

.
.
.
John L. Hufferd

To:   [email-masked]
cc:

Sanjeev,

   legacy

Julo

                    "Sanjeev Bhagat

Julian, Santosh,

Sanjeev
----- Original Message -----
From: "John Hufferd" <[email-masked]>
To: "Santosh Rao" <[email-masked]>
Cc: "Julian Satran" <[email-masked]>; <[email-masked]>
Sent: Monday, September 24, 2001 10:34 PM
Subject: Re: iscsi : default iscsi mode page settings.

iSCSI
during
of
of
SCSI
can
ASC
co-ordinate
to
changing
pages.
the
to
part
their

---

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 25 Sep 2001 22:14:12 -0700

>Julian and Santosh,
>
>Whether FirstBurstSize should be a text key or not,
>IMHO, is (mostly) dependent on the current implementations.
>Santosh rightly pointed out several drawbacks of 
>mandating a new set of mode select/sense operations
>that are totally iSCSI-specific since the legacy SCSI
>stack (class drivers, services/midlayer) will have no
>clue about them.  OTOH, if most of today's SCSI stacks
>_do_ perform this mode parameter manipulation in disconnect-
>reconnect mode page, that would be a strong argument to 
>leave FirstBurstSize as a mode page parameter.

Anything iSCSI specific should attempt to follow other iSCSI
methods of configuration (e.g. text keys).  We should really
be driving towards a single method of parameter negotiation
and configuration - especially when the legacy methods
have no clue about the new parameters and would require upgrades.

Paul

---

From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]>
Date: Wed, 26 Sep 2001 20:03:04 +0200

John,

the firstburstsize will not be included in the SCSI device driver. It has to
be done either by iscsi driver or any application passsing command to iscsi
driver.

Firstburstsize parameter depends on the buffer capacity of the Target and
application client. In most cases this will be a limitation at target's end
which has limited buffersize in which it can take the data from service
delivery subsystem. The application client on other hand can keep queuing
the requests and ask the data from the OS corresponding to the command.

The role of SCSI driver is to pass the commands as it is to the lower layer
in the stack. It does not probe any CDB, although it is fully capable of
doing it.

Regards,
Sanjeev

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Wednesday, September 26, 2001 4:37 PM
To: CONGDON,PAUL (HP-Roseville,ex1)
Cc: [email-masked]'; ips
Subject: RE: iscsi : default iscsi mode page settings.

Does anyone know of where a Legacy function would exist, in the Host which
would do anything with FirstBurstSize?  I am assuming it would have to be
in the SCSI Device Driver, and since we have iSCSI instead, that may not be
an issue.
I could be wrong but I do not think that it occures in the SCSI Class
Drivers.
And I do not think it ocures in the File Systems, so where does this Legacy
function we are worried about occure?
If it is in the SCSI Device Driver it is NOT an issue.

.
.
.
John L. Hufferd

"CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>@ece.cmu.edu on
09/25/2001 10:14:12 PM

To:   "[email-masked]'" <[email-masked]>, ips <[email-masked]>
cc:
Subject:  RE: iscsi : default iscsi mode page settings.

Paul

---

From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]>
Date: Wed, 26 Sep 2001 21:02:40 +0200

John, julian, Santosh

Agreed, but it depends where the protocol specific code is implemented.

Let us take example of Windows 2k

the command startes from application and flows down to file system to SCSI
ULP to Fileter drivers, SCSIPORT driver to SCSI Miniport driver and then to
HBA. 

Now in order to implement iSCSI in windows the commands can be diverted into
two paths 

1. after the SCSI ULP (class drivers). A filter driver or a custom written
parallel SCSIPORT driver may divert it to (iscsi protocol specific) TDI
client driver and so to TCP /IP stack 

or 
2. 
  a.)it flows down untill SCSI Miniport driver which can further pass it
(iscsi protocol specific) TDI client driver and then to TCP transport layer
...... etc etc

or 
  b>.)alternatively for step 2 it can go directly to an iSCSI HBA (with
TCP/IP accelerator, Ethernet built in)

In case 1, 2a the FirstburstSize will be set in the iscsi protocol specific
TDI client driver and in case 2b it will be set in SCSI miniport itself.

Clearly it will be set only at the place where the transport protocol
specific layer.

Regards,
Sanjeev

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Wednesday, September 26, 2001 7:40 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iscsi : default iscsi mode page settings.

John,

I suspect that in most cases these mode page settings would not be done, 
since most stacks are still SCSI-2 based.
Hence, any SCSI LLPs that do provide support for these transport specific
mode pages (ex : FCP-2 implementations) would probably be issuing these 
mode sense/select's from within the LLP (miniport driver, HBA driver, etc).

The file system and wedge drivers do not muck with these, as you already
pointed out.

Since these mode pages have transport specific semantics, any SCSI ULP
(ex : class driver) that attempts to issue mode sense/select for transport
specific mode pages would first need to interact with some transport
specific code to determine which transport is being used and what mode
page format is to be used. Thus, any such class driver would need an
upgrade to understand the iscsi transport specific mode pages.

Even if there are some management applications that may be trying to set
these parameters through pass thru mode sense/select commands, they would
need to now be upgraded to understand iscsi specific versions of these
transport mode pages. Further, any such management app. would also need to
develop mechanisms to issue pass-thru text commands or some other
mechanism if it wished to tweak iscsi parameters.

Hence, I agree with you that there should not be any legacy issue here.
Any layer or management app that mucks with iscsi parameters will need an
upgrade anyway and they might as well be upgraded to use a single
mechanism, login keys.

I think we've beaten this issue to death, and suggest that we call for
consensus on this issue and move onto other issues.

Regards,
Santosh

-- 
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################