Subject: RE: iSCSI: Boolean value (yes, no) negotiation

From: "Martin, Nick" <[email-masked]>
Date: Wed, 6 Feb 2002 13:17:36 -0600

Lakshmi,

It is my understanding, that if either initiator or target begins
negotiation for a boolean by sending a key=value pair, the responder
applies the specified boolean function (to the requested value and the
current value) to obtain the result.  The result is then included in a
reply (unless the rules say it may be omitted).  This negotiation is
concluded.

I believe it should not be permitted for the responder, desiring a
different outcome, to later initiate negotiation for a different value
of the same parameter.  If both initiator and target were permitted to
do this, it can cause an endless loop.  However I do not find where this
is documented.

I have found an option for the target other than rejecting the login.
It can reject this parameter value with key=Reject.  The initiator in
this case can then accept the value previously in effect, negotiate for
another value, or close the connection.  I believe sending key=Reject
does not require that the entire login should fail.  The current value
for key should be unchanged by a negotiation ending in key=Reject, just
as if it never happened.

It is not always clear to me whether such negotiations are intended only
to allow selection of preferred modes of operation, or to enable
implementations which do not support certain features to operate with
other implementations which do not require those features.

For example, it is not stated whether a target or an initiator SHOULD or
MUST implement/accept both ImmediateData=yes and ImmediateData=no.

If these are for preferences, and the initiator and target are
configured for different preferences, what should be the result?  Either
result may allow operation.  In fact neither may be optimal for both
parties at the same time.  Is the result predictable?  Should we
negotiate differently for preferences versus requirements?  For example
should an initiator only negotiate preferences after the target has had
a chance to negotiate requirements?  Should we expect that key=Reject
could be the response to almost any key negotiation?

The suggestion by Rahul to use key=? is not permitted.  key=? is only
permitted in text commands, during full feature phase.  It returns the
current value, not the list of support values.  Requesting the list of
supported values is not a current capability.

Thanks,
Nick

> -----Original Message-----
> From: Lakshmi Ramasubramanian [mailto:[email-masked]]
> Sent: Wednesday, February 06, 2002 11:26 AM
> To: [email-masked]
> Subject: iSCSI: Boolean value (yes, no) negotiation
> 
> 
> Could someone please clarify Boolean key=value usage
> (such as "ImmediateData=yes", etc)?
> 
> For example, the initiator sends to target "ImmediateData=no". 
> But the target wants ImmediateData. So, it sends back
> "ImmediateData=yes".
> The initiator, being able to handle it, sends back "ImmediateData=no".
> Now, they use immediate data in the PDUs. 
> 
> Is this valid? Or, in the above case if the target can't handle 
> non-immediate data it has to reject the login ?
> 
> thanks!
>  -lakshmi
>

---

From: "Buck Landry" <[email-masked]>
Date: Wed, 6 Feb 2002 13:59:41 -0600

Not that sixty other people won't answer this, but draft v10 states pretty clearly in section 1.2.4 that:

-> The value "?" MUST be used ONLY in Full Feature Phase.

IMHO if the initiator is willing to work with *or* without ImmediateData it should send ImmediateData=yes and let the target decide.

If the initiator can't use ImmediateData, it should send ImmediateData=no.  If the target supports only ImmediateData (now *that* would be interesting), the login session might as well terminate because the two implementations clearly aren't compatible.

I suppose if the initiator can only handle ImmediateData=yes, it should send that and terminate the session if the target sends back ImmediateData=no.  "Bad initiator! *whack*"

To respond directly to lakshmi,

> So that means, if the target needs to use ONLY immediate data,
> it has to fail the login because the initiator said NO to ImmediateData?

(again, IMHO) yup.

--buck

