|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: keys/parameter dependenceJulian: 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
Home Last updated: Mon Jun 03 17:18:37 2002 10471 messages in chronological order |