RE: iSCSI: keys/parameter dependence

[pat_thaler@agilent.com]

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")

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.

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.

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.

Actually, the draft does not explicitly say that one needs to check that
MaxBurstSize and FirstBurstSize have the right relationship at the end
of negotiation. Is that a requirement? Mathematically, if both sides
offer/respond with a pair of values that meet the rule, then the final
values will meet the rule. 

Call the values:
Mi - initiator's preferred value of MaxBurstSize
Mt - target's preferred value of MaxBurstSize
Fi - initiator's preferred value of FirstBurstSize
Ft - target's preferred value of FirstBurstSize
Mn - negotiation result for MaxBurstSize
Fn - negotiation result for FirstBursSize

Mi >= Fi
Mt >= Ft
Mn = min (Mi, Mt)
Fn = min (Fi, Ft)

then it is guaranteed that
Mn >= Fn
for example, take the case where Mi < Mt.
This results in Mn = Mi
If Fi > Ft
Then Fn = Ft and 
Mn = Mi > Fi > Ft = Fn

I might check anyway because I don't trust my partner to get the values
right or to offer both when changing one to the point that the other
needs to change, but should the check be required?

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.

Regards,
Pat

-----Original Message-----
From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
Sent: Sunday, June 02, 2002 12:08 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: keys/parameter dependence


Hi Mike:

Comments in text below:

> >From 12-95 4.3.3 pg 80 (and also in 4.4 pg 83):
>
> Whenever parameter action or acceptance are dependent on other parameters,
> the dependent parameters MUST be sent after the parameters on
> which they depend. If they are sent within the same command, a
> response for a parameter might imply responses for others.
>
>
> Is an example of this FirstBurstSize being dependent on MaxBurstSize (or
> vis-versa)?

yes


> So MaxBurstSize MUST come before FirstBurstSize?

Not necessarily, since it says "Whenever parameter action or acceptance
are dependent on other parameters, ...".  If you want to offer a value of
FirstBurstSize (say 524288) that is greater than the default value 262144
of MaxBurstSize then a value of MaxBurstSize at least as large as 524288
must be offered first -- otherwise the offered value of 262144 for
FirstBurstSize could not be accepted, since that would violate the
requirement in section 11.14 that "FirstBurstSize MUST NOT exceed
MaxBurstSize." (and the (default) value for MaxBurstSize would be
exceeded if the offered value were accepted at that point in the
negotiations.)

On the other hand, if you want to offer a value of MaxBurstSize (say 32768)
that is smaller than the default value 65536 of FirstBurstSize then a value
of FirstBurstSize no larger than 32768 must be offered first -- otherwise
the offered value of 32768 for MaxBurstSize cannot be accepted, since that
would violate the same requirement at that point in the negotiations.


> I don't see any definition of operational parameters.  Just in section 11
> keys that are not "declarative" are "operational keys".

In draft 12-95, Chapter 11 is entitled "Login/Text Operational Keys",
and the fourth paragraph in this chapter says:
"Keys marked as "declarative" may appear also in the SecurityNegotiation
stage while all other keys described in this chaper are operational keys."

Doesn't that pretty clearly define operational keys?


> Also, the spec goes back and forth between the terms "keys"/"parameters"
and
> "operational keys"/"operational parameters"/"operational negotiation
> parameter keys".  Is this something that should be cleaned up?

It would certainly help to use consistent terminology throughout.

Best,

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774