RE: iSCSI: keys/parameter dependence

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Thu, 6 Jun 2002, THALER,PAT (A-Roseville,ex1) wrote:

> Julian,
>
> Then we shouldn't have added the C bit at all. One doesn't need it to
> indicate that a key-value isn't complete and one certainly doesn't
> need it for security negotiation where there is already a fairly lock
> step process for the certificate exchange.
>
> The arguments people used for adding it were that they wanted to be
> able to batch offers larger than a PDU without worrying about length.
> I agree that isn't necessary today for any of the standard keys.

Kinda. The spec says that you can have keys & values span a PDU.  My main
concern was I took the negotiation code I was writing down the path that
split keys would lead to, and I found an UGLY mess. So I would either have
to code up a mess, or I would have to have a not-strictly-conforming
implementation. The whole thread on it was an effort to avoid that mess
and follow the spec.

> During login one can send all the standard keys in a single 8k PDU.
> During FFP, the only standard negotiated key exchanged is
> MaxRcvPDUDataSize. One could respond to a SendTargets with keys spread
> over multiple PDUs without an issue.

> The current places where C helps are:
> Implementation doesn't support 8k transmit PDU size - the negotiation
> default of 8 k is for the size PDU one supports receiving. An
> implementation might chose to only send a much shorter PDU and then
> its keys would not al fit in a single PDU. I find it difficult to
> imagine someone designing an implementation that creates a long batch
> of keys and then sends it in multiple short PDUs when it could send it
> in one PDU, so this doesn't seem like a very good reason to have the C
> bit.

I agree this isn't a strong reason.

> Anticipation of many more or longer standard keys in the future so
> that they don't all fit in 8k.
>
> Anticipation of more FFP negotiations so that FFP offers don't all fit
> in a single PDU when PDU size might be as small as 512.
>
> Support for vendor specific extension keys that are more then 8 k in
> login or more than MaxRcvPDUDataSize in FFP.

The latter ones are good reasons. But the main reason I saw for the C bit
is that the way the spec was written, to strictly comply with it would
lead to a real mess. It certainly could be done, but where I saw things
going was (as the thread indicated) not where the majority of the WG had
seen them going. For instance Julian had a sender making a buffer and
chopping it into PDUs in mind, which wasn't simple with the spec as it
was.

Yes, there are other ways out of the mess, but the C bit is one that
required little change to current negotiations. All you have to do is
stick some buffer control code in the head of the login PDU analysis code
(I posted pseudocode based off of what I am using), and your current code
works as-is.

Take care,

Bill