Subject: Re: iscsi : default iscsi mode page settings - Consensus call

From: Ralph Weber <[email-masked]>
Date: Mon, 01 Oct 2001 10:56:31 -0500

Santosh,

I was not aware that you were proposing that iSCSI
not support the Disconnect-Reconnect mode page at
all.  Now that would be a radical step.

If on the other hand you are proposing that iSCSI
have a Maximum Burst Size but refuse to provide
that information in the Disconnect-Reconnect mode
page whose page code iSCSI devices accept, then
I think you are at least violating the ISP charter
as regards interactions with T10 standards (specifically
SPC-2).

This is my rather strongly held opinion and unless
you find an argument that is substantially better
than anything presented to date I expect to maintain
this opinion to the bitter end.

Ralph Weber

---

From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <[email-masked]>
Date: Mon, 1 Oct 2001 21:25:39 +0200

i vote for no as well.

-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Monday, October 01, 2001 8:38 PM
To: [email-masked]
Subject: RE: iscsi : default iscsi mode page settings - Consensus call

I vote NO.

Eddy

-----Original Message-----
From: Dev - Platys [mailto:[email-masked]]
Sent: Monday, October 01, 2001 1:18 PM
To: IPS Reflector
Cc: [email-masked]
Subject: RE: iscsi : default iscsi mode page settings - Consensus call

All,

I prefer that the default value for ImmediateData be set 'no'. This
allows
the initiators/targets, that support immediate data or not, to negotiate
this value with minimal handshakes during login phase. I feel that
discussions on the benefits of immediate data, complexity of
implementing it
etc, though
useful, have gone off path, to determine what could be the default
value.

My vote is for the default value of 'Immediatedata' to be set as 'No'.

Thanks

Deva
Adaptec

---

From: "Julian Satran" <[email-masked]>
Date: Mon, 1 Oct 2001 22:44:30 +0300

Ralph,

That was the path and endlless-month mail exchange (with very little new
argument in each round) has brought us.
In summary:

   it was considered bad form to leave 2 layers (the layering argument) own
   (change) mode page variable
   we attempted to segregate the variables and argue that the burst-sizes
   are used by iSCSI but their values will be dictated by SCSI as they
   determine the multiplexing capabilities of the transport
   against this the argument was made that the mode page mechanism is hard
   to handle and a specific protocol has anyhow a mode page setup that is
   specific (that is not the current practice but is not explicitly
   forbidden by SPC)
   with all the above it makes little sense to support any mode page
   content (as SCSI can't control any value)

My question is - would returning the mode pages with a read-only content
make any-sense (considering that SCSI can't directly control the burst
values and that is the only reason SCSI may want them)?

The alternative would be (as I attempted) to leave both burst values under
SCSI control (where layering will require them to be) against which a
majority (of 2) brought the "very hard to handle" argument (which BTW has
some ground as text mode negotiations are easier than the set/enquiry ) and
reopen the consensus-call.

Regards,
Julo

                    Ralph Weber                                                               
                    <ralphoweber@compu       To:     IPS Reflector <[email-masked]>          
                    serve.com>               cc:                                              
                    Sent by:                 Subject:     Re: iscsi : default iscsi mode page 
                    [email-masked].        settings - Consensus call                       
                    edu                                                                       

                    01-10-01 17:56                                                            
                    Please respond to                                                         
                    ENDL_TX                                                                   

Santosh,

Ralph Weber

---

From: Robert Snively <[email-masked]>
Date: Tue, 2 Oct 2001 08:36:18 -0700

Folks,

In an offline discussion, we have picked at a thread
central to this fabric.  That is basically the view that
one has of the structure of targets.

------------------   Note sent out a day ago  ---------------

Traditional network environments talk from one big host
memory to another big host memory.  In the storage space, the
memory in the target is actually distributed between whatever
caching and preprocessing space the target platform may have
and the space held by each logical unit.  In some cases (RAIDs)
the distribution is heavily in favor of the target platform
cache.  In others (tapes), individual logical units may have
100s of Megabytes of buffering which are not available to other
logical units.  If you have mixed types of logical units or
if you have the memory distributed unevenly among the logical
units, different values are normal among different LUs.

Different sessions to the same LU may also have different
properties.  In particular, the LU may give away resources
freely for the first few sessions, but more sparingly for
subsequent sessions.  Alternatively, the LU may share the
resources dynamically, providing UNIT ATTENTION indications
if it must change the values.

The iSCSI target is merely a handy portal to the logical
units and device servers, which really run the show.  While
many targets are simplified, sharing parameters across LUs
and sessions, there is no requirement for that.  Sophisticated
devices may have individual parameters for each LU and
session.  iSCSI is trying hard to ignore the differences
between storage and networking devices, but the differences
are justified and genuine.

----------------   Some of the questions that triggered the note  -----

> Are you saying that these parameters need to be able to have different
> values for each LU among several LUs of single target in a single
> session?
> 
> Also would different sessions to the same LU all need to use the same
> value?

---------------  And a succinct summary of the thoughts  ---------------

If I understand correctly, in your view, such parameter negotiations
should be per initiator and per LU.  Parameters which are unique per
logical unit can be set (or "negotiated") *only* via mode pages.
Whether or not changing the value for one logical unit changes it for
others would be target end implementer's choice, subject to appropriate
parameter change notifications to the initiator(s).  The values
negotiated during login would be per initiator and per target
default/initial values to be used when per LU mode pages have not been
subsequently modified by this initiator.

I am not reading that you think these values should not be settable at
the per session level.  Only that you believe there is a real need to be
able to change them at the per LU level so that the per session values
can be over-ridden for specific LUs.  Changing the value for one LU via
the mode pages would not have to change it for other LUs in this session
nor for other sessions to this LU.

Is that about right?

---------  My answer would be yes  -------------------------------------

---

From: Robert Snively <[email-masked]>
Date: Tue, 2 Oct 2001 08:36:18 -0700

Folks,

---------------  And a succinct summary of the thoughts  ---------------

Is that about right?

---------  My answer would be yes  -------------------------------------

---

From: "John Hufferd" <[email-masked]>
Date: Tue, 2 Oct 2001 12:12:39 -0700

Bob,
I think I agree with the direction of the note, but need to be sure we are
on the same (mode) page:-)

If you are saying the some values that effect an LU should be in LU
specific Mode Pages, then fine in theory.  I just need to understand which
ones you are referring to.  Since many of the Session parameters must be
applied at the Transport, we need to know which iSCSI negotiated values you
feel should be in the LU specific mode pages?  Or did I miss understand you
statements?
.
.
.
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]

Robert Snively <[email-masked]>@ece.cmu.edu on 10/02/2001 08:36:18 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  RE: iSCSI : default iSCSI mode page settings - Consensus call

Folks,

---------------  And a succinct summary of the thoughts  ---------------

Is that about right?

---------  My answer would be yes  -------------------------------------

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 3 Oct 2001 19:54:07 +0300

Robert,

I agree. Per LU parameters have little or no relation to iSCSI.

Regards,
Julo

Robert Snively <[email-masked]>
Sent by: [email-masked]
02-10-01 17:36
Please respond to Robert Snively

        To:     [email-masked]
        cc: 

Folks,

---------------  And a succinct summary of the thoughts  ---------------

Is that about right?

---------  My answer would be yes  -------------------------------------