RE: iscsi : iscsi parameter default values

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

Julian,

You still did not answer my question. If you do have any
information (specific product related), I would really
appreciate that.

Thanks,
Somesh

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Friday, September 28, 2001 10:52 PM
> To: ips@ece.cmu.edu
> Subject: RE: iscsi : iscsi parameter default values
>
>
>
> Somesh,
>
> There is a lot of confusion between immediate and non-solicited
> in general.
> There is no need to change the transport at all.
> See my previous answer to Robert Snively.
>
> Julo
>
>
>
>
>                     "Somesh Gupta"
>
>                     <somesh_gupta@silverbacksy       To:
> "Julian Satran" <Julian_Satran@il.ibm.com>,
>                     stems.com>
> <ips@ece.cmu.edu>
>                                                      cc:
>
>                     28-09-01 23:44                   Subject:
> RE: iscsi : iscsi parameter default values
>                     Please respond to
>
>                     somesh_gupta
>
>
>
>
>
>
>
>
> Is there any target today that will handle ImmediateData
> without a significant change to the transport API? Also
> is there any target that does use out of order R2Ts?
> (Just curious)
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Julian Satran
> > Sent: Thursday, September 27, 2001 9:50 AM
> > To: ips@ece.cmu.edu
> > Subject: RE: iscsi : iscsi parameter default values
> >
> >
> >
> > The one that I have trouble living with is ImmediateData. This is
> > important
> > for low-end desktops and hardly matters for large boxes.
> > As such I would suggest it stays as yes.
> >
> > Julo
> >
> >
> >
> >
> >                     "Eddy
> >
> >                     Quicksall"            To:     "'Santosh Rao'"
> > <santoshr@cup.hp.com>,
> >                     <EQuicksall@med        <ips@ece.cmu.edu>
> >
> >                     iaone.net>            cc:
> >
> >                     Sent by:              Subject:     RE: iscsi
> > : iscsi parameter default values
> >                     owner-ips@ece.c
> >
> >                     mu.edu
> >
> >
> >
> >
> >
> >                     27-09-01 17:22
> >
> >                     Please respond
> >
> >                     to "Eddy
> >
> >                     Quicksall"
> >
> >
> >
> >
> >
> >
> >
> >
> > I like your defaults below.
> >
> > But, section 5 says:
> >
> >  The initial Login request MUST include the InitiatorName and
> >  SessionType key=value pairs.
> >
> > Since SessionType is REQUIRED, naming a default would imply a
> > possible typo
> > in the spec.
> >
> > Eddy
> >
> > -----Original Message-----
> > From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > Sent: Wednesday, September 26, 2001 10:29 PM
> > To: ips@ece.cmu.edu
> > Subject: iscsi : iscsi parameter default values
> >
> >
> > All,
> >
> > With the issue of mode page vs. login keys having [almost] drawn to a
> > close, I would like to
> > raise the below issues again, on the subject of default values for login
> > keys and other iscsi
> > parameters :
> >
> >
> >    * In keeping with traditional use of scsi mode pages, iscsi should
> > not specify any default
> >      settings for any mode pages that continue to exist for iscsi.
> > "Default values" for mode
> >      pages are target specific and should not be bound to the protocol
> > draft.
> >
> >    * MORE IMPORTANTLY, I read the default for EMDP as being set to 1
> > :-<  This implies that
> >      targets must be always prepared to deal with out of order data and
> > initiators must be
> >      prepared to deal with out of order data, unless the initiator
> > performs a mode select to
> >      disable it. [which defeats all the previous advantages gained thru
> > mandating use of login
> >      keys for other negotiations.]. A default, if it were to exist,
> > should be 0. (in-order, by
> >      default).
> >
> >    * Conservative specification of defaults for login keys along the
> > following lines :
> >                             MaxConnections = 1
> >                             FMarker = "no"
> >                             InitialR2T = "yes"
> >                             BidiInitialR2T = "yes"
> >                             ImmediateData = "no"
> >                             DataPDULength = 16
> >                             MaxOutstandingR2T = 1
> >                             DataPDUInOrder = "yes"
> >                             ErrorRecoveryLevel = 0
> >                             SessionType = "normal"
> >
> >    * Should the iscsi protocol require a "Lun Control Mode Page"? IOW,
> > is an EnableCRN bit
> >      required at the transport layer ? If the device server capability
> > is to be negotiated , I
> >      suggest this bit be moved to a SCSI ULP Mode Page such as the
> > "Control Mode Page", through a
> >      T10 change as a part of the SCSI changes being driven by iscsi.
> >
> > Comments ?
> >
> > Thanks,
> > Santosh
> >
> >
> > Santosh Rao wrote:
> >
> > > There are the separate issues of :
> > >
> > >    * iscsi's specification of defaults for its mode pages which is not
> > in line with mode page
> > >      usage. This impacts the target's ability to enforce values other
> > than the protocol
> > >      specified default, if the initiator were to not use mode
> > sense/select.
> > >
> > >    * default settings for login keys.
> > >
> > >    * Is there a need for the "LUN Control Mode Page" and whether
> > "Enable CRN" should be in a
> > >      transport specific mode page ?
> > >
> > > which need to be driven to closure as well.
> > >
> > > Regards,
> > > Santosh
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>