Re: [iSCSI]: Key negotiation procedure proposal

[Martins Krikis <mkrikis@yahoo.com>]

> > That's the problem---the "negotiation step".
> > Currently a step is basically PDU-wide. You cannot
> > force the other side to hold off answering before
> > you've sent all the data that you want processed
> > together. Since we need to know what physically
> > went out on the wire and what didn't (to be able
> > to process reception of same keys properly), we
> > cannot just leave ready-to-be-sent text sittin
> > in buffers. We cannot prepare a key=value unless
> > we're sure it will fit. That's true in general,
> > not just for this key=Reject\0Key=BetterValue\0
> > situation. I think we need a flag there to tell
> > the other side to hold off processing. No replies
> > necessary until the flag goes off.
> 
> But we do! It's not a flag, but we do have the
> capability.

The capability to send our pairs in multiple PDUs
yes, but we don't have the capability to stop
the other side from responding to the first ones
seen while we haven't sent all that we were planning
to send yet.

> It's not as clear as I think it should be, but my
> understanding (which has
> been confirmed/developed by EMails from others) is
> that if you get a login
> PDU whose last data byte (not padding, but byte in
> the data length) is not
> a NUL (0x00), you have more coming. You should then
> send an empty PDU to
> the other side, and then you'll get more data.

I haven't seen a requirement to send an empty PDU.
In fact, since I view all keys as independent, I'm
sending however much I can send in each an every
PDU, not waiting for the other side to finish up
and send a PDU ending in a NUL byte. I.e., I will
not send you blank PDUs as a favor, because the spec
hasn't required me to do so and I didn't think it
was needed. I thought I was saving time by sending
PDUs with my responses (to what can be responded to).
I now realized that I had a problem by leaving
stuff sitting in buffers but marking it as sent.
I can fix it, but I see that the protocol allowing
this is what's making it messy. So, if we were
required to use blank PDUs until the other side
sends us something ending in NUL, things were
actually great. Still, not as good as an explicit
flag, since data has to be looked at, not just
stored away, but decent. However, the requirement
for a blank PDU has escaped me if it exists.
Somebody please enlighten me.

> Also, it would be nice if it were stated that
> sending new key/value pairs
> in the "I'm ready for more" PDUs is a protocol
> error. Otherwise one side
> is feeding the other info before the other has had a
> chance to finish
> responding.

Yeah, so I'm afraid it is not a protocol error
currently. If it is, I'm happier already.
Then, of course, we could say that blank PDUs
aren't even necessary, the sending side can just
send all PDUs that it had to send.

> Oh, nits: 1) I'm not sure what meaning transit and
> NSG would have when the
> initiator is sending these "I'm ready for more"
> PDUs. 2) The target
> shouldn't set "transit" until its sending the last
> of an extended-PDU data
> transfer.

NSG=CSG and no T/F flag
set (until possibly the last of thos PDUs).

> 3) If you are sending data that will span multiple
> PDUs, you MUST not send
> a PDU that has a zero (0x00) in its last data byte.
> i.e. say you're
> sending 12 k, and build an 8k pdu. The very last
> byte of that 8k must not
> be zero, or else the other side won't realize
> there's more coming.

This I know and was observing diligently. But I
don't believe there is a requirement for the
other side to refrain from sending data and
to send just blank PDUs.

Looks like we need some clarity here.

> Devil's advocate question, if you don't understand
> key=?, would asking for
> the other side's values then constitute a
> negotiation failure? :-)

Asking would be legal, but the other side will
likely not see it that way. Anyway, I am NOT
seriously proposing this.

Martins Krikis, Intel Corp.

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



__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com