RE: iscsi : iscsi parameter default values

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

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