SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iscsi : iscsi parameter default values



    
    Eddy,
    
    The text (cleaned) says:
    
       For numerical negotiations, the responding party MUST respond with the
       required key.
    
       Binary negotiations (for keys taking the values yes or no) are a
       restricted form of numerical negotiations and the result is a key
       dependent Boolean function of the two inputs. The negotiation MUST
       proceed ONLY up to the point where both parties can unequivocally
       compute the result based on new values; continuing beyond this point is
       OPTIONAL.
    
    
       Comments?
       Julo
    
    
                                                                                                      
                        "Eddy                                                                         
                        Quicksall"            To:     John Hufferd/San Jose/IBM@IBMUS, Julian         
                        <EQuicksall@med        Satran/Haifa/IBM@IBMIL                                 
                        iaone.net>            cc:     <ips@ece.cmu.edu>                               
                                              Subject:     RE: iscsi : iscsi parameter default values 
                        28-09-01 16:44                                                                
                        Please respond                                                                
                        to "Eddy                                                                      
                        Quicksall"                                                                    
                                                                                                      
                                                                                                      
    
    
    
    I don't have any problem anymore with the ImmediateData default because the
    spec has been changed to say:
    
     For numerical (and binary) negotiations, the responding party MUST
     respond with the required key.
    
    But, there is still the issue I have pointed out below, that is ...
    
    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 (i.e., either the SessionType is not required or the
    default has no meaning).
    
    I suggest that we take the Default out of SessionType or change section 5
    to
    say:
    
     The initial Login request MUST include the InitiatorName key=value pair.
     If the SessionType is not specified, the default type will be Normal.
    
    Eddy
    
    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Friday, September 28, 2001 4:33 AM
    To: Julian Satran
    Cc: ips@ece.cmu.edu
    Subject: RE: iscsi : iscsi parameter default values
    
    
    
    I also agree with this.  It should be yes.
    
    .
    .
    .
    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: hufferd@us.ibm.com
    
    
    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 09/27/2001 09:50:21 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    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
    
    
    
    
    
    
    
    
    
    
    
    
    
    


Home

Last updated: Sat Sep 29 18:17:20 2001
6875 messages in chronological order