-----Original Message-----
From: Rahul Bhagwat [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 12:44 PM
To: Lakshmi Ramasubramanian; [email-masked]
Subject: Re: iSCSI: Boolean value (yes, no) negotiation

In this particular case, the default value for the key is "Yes". Initiator
should
be able to express it's preference that it wants to do away with immediate
date if the target is willing to do so (without forcing it through the AND
function),
else the initiator is okay to work with immedidate data. Looks like this is
not
possible with the boolean  negotiation. Can we use ImmediateData=? to get
the
supported value from the target. If the target responds with yes, the
initiator can
either use immediate data (by responding Yes) or not use it (by responding
No).
If the target response no, the initiator does not use immediate data. In
this case,
the Login need not terminate. Does this give the solution ? Is this a valid
thing ?

Regards,
Rahul
----- Original Message -----
From: "Lakshmi Ramasubramanian" <[email-masked]>
To: "Rahul Bhagwat" <[email-masked]>; <[email-masked]>
Sent: Wednesday, February 06, 2002 11:40 PM
Subject: RE: iSCSI: Boolean value (yes, no) negotiation

> So that means, if the target needs to use ONLY immediate data,
> it has to fail the login because the initiator said NO to ImmediateData?
>
> thanks!
>  -lakshmi
>
> From: Rahul Bhagwat [mailto:[email-masked]]
> Sent: Wednesday, February 06, 2002 10:07 AM
> To: Lakshmi Ramasubramanian; [email-masked]
> Subject: Re: iSCSI: Boolean value (yes, no) negotiation
>
>
> I believe a key is not negotiated thrice as you have pointed out. That
> is a sender offers a value, receiver offers it's own and that's it. (I
> think specs has a mention that a key cannot be negotiated twice. This
> example falls into that category.) The result of the negotiation is key
> dependent. For example, in this particular key, when initiator sends
> ImmediateData=no, the negotiation is over as this is an
> AND function. However it is not an error to send back a response. In any
> case, the outcome of the result was decided for the initiator when it
> sent the key first and for the target when it received the key.
>
> Regards,
> Rahul
> ----- Original Message -----
> From: "Lakshmi Ramasubramanian" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, February 06, 2002 10:56 PM

---

From: Eddy Quicksall <[email-masked]>
Date: Wed, 6 Feb 2002 15:59:44 -0500

The "?" value is only valid in FFP.

Eddy

-----Original Message-----
From: Rahul Bhagwat [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 1:44 PM
To: Lakshmi Ramasubramanian; [email-masked]
Subject: Re: iSCSI: Boolean value (yes, no) negotiation

Regards,
Rahul

---

From: Eddy Quicksall <[email-masked]>
Date: Wed, 6 Feb 2002 16:55:45 -0500

It looks to me like "reject" is intended for list negotiations (notice "all
of the offered options" ... I think that is referring to list options):

If a responder does not support or is not allowed to use all of the
offered options with a specific originator, it may use the constant
"Reject".

Julian, correct me if I am wrong.

Eddy

-----Original Message-----
From: Martin, Nick [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 2:18 PM
To: Lakshmi Ramasubramanian; [email-masked]
Subject: RE: iSCSI: Boolean value (yes, no) negotiation

Lakshmi,

Thanks,
Nick

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 6 Feb 2002 19:38:43 -0500

This seems to be a interesting scenario. 

Mapping this to traditional SCSI model the initiator during message out phase sends to the target its capabilities (support disconnect/reconnect etc) if the target supports the message it acknowledges and the agreement prevails as long as the devices stay powered or else a message reject is sent by the target and the state machine moves on to the next phase.

An inference out of this quote is that the target holds the authority to make final decisions on any proposals that the initiator may choose to make. 

Elaborating the example on which this thread started -

I->T ImmediateData=no
T->I ImmediateData=no

Irrespective of intelligence either in the target and/or initiator, they should not be soliciting choices otherwise convergence of a proposal might be cumbersome.

Thanks,
Rakesh

Original Message:
-----------------
From: Rahul Bhagwat [email-masked]
Date: Thu, 7 Feb 2002 00:14:28 +0530
To: [email-masked], [email-masked]
Subject: Re: iSCSI: Boolean value (yes, no) negotiation

Regards,
Rahul
----- Original Message -----
From: "Lakshmi Ramasubramanian" <[email-masked]>
To: "Rahul Bhagwat" <[email-masked]>; <[email-masked]>
Sent: Wednesday, February 06, 2002 11:40 PM
Subject: RE: iSCSI: Boolean value (yes, no) negotiation

> > non-immediate data it has to reject the login ?

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 7 Feb 2002 06:41:15 +0200

Eddy is right - reject is not intended/valid for booleans.

Julo

                    Eddy Quicksall                                                               
                    <Eddy_Quicksall@iv       To:     "Martin, Nick" <[email-masked]>,    
                    ivity.com>                Lakshmi Ramasubramanian                            
                                              <[email-masked]>, [email-masked]    
                    06-02-02 23:55           cc:     Julian Satran/Haifa/IBM@IBMIL               
                                             Subject:     RE: iSCSI: Boolean value (yes, no)     
                                              negotiation                                        

Eddy

-----Original Message-----
From: Martin, Nick [mailto:[email-masked]]
Sent: Wednesday, February 06, 2002 2:18 PM
To: Lakshmi Ramasubramanian; [email-masked]
Subject: RE: iSCSI: Boolean value (yes, no) negotiation

Lakshmi,

Thanks,
Nick

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 9 Feb 2002 06:51:44 +0200

Martin,

All you say is correct. The function AND means that both parties have to
say yes for it to hold.
The target cannot force his decision on the initiator.  On the other hand I
do not see this as an issue of practical importance (in this case) as a
initiator will most probably say yes about ImmediateData (no resources
involved) and a target will say what it wants (resources involved) and will
have the issue settled in one round.

I->T ImmediateData=Yes
T->I ImediateData=No /No

Julo

                    "Martin, Nick"                                                           
                    <Nick.Martin@C       To:     Julian Satran/Haifa/IBM@IBMIL, "Eddy        
                    OMPAQ.com>            Quicksall" <[email-masked]>            
                                         cc:     <[email-masked]>, "Lakshmi                 
                    08-02-02 23:30        Ramasubramanian" <[email-masked]>    
                                         Subject:     RE: iSCSI: Boolean value (yes, no)     
                                          negotiation                                        

Julian, Eddy, and Lakshmi,

OK, since I had it wrong last time.  Let me try to explain it again.

The default for ImmediateData is yes.  The result function is AND.

I->T ImmediateData=no

Presuming the target wanted "yes", the result ("yes" AND "no") is "no".

The target has one option

T->I ImmediateData=no

If this response is omitted, the result is the same.  Login proceeds
presuming ImmediateData=no.

I have been corrected that ImmediateData=Reject is not valid.
A response of ImmediateData=yes is also not valid.
I do not see a login response code meaning option not supported by
target.

From this in infer that support for both ImmediateData=yes and
ImmediateData=no is required.  One is not supposed to build a target nor
an initiator which does not support both possible values for each
boolean.  For either possible result of the negotiation, both parties
should be able to proceed.

Is this correct?  If so, I think it is worth stating that support for
both outcomes is required.

Thanks,
Nick

> From: Julian Satran [mailto:[email-masked]]
> Sent: Wednesday, February 06, 2002 10:41 PM
> To: Eddy Quicksall
> Cc: [email-masked]; julian_satran@il. ibm. com (E-mail);
> Martin, Nick;
> Lakshmi Ramasubramanian

---

From: Eddy Quicksall <[email-masked]>
Date: Sun, 10 Feb 2002 12:13:43 -0500

Regarding "support for both outcomes is required". I don't agree. Targets
can have all sorts of reasons not to support both.

It may be useful to have a value like "Reject" apply for cases like this.
Then, the initiator or target would the option to disconnect or try to keep
going depending on the key.

Eddy

-----Original Message-----
From: Martin, Nick [mailto:[email-masked]]
Sent: Friday, February 08, 2002 4:30 PM
To: Julian Satran; Eddy Quicksall
Cc: [email-masked]; Lakshmi Ramasubramanian
Subject: RE: iSCSI: Boolean value (yes, no) negotiation

I->T ImmediateData=no

T->I ImmediateData=no          

Thanks,
Nick

---

From: "Martin, Nick" <[email-masked]>
Date: Mon, 11 Feb 2002 10:52:06 -0600

Paul,

I agree. You are correct, I was not.  
Only the irresistible boolean negotiation values are required to be
supported.  
This would be "no" where the rule is "AND", and "yes" where the rule is
"OR".

Thanks,
Nick

> From: Paul Koning [mailto:[email-masked]]
> Sent: Monday, February 11, 2002 9:17 AM
> To: Martin, Nick
> Cc: [email-masked]
> >>>>> "Martin," == Martin, Nick <[email-masked]> writes:
> 
>  Martin,> From this in infer that support for both 
> ImmediateData=yes and
>  Martin,> ImmediateData=no is required.  One is not supposed to build
>  Martin,> a target nor an initiator which does not support both
>  Martin,> possible values for each boolean.  For either possible
>  Martin,> result of the negotiation, both parties should be able to
>  Martin,> proceed.
> 
> I don't agree, and it doesn't follow from the analysis.
> 
> If the rule is AND, then either end can force the outcome "no" by
> proposing "no" (as initiator) or replying with "no" (as target).
> 
> If the rule is OR, then either end can force outcome "yes" by similar
> reasoning. 
> 
> So the negotiation rules imply that you must support the outcome that
> the other end can force.  The rules imply nothing about the other
> outcome (e.g., "yes" for ImmediateData).  That could be optional to
> support as far as the mechanism goes.  The spec can make it mandatory
> if it is agreed to do so, but the mechanism doesn't affect such a
> decision. 
> 
>     paul
> 
>

---

From: "Julian Satran" <[email-masked]>
Date: Mon, 11 Feb 2002 19:30:57 +0200

Eddy,

You are correct. Support for both, in this case, is a SCSI issue. We can't 
mandate support for immediate data.

Julo

Eddy Quicksall <[email-masked]>
10-02-02 19:13

        To:     "Martin, Nick" <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked], Lakshmi Ramasubramanian <[email-masked]>
        Subject:        RE: iSCSI: Boolean value (yes, no) negotiation

It may be useful to have a value like "Reject" apply for cases like this.
Then, the initiator or target would the option to disconnect or try to 
keep
going depending on the key.

Eddy

-----Original Message-----
From: Martin, Nick [mailto:[email-masked]]
Sent: Friday, February 08, 2002 4:30 PM
To: Julian Satran; Eddy Quicksall
Cc: [email-masked]; Lakshmi Ramasubramanian
Subject: RE: iSCSI: Boolean value (yes, no) negotiation

I->T ImmediateData=no

T->I ImmediateData=no 

Thanks,
Nick