RE: iSCSI: Negotiation clarifications still needed

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Tue, 28 May 2002, THALER,PAT (A-Roseville,ex1) wrote:

> Martin,
>
> I want to make it clear that I am not advocating for any particular
> scheme. In my experience, negotiation phases of protocols are a
> frequent cause of the type of interoperability bug that causes total
> non-operation. My goal is for the negotiation to be described clearly
> enough that this doesn't happen.

I would like to say that I am very heartened by the above. While I do
advocate a particular way of doing negotiations, I will be happy if we
clarify the negotiation description w.r.t. PDU spanning.

> I am not trying to optimize bandwidth for negotiation but I am trying
> to propose ways to clarify the existing protocol that are consistant
> with the approach the group has already chosen - the smallest changes
> that fix what is broken.

Here I am at a disadvantage. The only source code I have access to at the
moment (other than mine :-) are the draft 8 implementations available on
the net (UNH, Intel, IBM, and cisco). These implementations bill
themselves as reference implementations. Obviously since they are draft 8
and we are draft 12+, they aren't complete.

All of these implementations seem happiest dealing with a complete buffer
of negotiation data. Sticking the two chunks of code I detailed in
pseudo-code, the were-sending-a-big-offer or the there's-more-to-get, was
an easy add in front of the current negotiation code, and immediately the
non-PDU-savy negotiation code could deal with PDU-spanning negotiation.

> The SecurityNegotiation phase requires going back and forth between
> initiator and responder so a general approach of the initiator
> sends all its keys and then the responder sends all its keys doesn't
> work.

True. And AFAICT the negotiations that will need BIG keys only have one in
flight, in a specific direction, at a time.

> Even in the operational parameter negotiation phase, it is possible
> that keys received from the target will alter some of the
> later keys offered so one may not want that phase to be
> initiator sends all the keys it wants to originate then the target
> sends all the keys it wants to originate. My understanding of earlier
> reflector discussions is that is the way people want the negotiation
> to operate.
>
> I think the method you propose would work, but it isn't consistant
> with the kind of negotiation process the group appears to want.

Oh, you don't have to send everything at once. :-) If you want to make
some offers, see what comes back, and choose from there, you can.

> Also see one response inserted below.
> > Because of the request-response nature of
> > negotiation plus the
> > flexibility of allowing either side to make an offer
> > plus the simplification
> > that a negotiation is at most one offer and one
> > response, the negotiation
> > has to be PDU boundary aware.
>
> With a requirement for empty PDUs it doesn't.
> The negotiation is completely PDU boundary agnostic.
>
> <PAT> A requirement for empty PDUs doesn't do this.
> It is a requirement that the target not originate
> any keys non-declaritive keys until the Initiator
> has somehow indicated it won't issue any more. In
> what I wrote above, I really meant "the flexibility
> of allowing either side to make an offer at any
> point during the negotiation." <PAT>

True. The requirement for empty PDUs is just one way of keeping one side
quiet while the other is making offers.

Take care,

Bill