Subject: RE: iSCSI: not offering a key

From: Eddy Quicksall <[email-masked]>
Date: Fri, 1 Feb 2002 07:37:17 -0500

Maybe I misunderstood your note.
 
What I was referring to is that you said: 
 
If for some reason the other party doesn't have the
same default (bugs happen), negotiation should drive
both parties to an agreed value ...
 
Reading on I assumed you meant that we should add code to cope with that. If
you take that to an extreme, we would be adding "lots of code" just to cover
all possible bugs.
 
An implementation should only have to cover the other ends bugs that could
cause a crash or data corruption at our end. In this case, I don't think
that means we should change the standard to do extra negotiations just to
cover possible bugs.
 
Again, maybe I misunderstood what you were trying to say.
 
Eddy
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 3:16 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI: not offering a key
 
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
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: Paul Koning <[email-masked]>
Date: Fri, 1 Feb 2002 10:36:07 -0500

Excerpt of message (sent 31 January 2002) by [email-masked]:
> > 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

---

From: [email-masked]
Date: Fri, 1 Feb 2002 10:08:28 -0500

Eddy,
 
> Reading on I assumed you meant that we should add code to cope with that.
> If you take that to an extreme, we would be adding "lots of code" just to
cover all possible bugs.
 
That was definitely not my intention.  If either party chooses to negotiate
a value, the negotiation
code that has to be implemented anyway will drive both parties to agreement,
but notice the *if*.
I definitely do not want this taken to an extreme that would require all
keys to be negotiated in
all cases. As a consequence, there will be situations in which mistakes
occur that cause the
two parties to have different ideas of what the default value is for a key
that wasn't negotiated
(to err is human, most code is written by humans ... ).  I am recommending
an "if in doubt,
negotiate" approach to implementation that will tend to limit such problems
to relatively
unimportant keys.  Coverage of "all possible bugs" was not my intention.
 
> An implementation should only have to cover the other ends bugs that could
cause a crash
> or data corruption at our end. In this case, I don't think that means we
should change the
> standard to do extra negotiations just to cover possible bugs. 
 
I think we have a serious difference in philosophy.  The usual IETF
dictum of being conservative in what is sent and liberal in what is
accepted implies coverage of more than just bugs that could cause a
crash or data corruption - see the recent example I sent to the list
of how a notion of "implicit offers" could cause a silly breakdown
in negotiation.  OTOH, being liberal in what is accepted does not
equate to covering all possible bugs - it means doing one's best to
do something reasonable in the face of the unexpected as opposed
to regarding the least little thing going wrong as a fatal error and
reason to immediately give up.
 
As to the standard, I'm not proposing any change.  I'm recommending that
implementers
exercise good judgment by choosing to negotiate any parameters that are
important to the behavior
and performance of their implementation (which sounds like common sense -
are you objecting to
this?).  The negotiation algorithm has been (and should be) specified in a
way that is robust to
minor things going wrong, and hence just using it provides some robustness
against minor
things going wrong.
 
The overall principle is somewhat akin to the exhortation not to complain
about the behavior of
the government if you didn't bother to vote.  I think we're close to violent
agreement.
 
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
---------------------------------------------------

 -----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Friday, February 01, 2002 7:37 AM
To: [email-masked]; Eddy Quicksall
Cc: [email-masked]
Subject: RE: iSCSI: not offering a key

 

 
 
Eddy
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 3:16 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI: not offering a key

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: [email-masked]
Date: Fri, 1 Feb 2002 11:26:25 -0500

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

> (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.
 
> of the two versions, or the different parameter limits, or the

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

Thanks,
--David

---

From: Eddy Quicksall <[email-masked]>
Date: Fri, 1 Feb 2002 21:53:15 -0500

> I'm recommending that implementers exercise good judgment ... are you
objecting to this?
 
No
 
> I think we're close to violent agreement.
 
Yes
 
Actually, I started this thread because I was wondering what was meant by
the sentence:
 
Not offering a key for negotiation is not 
equivalent to offering the current (or default) value.
 
And I think that was answered.
 
Thanks
 
Eddy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 01, 2002 10:08 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI: not offering a key
 
Eddy,
 
cover all possible bugs.

cause a crash
should change the

 
 
Thanks,
--David
 
 -----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Friday, February 01, 2002 7:37 AM
To: [email-masked]; Eddy Quicksall
Cc: [email-masked]
Subject: RE: iSCSI: not offering a key

 

 
Eddy
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 3:16 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI: not offering a key

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