RE: iSCSI: not offering a key

[Black_David@emc.com]

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

I'd leave that decision to implementers, who understand far more about
what matters to their implementation than WG members who aren't familiar
with the details of that specific implementation.  As indicated in a
previous message, I believe that this approach to defaults and negotiation
is in line with the IETF dictum of being conservative in what is sent and
liberal in what is accepted - disallowing "implicit offers" is conservative,
because it results in less state having to be inferred from a message, IMHO.

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

That's not correct.  The problem occurs in the above scenario because
the Initiator *is* treating the <key>=<value> supplied by the Target
identically to an omitted (and hence defaulted) key.  Recall that the
problem is caused by Initiator and Target having different views of what
the default value is, so that while the Target believes it has offered
a non-default value, the Initiator believes that the Target has
agreed to the default value offered by omission in the initial message,
hence the Initiator does not respond to the Target, and the negotiation
fails.
 
> > 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...

But it's more complexity ... why force this on implementers?

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