RE: iSCSI: keys/parameter dependence

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Tue, 4 Jun 2002 pat_thaler@agilent.com wrote:

> Robert,
>
> You seem to be assuming that the set of values for keys must be a valid set
> of keys at any time during the negotiation. If that is the rule then, for
> example, if one is planning to increase FirstBurstSize over the default
> value of MaxBurstSize, one has to increase MaxBurstSize first. Similarly, if
> one was going to decrease MaxBurstSize below the default of FirstBurstSize
> then one needs to decrease FirstBurstSize first. (Call this "valid when
> set")
>
> The draft doesn't state that this is a rule for negotiation. It would work
> just as well to require that the set of parameters be valid at the end of
> negotiation. With this rule, it is okay to set the parameters in either
> order. One can check that a parameter relationship rule is met when all the
> parameters covered by the rule have been negotiated or when one is ready to
> set the T bit. (Call this "valid at commit")

I vote for the latter.

> The draft needs to clarify whether the rule is valid when set or valid at
> commit because there will be interoperability problems between a device
> applying valid when set and one applying valid at commit. Actually, the
> draft doesn't even say you need to check the values and it isn't clear a
> check is necessary though it is prudent. One possibility is to say that one
> doesn't check non-final results but may check when the negotiations involved
> have responses or before commit.

Sounds good.

> Note that the valid when set rule imposes certain complexities.
> For example:
> Initiator wants to set FirstBurstSize larger than MaxBurstSize default.
> It therefore sends MaxBurstSize first.
> It turns out that the target wants to set MaxBurstSize smaller than the
> default for FirstBurstSize so it cannot reply to MaxBurstSize right away.
> It has to lower FirstBurstSize first
> First the Target has to check forward in its receive buffer to see if
> the initiator made an offer for FirstBurstSize, then respond to that
> offer or, if the offer hasn't been made it has to make its offer.
> Then it can send MaxBurstSize.
>
> That is a pain and things like this are causing login code to grow
> beyond what is reasonable and necessary.

Agreed. Let's avoid if if possible.

> Furthermore, 4.2 says "Conservative
> design requires also that default values should not be
> relied upon when use of some other value has serious consequences."
> Failing negotiation because you think your partner set MaxBurstSize
> lower than the default value of FirstBurstSize seems like a serious
> consequence.

Eek. Yes.

> One could do a sentence like:
> While negotiations are incomplete, the set of values may not meet all the
> dependency requirements (e.g. MaxBurstSize might be less than FirstBurst
> size when one has been negotiated and the other has not completed
> negotiation). The initiator or target making an offer or sending a response
> that results in such an inconsistancy MUST offer the other value when
> necessary to resolve the inconsistancy. Conservative design also requires
> that the final values of negotiation be checked for a dependency when
> failure to meet the dependency has serious consequences.

That sounds good.

Take care,

Bill