SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: [iSCSI]: Key negotiation procedure proposal



    On Thu, 23 May 2002, Luben Tuikov wrote:
    
    > Bill Studenmund wrote:
    > >
    > > My only concern with this is that we now have to keep more state around;
    > > we have to remember to send the key next negotiation, and the other side
    > > has to know to send a blank message as part of that next negotiation.
    >
    > Yes, but as we already know negotiations are stateful!
    > I.e. you have to remember what you sent!
    
    True, but you are proposing negotiation add an extra state, "partly sent."
    i.e. we've sent a Reject, and need to send a value next time.
    
    Before all we needed to remember is what we want to negotiate, what we
    have negotiated, and what we'll accept for new negotiations. Now we have
    to remember that we are in the middle of a reject/reoffer.
    
    > State: This can be accomplished by a linked list with status
    > in each element.
    
    It can, but we don't have to, so why should we?
    
    > > Instead, why not just send it later in the first message?
    >
    > Because the Originator needs to know that its offer was
    > Rejected. If it is a simple implementation it will close
    > the connection with TCP FIN, else it will stick around
    > for the rest of the negotiation, i.e. send more (other)
    > key=value pairs or sent empty PDU as per the protocol.
    
    That statement doesn't make sense.
    
    The originator WILL know its offer was rejected; there's a "key=Reject" in
    the login payload. I don't understand how the fact that's a reject isn't
    clear to the originator.
    
    I'm suggesting that we not wait for a future packet pair to send the value
    we would be happy with. As you so strongly pointed out, we can have
    multiple key=value tuples, why not repeat this key twice, once to indicate
    reject, and once to indicate our value. Thus the originator gets all the
    info it needs very quickly, we save a packet pair, and we don't need to
    add more state.
    
    i.e. addlen = snprintf(buffer, "%s=Reject\000%s=%s", key, key, newval);
    to generate the text response for this negotiation step.
    
    
    > > > Let O: denote Originator and R: the Responder.
    > > >
    > > > Example 1:
    > > > ----------
    > > > O: v = x  -->
    > > >          <--   R: v = Reject
    > > >
    > > > O: ""     -->
    > > >          <--   R: v = y
    > >
    > > We 1) make the negotiations happen faster, and 2) can keep less state
    > > around (O doesn't need to send "", and R doesn't need to remmeber to send
    > > v = y next time).
    >
    > The Originator _has_ to send something as are the rules
    > of the protocol. This is very well described in the protocol.
    > It may send OTHER variables for negotiation or just and empty
    > PDU.
    >
    > As I mentioned the Originator has to know its offer failed
    > so that it can then decide if it wants to close the connection
    > with TCP FIN, or stick around (simple implementation vs. complete one)
    > and send more (other) key=value pairs for negotiation.
    
    You snipped my diagram, so I can't explain how we took exactly different
    spins on it.
    
    As above, I wasn't talking about two packets from the responder, but two
    key/value pairs that share the same key in the same text payload of one
    login response.
    
    > > All the implementations I've seen break the login text up one key/value
    > > pair at a time, so seeing the same key twice won't cause a problem AFAICT.
    >
    > But this is not the rule, it is the exception.
    >
    > I negotiate all keys I can send in one packet!
    
    So do I.
    
    > Please also note that the proposed negotiation procedure
    > takes care of MULTIPLE key=value pairs being sent in each PDU,
    > and their responses.
    
    And my suggestion was to make use of that ability to make it so we don't
    have the extra pair of packets you described. :-)
    
    > This is important as not all implementations will
    > send one variable at a time! I.e. to conserve
    > time and bandwidth!
    >
    > Those negotiation procedure rules allow for the connection
    > to survive even when all of the Originator keys have been Rejected,
    > but the Responder sent back values acceptable by the Originator.
    > I.e. complete ineroperability.
    
    And I think it's a good idea. It also clarifies the use of Reject.
    
    With the tweak I suggested above, it just happens faster. :-)
    
    Take care,
    
    Bill
    
    


Home

Last updated: Thu May 23 15:18:32 2002
10260 messages in chronological order