RE: iSCSI: keys/parameter dependence

["Robert D. Russell" <rdr@io.iol.unh.edu>]

Pat:

Replies to all your e-mails in this one response.

> 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.

You are, of course, correct -- the draft does not say anything about
processing, and I was mistaken to imply that it did.

This does, however, bring up another question.  When the C bit is 0,
the receiver of that PDU does not seem to be required to send replies
to the keys it has received up to that point -- it could send
another empty PDU, or more likely, it could send new offers of its
own.  It seems to me that there is nothing in the draft that says
when replies to keys should be sent, only that they MUST be sent.


> However, there ARE dependencies between operational
> parameters that cannot be ignored, such as the one Mike mentioned
> -- FirstBurstSize and MaxBurstSize are dependent because of the
> requirement in section 11.15: "FirstBurstSize MUST NOT exceed
> MaxBurstSize."  See my e-mail response to Mike for details
> on that dependence.  I am also sending a following e-mail
> that details 3 other dependencies.
>
> <PAT> This is an excellent example of why it is necessary
> to state explicitly where (if anywhere) one is required
> to send parameters in a specific order. Requiring that
> x not exceed y is equivalent to requiring y to be greater
> than or equal to x. It doesn't imply the order. In any case,
> as long as each side independently ensures that the maximum
> value it will accept for FirstBurstSize does not exceed
> the maximum value it will accept for MaxBurstSize, it doesn't
> matter which is negotiated first. The relationship between
> these two values does not imply an order and if we want to
> force an order it will need to be done explicitly.

You are correct, it does not force an order and I was mistaken
to imply that it did.  I also believe we do not need or want to
force an order.


> I don't think there are currently
> any cases where order of negotiation is required.

You are correct, the dependencies I mentioned exist,
but they do not require imposition of any ordering
on the negotiation -- my mistake.

Bob Russell