Subject: RE: iSCSI: not offering a key

From: "LEMAY,KEVIN (A-Roseville,ex1)" <[email-masked]>
Date: Fri, 25 Jan 2002 11:56:31 -0700

I would disagree that it serves no purpose. It has code implications.

If your implementation requires/desires values other than the defaults, then
those parameters must be negotiated.

For well chosen defaults, this should mean simplier login exchanges.

The alternative would mean that every parameter must be negotiated every
time.

Kevin Lemay
Agilent Technologies

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Friday, January 25, 2002 10:41 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: not offering a key

Excerpt of message (sent 25 January 2002) by Eddy Quicksall:
> The spec says:
>  
> Not offering a key for negotiation is not 
> equivalent to offering the current (or default) value.
>  
> Does anyone know why?

I remember a long discussion about that some months ago.  As far as I
can tell, this rule in the spec is unnecessary complexity that serves
no purpose.  Certainly nothing was brought up in that discussion that
sounded like a good reason to have the current rule.

   paul

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 25 Jan 2002 21:00:15 +0200

To keep the negotiation stateless - Julo

Eddy Quicksall <[email-masked]>
25-01-02 17:08

        To:     "ips@ece. cmu. edu (E-mail)" <[email-masked]>
        cc:     Julian Satran/Haifa/IBM@IBMIL
        Subject:        iSCSI: not offering a key

The spec says:

Does anyone know why?
 
Eddy

---

From: Eddy Quicksall <[email-masked]>
Date: Mon, 28 Jan 2002 12:41:45 -0500

I don't think we should be in the business of adding lots of code to cope
with possible bugs at the other end ... there would be no end to what you
would do and how you would do it.
 
Couldn't we just strike the sentence and say what Dr. Russell said. I would
suggest something like:
 
"There is no such thing as implicit offers. If an explicit offer is not made
then a reply cannot be expected."
 
-- cut and past from his EMAIL --
I believe this sentence was added to the spec because at the
last UNH plugfest, several people were interpreting "no explicit
offer" of a key as an "implicit" offer of the default for the key,
and were therefore expecting a reply.  This sentence is intended
to prevent that interpretation -- if you don't make an explict offer
you cannot expect a reply -- there are no such things as implicit offers.
 
Eddy
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, January 26, 2002 3:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI: not offering a key
 
> Maybe I don't understand the sentence. I interpret it to mean that if the
> default value is acceptable to me then not offering it is somehow
different
> than the default ... and that confuses me (well, actually it makes me
wonder
> if the sentence is trying to say something else).
 
Here are two examples of how it's different:
 
(1) If for some reason the other party doesn't have the
    same default (bugs happen), negotiation should drive
    both parties to an agreed value, but in the absence of
    negotiation, the other party might do something different.
    Moral: if a key value is important, it MUST be negotiated.
    This is a little weaker than Luben's statement that
    all keys always have to be negotiated.  That strength
    was never intended.
 
(2) If the other party wants to negotiate the value and
    both offer the same default value, not offering the default
    results in an additional step before the negotiation can
    conclude, viz:
 
    -> Nothing        -> Key=Default
    <- Key=Default    <- Key=Default
    -> Key=Default
 
--David

---

From: [email-masked]
Date: Tue, 29 Jan 2002 03:16:25 -0500

I don't understand how this leads to "lots of code".  The
underlying principle is to negotiate anything you care about
and not to complain about things that you didn't negotiate.
Saying that there are no implicit offers is fine with me.
 
Thanks,
--David
-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Monday, January 28, 2002 12:42 PM
To: julian_satran@il. ibm. com (E-mail)
Cc: [email-masked]; Robert D. Russell
Subject: RE: iSCSI: not offering a key

 

Eddy
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, January 26, 2002 3:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI: not offering a key
 
different
wonder

 

--David

---

From: "Fischer, Michael" <[email-masked]>
Date: Tue, 29 Jan 2002 11:22:51 -0800

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?  

What I am reading from this discussion is that all iSCSI initiators must
send _all_ keys.  How else is behavior going to be stable?

Michael

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 6:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI: not offering a key

Excerpt of message (sent 29 January 2002) by [email-masked]:
> > But that's an artifact of a peculiar design approach for a negotiation
> > algorithm.  The obvious design approach says that there are two ways
> > to *encode* a key having the default value: by sending the key with
> > that value, and by omitting that key.  Those two encodings should have
> > the same effect on the negotiation state machine.
> 
> The problem with this line of reasoning is that it assumes completely
> identical state machines at both ends of the negotiation. 

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.

	 paul

---

From: [email-masked]
Date: Thu, 31 Jan 2002 20:17:54 -0500

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

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

> 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
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------