RE: iSCSI: keys/parameter dependence

["Julian Satran" <Julian_Satran@il.ibm.com>]

Robert,

First I would like to correct an error that appeared (not intentionally I assume) in your note - a PDU  C bit set to 0 terminates a sequence even if it stands alone.

As for the batching of keys neither the new text nor the old said anything for or against it.

The new text says only that the receiver should not process text untill it does not receive the complete sequence (whether it is batched or not that is an implementation issue).

The only point that we added and we made it for simplicity is stating that the while a sequence is incomplete the answers should be empty.

We could as well reverse to the previous - "do not originate new keys" without breaking logic but we found this new rule simpler.

As for dependencies I agree that the argument about not having defined before is lightweight  but then the statement about dependencies was too general to be of any use and we replaced it with a key specific statement.

Overall the C bit change is lightweight and for reasons you have mentioned is not bound to break code.

I simplifies parsing as those boundary cases that where the old scheme was hard.

I would be grateful if you could point out those dependencies that are mandatory to check (some dependencies are benign and not worth checking - e..g., R2T is mandated and FirstBurstSize is also negotiated) so that we can specifically state them (as we do for security).

Regards,
Julo

"Robert D. Russell" <rdr@io.iol.unh.edu> 06/02/2002 12:23 PM Please respond to "Robert D. Russell"

To:        Julian Satran/Haifa/IBM@IBMIL         cc:                 Subject:        RE: iSCSI: keys/parameter dependence

Julian:

The following paragraph from an e-mail from Martins Krikis
made me realize that the definition of the new C bit
is not correct, because it goes much further
than is necessary to solve the "split key" problem,
and as a result, it opens up a whole new set of problems,
complicates what was previously a simple situation, and
breaks a lot of already running and tested code.


> "(sent) after" isn't defined. It is unclear
> whether "in higher numbered bytes within the
> same PDU" qualifies as "after" or whether only
> "in a PDU sent at a later time" would. It's
> probably irrelevant, since due to the introduction
> of the C-bit, parameters can be accumulated and
> processed one "batch" at a time, without any
> specific order within the "batch" and they will
> quite likely not be processed PDU by PDU.
> Therefore, the text about them being sent in
> "the same command" is likely irrelevant, too,
> since many implementation simply won't check that.
>

I don't believe the intention of the recent discussion
that led to the introduction of the C bit was, in fact,
to allow "batching" or to throw out "ordering" of the
sending of keys.  However, the definition in Draft 12-95
sections 9.10.2  and 9.11.2 seems to now allow batching:
(I agree with John Huffered that Martins' comments about
"ordering" are not correct in any case.)

Section 9.10.2 C (Complete) Bit:
"When set to 1, indicates that the text (set of key=value pairs) in
this Text Request is not complete (it will be continued on a
subsequent Text Request); otherwise, it indicates that this
Text Request ends a set of key=value pairs."

(Section 9.11.2 is the same, but with Response substituted for Request.)

The problem I see with this definition of the C bit is that
the sending side can force the receiving NOT to process
a PDU containing key=value pairs, even if all those key=value
pairs are complete within the PDU.  Therefore, the receiver
is forced to save this PDU (and any number of following PDUs)
until the sender finally sends C = 0.  In the worst case, the
sender could send one key=value pair per PDU with the C bit set
to 0 and the receiver could not reply to any of these until it
got one with C bit set to 1.
As the e-mail from Martins indicates, some people are already
taking this to mean that parameter negotiations will "normally"
be batched.  Up until the introduction of the C bit, PDUs and keys
in them were always processed as received, and most code already does
this, since it is the most logical and efficient way to do it.
We should still encourage this as the "normal" way of negotiating.

I believe the problem we were trying to solve by introducing
the C bit was the one where a key was split over a PDU boundary
-- we were not trying to redesign the negotiation mechanism,
which was discussed on the mailing list long ago and has been
working in a lot of running code for the past two plugfests.

Could we therefore please change the definition of the C bit in
section 9.10.2 to read:
"When set to 1, indicates that the text in this Text Request
contains a single key=value pair, and that pair is incomplete
within this PDU."

(Section 9.11.2 should have the same change, but with Response
instead of Request)

I believe this corresponds more closely with the description
in section 4.2 Text Mode Negotiation, where the C bit (flag) is
clearly tied to the idea of split keys only:
"Key=value" pairs may span PDU boundaries.  An initiator or target
having sent partial key=value text within a PDU indicates that more
text follows by setting the C flag bit in the Text Request or
Text Response to 1."

Perhaps an additional sentence could also be added to this:
"The following PDUs should only contain text that completes
the partial key=value text until after a PDU with C set to 1
has been sent, at which time new key=value pairs can be sent
in the next PDU."

I'm not happy about seeing such a major change (C flag bit)
introduced so late in the process to solve an "almost" non-existant
problem (split keys).  It is "almost" non-existand because of
the following considerations (some of which were already
mentioned on the list and are just summarized here):
During the login process, the PDU size is 8192 bytes.
Therefore, except for the long keys during negotiation
that follows a chosen AuthMethod, there is never a need to split
keys across pdu boundaries during login --
even if you negotiate every possible login key
(except those special keys that occur in security protocols)
to its maximum length, you do not reach the total of 8192 bytes.
It is not even close!  Therefore, there is no need for any
implication that the C bit should appear during this process.
When those long security keys are needed, the negotiation process is
in a 1 key over, 1 key back exchange mode, so there is no "batching"
possible and the split key should in fact be the only key in the pdu.
Finally, during text exchanges, there only 6 keys that can be
legally sent (plus the X-extension key): SendTargets, TargetName,
TargetAlias, TargetAddress, InitiatorAlias, and MaxRecvPDULength.
None of these can legally have a value greater than 255 bytes,
which is well less than the minimum PDU size (512 bytes).
So there is no need to split keys over boundaries during text
negotiation, except perhaps for the X-extension keys.
My proposed definition of the C bit as applying only to split keys
therefore only applies to X-extension keys during text negotiation.
Since we have had no experience with X- keys, and cannot forsee their
use, anything we introduce only for them should be the minimum possible.

In summary, I would like to see as little disruption as possible
to the key negotiation scheme which has been stable for a long time,
especially since anything we introduce will be needed only in very
limited circumstances.  I believe my modification to the definition of
the C flag accomplishes that, without introducing any new, false
perceptions about "batching" and "ordering".

Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774