SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: not offering a key



    > My question is that if there is no such thing as an implicit value, then a
    > "default value" shouldn't exist, right?  Isn't a "default" implicit?
    
    There are two senses of implicit here that are subtly different:
    
    (1) A "default value" is what is used in the absence of negotiation.
    	It is implicit only in the sense of "what results from the
    	absence of negotiation".
    (2) An absence of negotiation is an absence of negotiation.  iSCSI
    	login does not treat the absence of a key as equivalent to sending
    	<key>=<default value>.  There are NO implicit negotiation steps.
    
    So a "default value" is to be used implicitly if it's not negotiated,
    but negotiation is *always* completely explicit to avoid possible confusion
    - if an implementation wants to negotiate something, it has to explicitly
    negotiate it, and the other side must explicitly respond.
    
    > What I am reading from this discussion is that all iSCSI initiators must
    > send _all_ keys.  How else is behavior going to be stable?
    
    "_all_ keys" --> "_all_ important keys".  If every key is important to
    an implementation, then it should negotiate every one of them.
    
    > It seems strange to complexify the algorithms on the grounds that
    > people will implement things incorrectly, but it looks like I'm
    > fighting a lost cause here so I'll stop now.
    
    IMHO, adding a notion of implicit offers of default values is more
    complex, because in the case where the Initiator does not negotiate a
    value and the Target replies with <key>=<value>, the following two
    additional things happen to the negotiation algorithm:
    - The Initiator must check whether <value> is the default value,
    	and does not continue negotiation of this key if that value
    	is acceptable.
    - The Target must check whether <value> is the default value
    	in order to know that the Initiator may not respond if it
    	accepts the value.
    Running the negotiation sequence until both sides have agreed
    avoids these complications, and avoids some silly negotiation
    protocol breakages ...
    
    Suppose someone overlooks the recent change in the default for
    MaxRecvPDULength from 8191 to 8192, and suppose a Target who thinks
    8192 is the default offers MaxRecvPDULength=8191 to an Initiator who
    thinks 8191 is the default.  With the two changes above, the negotiation
    fails because the Initiator doesn't send a response (it believes that
    the Target sent an explicit response to its implicit offer of 8191),
    but the Target won't receive the response required to complete the
    negotiation (it believes it sent 8191 in response to an implicit offer
    of 8192, and hence is waiting for an explicit reply), and hence no
    iSCSI session is established.  This negotiation failure is really
    silly, as both parties have all the information needed to complete
    the negotiation successfully (8191 is a likely result).
    
    Just to make matters worse, if we change defaults in the future and
    change the version number, we force an implementation that wants to
    support multiple versions to keep a table of what default applies to
    which version in order to comply with the two additional bullets above.
    In contrast, if there are no implicit offers, an implementation has the
    choice of always choosing to negotiate the keys whose default values
    differ between versions, which looks like a simpler approach to me.
    
    The upshot is that default values are supposed to be used in the absence
    of negotiation, but having them play no special role in negotiation
    results in a more robust negotiation protocol and potentially simpler
    implementations.
    
    Picking up Robert Russell's question on this issue:
    
    > It seems to me that your interpretation is adding something new that
    > is not in the standard and was never intended to be in the standard.
    > That is that the value of keys that were not negotiated is "unknown"
    > or uncertain.  On the contrary, the standard is quit explicit that
    > all keys have default values, and if a key is not negotiated then it
    > retains its default value on both sides of the connection, initiator
    > and target.  If this were not the case, then we would be in the
    > situation of essentially requiring the negotiation of every key,
    > just to confirm the defaults, and this is clearly contrary to
    > the whole idea of the negotiation process.
    > 
    > Am I misunderstanding what you are saying?
    
    Yes, see above.  The Initiator who thinks the default is still 8191 has
    a bug, but causing the whole negotiation to fail for that sort of bug
    appears to be going seriously overboard.  Negotiation is optional, but
    once negotiation of a key is commenced, it must be concluded explicitly.
    
    Thanks,
    --David
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
    black_david@emc.com         Cell: +1 (978) 394-7754
    ---------------------------------------------------
    


Home

Last updated: Fri Feb 01 11:18:02 2002
8590 messages in chronological order