RE: iSCSI: not offering a key

[Black_David@emc.com]

> My question is that if there is no such thing as an implicit value, then a
> "default value" shouldn't exist, right?  Isn't a "default" implicit?

There are two senses of implicit here that are subtly different:

(1) A "default value" is what is used in the absence of negotiation.
	It is implicit only in the sense of "what results from the
	absence of negotiation".
(2) An absence of negotiation is an absence of negotiation.  iSCSI
	login does not treat the absence of a key as equivalent to sending
	<key>=<default value>.  There are NO implicit negotiation steps.

So a "default value" is to be used implicitly if it's not negotiated,
but negotiation is *always* completely explicit to avoid possible confusion
- if an implementation wants to negotiate something, it has to explicitly
negotiate it, and the other side must explicitly respond.

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

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

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.
In contrast, if there are no implicit offers, an implementation has the
choice of always choosing to negotiate the keys whose default values
differ between versions, which looks like a simpler approach to me.

The upshot is that default values are supposed to be used in the absence
of negotiation, but having them play no special role in negotiation
results in a more robust negotiation protocol and potentially simpler
implementations.

Picking up Robert Russell's question on this issue:

> It seems to me that your interpretation is adding something new that
> is not in the standard and was never intended to be in the standard.
> That is that the value of keys that were not negotiated is "unknown"
> or uncertain.  On the contrary, the standard is quit explicit that
> all keys have default values, and if a key is not negotiated then it
> retains its default value on both sides of the connection, initiator
> and target.  If this were not the case, then we would be in the
> situation of essentially requiring the negotiation of every key,
> just to confirm the defaults, and this is clearly contrary to
> the whole idea of the negotiation process.
> 
> Am I misunderstanding what you are saying?

Yes, see above.  The Initiator who thinks the default is still 8191 has
a bug, but causing the whole negotiation to fail for that sort of bug
appears to be going seriously overboard.  Negotiation is optional, but
once negotiation of a key is commenced, it must be concluded explicitly.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------