RE: iSCSI: Negotiation clarifications still needed

["THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>]

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 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.

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.

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.

Also see one response inserted below.

Pat

-----Original Message-----
From: Martins Krikis [mailto:mkrikis@yahoo.com]
Sent: Tuesday, May 28, 2002 2:20 PM
To: THALER,PAT (A-Roseville,ex1); Julian Satran; Mallikarjun C.
Cc: ips@ece.cmu.edu; Martins Krikis
Subject: RE: iSCSI: Negotiation clarifications still needed


--- "THALER,PAT (A-Roseville,ex1)"
<pat_thaler@agilent.com> wrote:

> The sender cannot do exactly what you describe. It
> cannot prepare a string of 
> key-value pairs then chop them into PDUs to send
> because the response to 
> the first PDUs may contain offers of keys that were
> not sent in the first PDU. 

This is where my scheme has an advantage. The
sender does not have to worry about how much fits
in each PDU. It knows that it will be getting
no response text until it is done all its sending.

Kind of like a speaker knowing that nobody will
interrupt it until it has finished the thought.

> 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> 

I know that your scheme works, Pat. It also more
efficiently uses the bandwitch and possibly converges
faster in the rare case when anything needs to be
split at all. However, my scheme is simpler and
allows simpler implementations without any harmful
effects on the general case when everything does fit.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not be
            those of my employer



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com