RE: iSCSI: not offering a key

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 31 January 2002) by Black_David@emc.com:
> > What I am reading from this discussion is that all iSCSI initiators must
> > send _all_ keys.  How else is behavior going to be stable?
> 
> "_all_ keys" --> "_all_ important keys".  If every key is important to
> an implementation, then it should negotiate every one of them.

I find this very strange.  Certainly no use of "default" I have ever
seen anywhere else takes this view -- that "default" exists for the
purpose of assigning values to unimportant things.  If that approach
made sense, then we should have default only for parameters whose
values don't matter much.  (Which parameters are those?)
 
> > It seems strange to complexify the algorithms on the grounds that
> > people will implement things incorrectly, but it looks like I'm
> > fighting a lost cause here so I'll stop now.
> 
> IMHO, adding a notion of implicit offers of default values is more
> complex, because in the case where the Initiator does not negotiate a
> value and the Target replies with <key>=<value>, the following two
> additional things happen to the negotiation algorithm:
> - The Initiator must check whether <value> is the default value,
> 	and does not continue negotiation of this key if that value
> 	is acceptable.
> - The Target must check whether <value> is the default value
> 	in order to know that the Initiator may not respond if it
> 	accepts the value.
> Running the negotiation sequence until both sides have agreed
> avoids these complications, and avoids some silly negotiation
> protocol breakages ...
> 
> Suppose someone overlooks the recent change in the default for
> MaxRecvPDULength from 8191 to 8192, and suppose a Target who thinks
> 8192 is the default offers MaxRecvPDULength=8191 to an Initiator who
> thinks 8191 is the default.  With the two changes above, the negotiation
> fails because the Initiator doesn't send a response (it believes that
> the Target sent an explicit response to its implicit offer of 8191),
> but the Target won't receive the response required to complete the
> negotiation (it believes it sent 8191 in response to an implicit offer
> of 8192, and hence is waiting for an explicit reply), and hence no
> iSCSI session is established.  This negotiation failure is really
> silly, as both parties have all the information needed to complete
> the negotiation successfully (8191 is a likely result).

That certainly would be silly, but you get that silly result because
of the rule that you treat defaulted keys differently from keys
explicitly specified.  If you treat an omitted key the same as a
supplied key, then you would answer either way, and things are fine
(the session is established).
 
> Just to make matters worse, if we change defaults in the future and
> change the version number, we force an implementation that wants to
> support multiple versions to keep a table of what default applies to
> which version in order to comply with the two additional bullets above.

That's no different from having to know the different state machines
of the two versions, or the different parameter limits, or the
different etc. etc...

	  paul