iSCSI - Change - proposal RE: Review of the 07 draft

["Julian Satran" <Julian_Satran@il.ibm.com>]

You have a good point.  We may want to change it to this definition and
leave it to SCSI (remove from appendix) and add an explicit MaxPDU.

Comments?

Julo

"Binford, Charles" <CBinford@pirus.com>@ece.cmu.edu on 13-08-2001 17:49:10

Please respond to "Binford, Charles" <CBinford@pirus.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: Review of the 07 draft



I agree with Julian about removing EMDP and FirstBurstSize from iSCSI
control.  I disagree on MaxBurstSize.

MaxBustSize defines DataPDU length only because we said it does.  We could
just as easily remove the relationship between DataPDU length and
MaxBurstSize.  I would prefer we let iSCSI control DataPDU length as it
does
today and change the meaning of MaxBurstSize under iSCSI to be more in line
with what MaxBurstSize means under other SCSI protocols.  As pointed out
earlier on this thread a generic SCSI mode page utility doesn't/shouldn't
know/care what the transport it.

The meaning of MaxBurstSize under FCP is largest FC Sequence a target can
send.  Since an FC class 3 target can send multiple Read data sequences to
the host with no handshake, the parameter is essentially a don't care for
reads.  For Writes it effectively governs the largest amount of data a
target can ask for on an XFER_RDY.

For iSCSI, I'd like to see MaxBurstSize be defined as one of the following:
- largest amount of data a target can ask for under a single R2T; or
- ignored.

My problem with the current definition is typical iSCSI DataPDU lengths are
relatively small (default 8K in the spec.)  The typical MaxBurstSize for
other protocols is much larger - 64K to 512K.

Charles Binford
Pirus Networks
316.315.0382 x222


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 11, 2001 5:50 PM
To: Robert Snively
Cc: 'deva@stargateip.com'; Robert Griswold; Eddy Quicksall; Jim Hafner;
ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


I think that for regularity it would be wise to remove completely EMDP and
FirstBurstsize from iSCSI control.
MaximumBurstSize defines the DataPDU length and is transport related
(affects iSCSI and less SCSI) and should stay under iSCSI control.


Comments?

Julo

Robert Snively <rsnively@Brocade.COM>@ece.cmu.edu on 10-08-2001 10:32:20

Please respond to Robert Snively <rsnively@Brocade.COM>

Sent by:  owner-ips@ece.cmu.edu


To:   "'deva@stargateip.com'" <deva@stargateip.com>, Robert Griswold
      <rgriswold@Crossroads.com>, Eddy Quicksall <ESQuicksall@hotmail.com>,
      Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  RE: Review of the 07 draft



Deva,

Both of you are right if iSCSI sticks to negotiating only
parameters related with the TCP connections, the iSCSI
session operational parameters other than EMDP and
burst length, and iSCSI security parameters.  Then, all
parameters relating to the normal SCSI activities, including
EMDP and burst length (which are required for SCSI, not iSCSI,
buffer management) would be negotiated in the normal
SCSI manner through the MODE SENSE/SELECT pages and everybody
would live happily ever after.

Otherwise, and especially with respect to EMDP and burst length,
I have to agree with Robert.

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110



-----Original Message-----
From: Dev [mailto:deva@stargateip.com]
Sent: Thursday, August 09, 2001 5:33 PM
To: Robert Griswold; Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


All,

I tend to disagree. The parameters for the iSCSI are negotiated between the
initiator and target.
If we allow the parameters to be changed through SCSI Mode select, how will
this work?

If parameters can be changed through SCSI Mode select then it will apply
only to Lead only connections.

So, we'll have

a) two methods to change the Lead only parameters common for the entire
session (one through mode select
and the other through text parameters)
b) Just iSCSI text command to change the connection specific parameters.

Does it not add to complexity having multiple ways to change the same
stuff?

Thanks

Deva
Platys communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Griswold
Sent: Thursday, August 09, 2001 1:36 PM
To: Eddy Quicksall; Jim Hafner
Cc: ips@ece.cmu.edu
Subject: RE: Review of the 07 draft


Eddy:

I actually have no problem with all mode pages (SCSI and iSCSI) being
accessible and changeable from standard SCSI mode commands.  My initial
response to this section was to propose a method that would be
acceptable to the authors of the iSCSI draft.  If there is desire in the
group to allow mode pages for the entire target to be manipulated from
the SCSI level, I think that is a better idea that the one I proposed.
I would assume that an iSCSI aware SCSI utility would understand the
iSCSI specific settings, and allow the user to make those changes.  What
I am really against, is the ability to modify standard SCSI mode page
settings from text messages, as that could lead to target behavior
changes outside of the understanding of the SCSI nexus.

To recap your thinking:  Allow iSCSI text messages to modify and read
iSCSI only mode settings (potentially allowing the reading if SCSI mode
settings), but allow SCSI mode commands to modify and read all target
mode settings, including iSCSI settings.  Is that what you are saying.
If so, I agree.

Bob

Robert Griswold
Technologist
Crossroads Systems, Inc.
512-928-7272

 -----Original Message-----
From:     Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
Sent:     Thursday, August 09, 2001 2:08 PM
To:  Robert Griswold; Jim Hafner
Cc:  ips@ece.cmu.edu
Subject:  Re: Review of the 07 draft

I don't like the idea of not letting a user of a SCSI utility be able to
change some of the parameters for iSCSI. Because they may be relevant to
him
and there may not be a user interface to the iSCSI driver. pSCSI sets
these
low level parameters via a standard mode set, so why not iSCSI?

It would be best if we could work out something where only the SCSI
layer
can set the mode pages. That would solve everything.

Eddy

----- Original Message -----
From: "Jim Hafner" <hafner@almaden.ibm.com>
To: "Robert Griswold" <rgriswold@Crossroads.com>
Cc: <ips@ece.cmu.edu>
Sent: Friday, August 03, 2001 5:26 PM
Subject: Re: Review of the 07 draft

> Well, in fact, the draft is supposed to say that MODE_SELECT for the
> transport-specific mode page will NOT be done via SCSI, only via Text
> commands.  I read that as saying that from the SCSI layer, all fields
in
> these pages are "unchangeable" (even though they can change in the
iSCSI
> layer).  Of course, the draft doesn't say whether MODE PARAMETERS HAVE
> CHANGED unit attentions get thrown up at the SCSI layer when this
happens
> at the iSCSI layer.... You later have a clarifying question (Section
3) on
> this as well.
>
> Regards,
> Jim Hafner
>
>
>
>