Subject: RE: iSCSI: Negotiation clarifications still needed

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Tue, 28 May 2002 16:43:32 -0600

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:[email-masked]]
Sent: Tuesday, May 28, 2002 2:20 PM
To: THALER,PAT (A-Roseville,ex1); Julian Satran; Mallikarjun C.
Cc: [email-masked]; Martins Krikis
Subject: RE: iSCSI: Negotiation clarifications still needed

--- "THALER,PAT (A-Roseville,ex1)"
<[email-masked]> 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

---

From: Martins Krikis <[email-masked]>
Date: Tue, 28 May 2002 16:26:47 -0700 (PDT)

> with the approach the group has already chosen - the

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.

> sends all its keys and then the responder sends all

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.

> reflector discussions is that is the way people want

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

> with the kind of negotiation process the group

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

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

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

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 28 May 2002 17:59:52 -0700 (PDT)

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

> with the approach the group has already chosen - the smallest changes

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.

> sends all its keys and then the responder sends all its keys doesn't

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

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

> 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