SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI - negotiating against defaults/renegotiation the same key



    Dear colleagues,
    
    I think that my previous proposal about negotiating against defaults is
    flawed.
    I was based on the simple-minded assumption that after the initiator has
    said all he had to say (as evidenced by the T=1) the target may assume that
    the values the target puts forward are against default. I even prepared a
    text in
    5.3 that read:
    
       When the initiator issues a login request with the T bit set to 1 the
       target MUST assume that this request includes also an "imaginary
       content".  The "imaginary content" consists of key=value pairs including
       all the operational keys that have a default value and where not sent
       yet by the initiator during the operational parameter negotiation. The
       values in the "imaginary content" are the key default values.  This
       enables an initiator to avoid sending all the defaults while the target
       may negotiate as if they where sent.
    
     But that was wrong. Here is a simple example:
    
     A simple initiator may issue a first login entering the operational
     negotiation and having T=1 and nothing beyond the 2 names:
    
     I->T Iname... Tname
    
     This means only that he does not care about things like MaxBurst and is
     content with defaults.
    
     The target (in my proposal prompted by Santosh's request) can't do
     anything but lower the value while under our simple rule of self contained
     negotiations he could ask for a burst increase and the negotiation could
     have proceeded.
    
     For this (and a several other scenarios that  you can easily build) I
     suggest we stick with our "old" rule that a negotiation must be completely
     "self contained".
    
     Now about the other two subjects:
    
     1-Multiple negotiations on one key - we may choose one of the following
     ways out:
    
       a)say that both initiator and target MAY drop the login if that happens
       (and close the connection)
       b)say that both initiator and target MUST drop the login if that happens
       (and close the connection)
       c)say that this is legitimate (a negotiated parameter change due to a
       later change not know when the negotiation started)
       d)say that the whole sequence of Login request/responses is a a "single
       single virtual exchange" and the last value is the single one that
       counts in every direction - this one is somewhat related to the length
       question but does not allow branching decisions
    
     I am would favor a)
    
     2. Text block length - we gave away (for a while) on our 4k text messages.
     That makes negotiation difficult and might somehow help some of the
     framing schemes:
    
     I think we may want to do one of the following:
    
       a) mandate that the default 8k is valid during login and change only at
       end of login
       b) get back to a separate length for text and fix it at 4 or 8k (not
       ideal for framing)
    
     Option a may solve the login issue but leaves us with an ugly text
     negotiation.
    
     Option b will require the framing folks to come up with a solution (works
     with markers though).
    
     I am in favor of b (a different and predefined length for text buffers)
     and return to the "complete" negotiation buffers
     that raise far less logical problems that the concatenation scheme we are
     (temporarily in).
    
     Julo
    
    
    


Home

Last updated: Tue Oct 16 22:17:34 2001
7263 messages in chronological order