Subject: RE: iscsi : iscsi parameter default values

From: "Julian Satran" <[email-masked]>
Date: Thu, 27 Sep 2001 19:50:21 +0300

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'" <[email-masked]>,          
                    <EQuicksall@med        <[email-masked]>                                      
                    iaone.net>            cc:                                                     
                    Sent by:              Subject:     RE: iscsi : iscsi parameter default values 
                    [email-masked]                                                               
                    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:[email-masked]]
Sent: Wednesday, September 26, 2001 10:29 PM
To: [email-masked]
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

---

From: "Somesh Gupta" <[email-masked]>
Date: Fri, 28 Sep 2001 14:44:08 -0700

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)

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Julian Satran
> Sent: Thursday, September 27, 2001 9:50 AM
> To: [email-masked]
> Subject: RE: iscsi : iscsi parameter default values
> 
> 
>