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,
    Only one correction below.
    
    .
    .
    .
    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
    
    
    "Eddy Quicksall" <Eddy_Quicksall@iVivity.com> on 10/02/2001 09:08:17 AM
    
    To:   "'Santosh Rao'" <santoshr@cup.hp.com>, John Hufferd/San
          Jose/IBM@IBMUS
    cc:   <ips@ece.cmu.edu>
    Subject:  RE: iscsi : iscsi parameter default values
    
    
    
    Would all cases look like these? (If I made a mistake, please correct it).
    
    Note that I am attempting to use the rule specified as:
    
     The negotiation MAY
     proceed only up to the point where both parties can unequivocally
     compute the result; continuing beyond this point is OPTIONAL.
    
    And my interpretation of the rule is that when a responder gets a binary
    value, it can compare that against the default and can therefore compute
    the
    result and therefore does not need to respond if the result is what he
    wants.
    
    Am I correct in my interpretation?
    
    Eddy
    
    Default ImmediateData="yes"
    ===========================
    Initiator wants immediate data & target supports it.
    ---------------------------------------------------
    
    I -> T : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    T -> I : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    yes * yes = yes
    
    Initiator does not want immediate data & target supports it.
    -----------------------------------------------------------
    
    I -> T : ImmediateData="no".
             (CSG=Operational, NSG=FFP). T=1
    
    T -> I : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    no * yes = no
    
    Initiator wants immediate data & target does not support it.
    -----------------------------------------------------------
    
    I -> T : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    T -> I : ImmediateData="no".
             (CSG=Operational, NSG=FFP). T=1
    
    yes * no = no
    
    Initiator does not want immediate data & does not target support it.
    -------------------------------------------------------------------
    
    I -> T : ImmediateData="no".
             (CSG=Operational, NSG=FFP). T=1
    
    T -> I : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    no * yes = no
    
    Default ImmediateData="no"
    ==========================
    Initiator wants immediate data & target supports it.
    -----------------------------------------------------------
    
    I -> T : ImmediateData="yes"
             (CSG=Operational, NSG=FFP). T=1
    
    T -> I : (no key sent).
             (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)
    
    yes * no = no
    
    [Huff] yes * no (but OK) = Yes
    [/Huff]
    
    Initiator does not want immediate data & target supports it.
    --------------------------------------------------------------
    
    I -> T : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    T -> I : (no key sent)
             (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)
    
    no * no = no
    
    Initiator wants immediate data & target does not support it.
    -----------------------------------------------------------
    
    I -> T : ImmediateData="yes".
             (CSG=Operational, NSG=FFP). T=1
    
    T -> I : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    yes * no = no
    
    Initiator does not want immediate data & does not target support it.
    -------------------------------------------------------------------
    
    I -> T : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    T -> I : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    no * no = no
    
    Eddy
    
    -----Original Message-----
    From: Santosh Rao [mailto:santoshr@cup.hp.com]
    Sent: Monday, October 01, 2001 7:16 PM
    To: John Hufferd
    Cc: ips@ece.cmu.edu
    Subject: Re: iscsi : iscsi parameter default values
    
    
    
    John Hufferd wrote:
    >
    > I think your logic reverses if the support wanted is yes and the
    target is
    > supporting yes.
    
    How so ?
    
    Here are the scenarios when initiator wants to use immediate data and
    target supports it, first with default ImmediateData set to "yes" and
    then, with default Immediatedata set to "no". In both cases, a single
    login handshake occurs. The only difference being that when
    ImmediateData defaults to "yes", the key need not be sent in either
    direction, whereas when it defaults to no, the ImmediateData key travels
    in both directions in the login payload.
    
    (FFP = FullFeaturePhase).
    
    Default ImmediateData="yes"
    ---------------------------
    Initator wants immediate data & targets supports it.
    ----------------------------------------------------
    
    I -> T : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    T -> I : (no key sent).
             (CSG=Operational, NSG=FFP). T=1
    
    
    Default ImmediateData="no"
    --------------------------
    Initiator wants immediate data and target supports it.
    -----------------------------------------------------------
    
    I -> T : ImmediateData="yes"
             (CSG=Operational, NSG=FFP). T=1
    
    T -> I : Immediatedata="yes"
             (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)
    
    Same number of handshakes in both cases. The only difference is that the
    key is not sent in the first case, and key is explicitly exchanged in
    the 2nd case.
    
    
    > If they say No they clearly do not care about extra handshakes sense
    R2T is
    > all they have and it requires extra handshakes.
    
    Hmm.... The way I see it, an initiator that does not use ImmediateData
    is a simple initiator and is more interested in seeing a simpler login
    (completed in a single login req/rsp) than one that does support
    ImmediateData.
    
    Those implementations that can do the extra work of supporting
    ImmediateData can well do the extra work of negotiating for its use.
    
    Regards,
    Santosh
    
    
    
    
    
    


Home

Last updated: Tue Oct 02 22:17:19 2001
6974 messages in chronological order