Re: [iSCSI]: Key negotiation procedure proposal

[Bill Studenmund <wrstuden@wasabisystems.com>]

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