Subject: RE: iSCSI: keys/parameter dependence

From: "Julian Satran" <[email-masked]>
Date: Mon, 3 Jun 2002 10:19:22 +0300

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" <[email-masked]>
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
[email-masked]
603-862-3774

---

From: "Robert D. Russell" <[email-masked]>
Date: Tue, 4 Jun 2002 04:13:40 -0400 (EDT)

Julian:

I have found the following dependencies between keys in draft 12-96,
and would ask other people on the mailing list to contribute others
they have found so we can all be aware of the complete set.

There seem to be very few dependencies, which I believe is a credit
to a clean, orthogonal design.

With a bit of work, we could probably get rid of all the dependencies
between the OFMarkInt (IFMarkInt) and OFMarker (IFMarker) keys, perhaps,
as suggested by Martins Krikis, by eliminating the OFMarker (IFMarker)
key and substituting a default (and response) value of 0 for the
OFMarkInt (IFMarkInt) to mean "no markers in that direction".

This would also eliminate the need for a "Reject" reply to an OFMarkInt
(IFMarkInt) offer.

"Meaningful" dependencies (i.e., those that cannot be ignored because
they effect operation):

1.  Between FirstBurstSize and MaxBurstSize
      Section 11.15: "FirstBurstSize MUST NOT exceed MaxBurstSize."

2.  Between OFMarkInt (IFMarkInt) and OFMarker (IFMarker)
      Section A.3.2: "When the interval (in an OFMarkInt (IFMarkInt)
      offer) is unacceptable the responder answers with "Reject".
      Reject is resetting the marker function (i.e., OFMarker
      (IFMarker)) in the specified direction (Output or Input) to No."

3.  Between SessionType and MaxConnections
      Section 11.22: "The discovery session implies MaxConnections = 1
      and overrides both the default and an explicit setting."

"Trivial" dependencies (i.e., those that only allow the option of
replying with "Irrelevant" instead of a normally selected value, and
therefore can be ignored).

1.  Between FirstBurstSize, InitialR2T, and ImmediateData
      The table in section 11.12 implies that the combination
      InitialR2T=Yes and ImmediateData=No allows the response
      FirstBurstSize=Irrelevant.

2.  Between OFMarker (IFMarker) and OFMarkInt (IFMarkInt).
      Sections A.3.1 and A.3.2 imply that OFMarker=No (IFMarker=No)
      allows the response OFMarkInt=Irrelevant (IFMarkInt=Irrelevant).

Bob Russell
InterOperability Lab

---

From: Martins Krikis <[email-masked]>
Date: Tue, 4 Jun 2002 11:43:43 -0700 (PDT)

> This would also eliminate the need for a "Reject"

I just started thinking that the introduction of 0
might require the responder to "respond with a 
value (the 0) out of range" if it does not want
markers, and thus thought that this plan wasn't
very good. However, if 0 is the default and if
Reject returns us to the previous (in this case,
default) value, then this would actually work fine,
and eliminate the boolean marker keys. We cannot
get by without allowing Reject as a response to
range not acceptable or not admissible, however.

If we keep the boolean marker keys, is there any
chance of NOT having a Reject for a marker interval
reset the corresponding boolean key to "no"? Then
we wouldn't have a dependency there. Can we have
the Reset mean "stick with the previous (i.e.,
default in this case) value"?

Thanks,

Martins Krikis, Intel Corp.

Disclaimer: my opinions, not necessarily Intel's.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com