Re: [iSCSI]: Key negotiation procedure proposal

[Luben Tuikov <luben@splentec.com>]

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!

State: This can be accomplished by a linked list with status
in each element.
 
> 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.
 
> > 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.
 
> 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!

Please also note that the proposed negotiation procedure
takes care of MULTIPLE key=value pairs being sent in each PDU,
and their responses.

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.

-- 
Luben
P.S. Those rules are the minimum consistent set of
a larger set of rules which allow complete interoperability.
Any mathematicians here? Bill, I suspect?