RE: iSCSI: keys/parameter dependence

[pat_thaler@agilent.com]

Robert,

The text:
"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 Requests); otherwise, it indicates that this Text Request
ends a set of key=value pairs."
says anything that implies the keys are batch processed. The draft 
is explicit that one must reply with empty PDUs while the C bit is
set, but it doesn't say anything about processing. One could be
building a buffer of responses to those keys while receiving them.

If one was only going to allow long security keys to be split, then 
one wouldn't need the C bit at all. One can tell that the complete 
key hasn't arrived yet. If we made the changes you suggest, we wouldn't
need the C bit at all.

The C bit was introduced because people wanted to build a buffer of 
keys to send without having to check whether they would all fit into 
one PDU. Concensus of those who responded was very much in favor of
this direction. (The discussion period was short though intense. 
Perhaps more time should be allowed for people to see the discussion
and respond before changing the draft.)

Regards,
Pat


-----Original Message-----
From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
Sent: Sunday, June 02, 2002 2:28 AM
To: ips@ece.cmu.edu
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