Re: [iSCSI]: Key negotiation procedure proposal

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Thu, 23 May 2002, Martins Krikis wrote:

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

We will need to define it as an error.

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

It's not written anywhere. All I can say is that: 1) the sample for text
negotiation (9.10.3) shows empty PDUs, and 2) if we don't do it,
negotiation becomes a REAL mess. :-)

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

A flag would be fine too.

I think we definitely need a better description of how it's suppsoed to
work..

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

I think we should make it an error. :-)

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

If no T bit, NSG == reserved = 0.

The last one of a set of PDUs should probably reflect the desired state.

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

Indeed. :-)

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

Ahhh.. Ok. :-)

Take care,

Bill