RE: iSCSI: Negotiation clarifications still needed

[Martins Krikis <mkrikis@yahoo.com>]

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

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

Then why involve declarations in the issue?

And if we classified the brokenness as "arbitrary
PDU boundaries imposed on unpredictable amount
of data", wouldn't the smallest change be to say
"wait, don't send anything until you got all that
data"?

Also, some people had already understood the
existing draft pretty much the way I proposed,
i.e., that empty PDUs are required in response
to PDUs ending in split pairs. I just realized
that it is even cleaner to have a data-end flag.

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

Regardless of the phase at any point one could
have a set of keys that it would like to send.
With my scheme they all can be sent w/o worrying
about which ones will fit in the first PDU and
which won't. I don't mean sending every single
key defined in the spec. I just mean sending 
all keys that would be nice to send at this point.
Then I'll see what I've received and perhaps
send some more. All w/o worrying about PDU boundaries.

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

Same as above, i.e.,
I never did mean sending _absolutely_ _all_ keys.

> I think the method you propose would work, but it
> isn't consistant
> with the kind of negotiation process the group
> appears to want.

I may be losing out on support numbers but I do
have support. Plus, Julian himself said
"chopping in PDUs"... And the process I'm proposing
is definitely not an "I send, you send, it's over".
It can go on in as many rounds as necessary.
It is just that I'm not inventing rules to support
"limited interruption of the speaker", I'm simply
saying "one MAY NOT interrupt the speaker".
I'm also not saying "the speaker should say all it
can now, 'cause it won't have another chance".

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

But that's what I proposed---empty PDUs until
the data-end flag is set (or, alternatively,
more-data flag cleared). So there is such an 
indication in my scheme. Even without the flag 
the encapsulator can make sure that every PDU 
ends in a split pair, except last.

And I don't think that it is beneficial to allow 
the other side the flexibility to make an offer
in the middle of my own unfinished-offer...

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