Subject: RE: iSCSI: Negotiation clarifications still needed

From: [email-masked]
Date: Tue, 28 May 2002 12:22:42 -0600

Bill,

I don't think that we need to prevent that case. If the initiatior chooses to 
not initiate a key-value pair when it has received a partial key-value pair
(or a partial key) and it doesn't have any keys to respond to, then it can
continue the negotiation by sending a PDU with the tail of the partial key-value
that it sent. Even if it doesn't have a partial key-value to send it can send
a PDU with a blank text field. Either way, the target can then send another 
PDU finishing its partial key-value. 

This isn't broken so we don't have to change it to make iSCSI robust.

Pat

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Friday, May 24, 2002 5:42 PM
To: [email-masked]

<snip>
But there's another case too:

Say the response from the target ALSO doesn't fit in one PDU. Yes, the
target's not going to respond to the key=value pair that wasn't complete,
but say its response to everything else was bigger than the initiator's
representation of said keys. For this case to happen, the target's
response has to grow more than the first bit of the PDU-spanning key/value
pair.

The case where I can see this happening is we had a mix of boolean-or keys
and other keys. And for these bolean-or keys, the initiator wanted NO but
the target wanted YES. So the target's response is bounded to be bigger.
Or maybe there were some Rejects in there when the offer was less than 7
bytes long.

So now we have TWO PDU-spanning key sets. And the target didn't originate
anything. :-)

Yes, this is a rare case. But it can happen. And, for iSCSI to be robust,
we need to prevent it.

---

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

> This isn't broken so we don't have to change it to make iSCSI robust.

You are correct. Negotiations will continue, and login will converge.

The concern is the target has to be more complex. While it can be done,
the more complex things are, the harder it is to make them robust.

This portion of the thread has been more, does everyone understand the
complexity (amount of state) lurking in the current spec?

If everyone does, then ok. Pat, I think you probably do. But some of the
questions I've seen don't fill me with confidence that everyone does.
Those comments are especially concerning given the, "let's get through
last call" pressures some folks are applying. While getting through
last-call is GOOD and IMPORTANT, it's also scarry to push into last-call a
protocol with not-well-understood parts (i.e. hidden login complexity) in
things folks think are well-understood.

If the WG wants it this way, so be it. I look forward to seeing text in
the next draft that better explains how PDU-spanning negotiations will
work. Especially helpful would be sample algorythms, since I forsee this
area is one that is easy to get wrong, and the current text is (obviously
:-) not getting new readers onto the same page as the WG. :-)

Take care,

Bill