RE: iscsi : iscsi parameter default values

["John Hufferd" <hufferd@us.ibm.com>]

Eddy,
Only one correction below.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com


"Eddy Quicksall" <Eddy_Quicksall@iVivity.com> on 10/02/2001 09:08:17 AM

To:   "'Santosh Rao'" <santoshr@cup.hp.com>, John Hufferd/San
      Jose/IBM@IBMUS
cc:   <ips@ece.cmu.edu>
Subject:  RE: iscsi : iscsi parameter default values



Would all cases look like these? (If I made a mistake, please correct it).

Note that I am attempting to use the rule specified as:

 The negotiation MAY
 proceed only up to the point where both parties can unequivocally
 compute the result; continuing beyond this point is OPTIONAL.

And my interpretation of the rule is that when a responder gets a binary
value, it can compare that against the default and can therefore compute
the
result and therefore does not need to respond if the result is what he
wants.

Am I correct in my interpretation?

Eddy

Default ImmediateData="yes"
===========================
Initiator wants immediate data & target supports it.
---------------------------------------------------

I -> T : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

yes * yes = yes

Initiator does not want immediate data & target supports it.
-----------------------------------------------------------

I -> T : ImmediateData="no".
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

no * yes = no

Initiator wants immediate data & target does not support it.
-----------------------------------------------------------

I -> T : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

T -> I : ImmediateData="no".
         (CSG=Operational, NSG=FFP). T=1

yes * no = no

Initiator does not want immediate data & does not target support it.
-------------------------------------------------------------------

I -> T : ImmediateData="no".
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

no * yes = no

Default ImmediateData="no"
==========================
Initiator wants immediate data & target supports it.
-----------------------------------------------------------

I -> T : ImmediateData="yes"
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)

yes * no = no

[Huff] yes * no (but OK) = Yes
[/Huff]

Initiator does not want immediate data & target supports it.
--------------------------------------------------------------

I -> T : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent)
         (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)

no * no = no

Initiator wants immediate data & target does not support it.
-----------------------------------------------------------

I -> T : ImmediateData="yes".
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

yes * no = no

Initiator does not want immediate data & does not target support it.
-------------------------------------------------------------------

I -> T : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

no * no = no

Eddy

-----Original Message-----
From: Santosh Rao [mailto:santoshr@cup.hp.com]
Sent: Monday, October 01, 2001 7:16 PM
To: John Hufferd
Cc: ips@ece.cmu.edu
Subject: Re: iscsi : iscsi parameter default values



John Hufferd wrote:
>
> I think your logic reverses if the support wanted is yes and the
target is
> supporting yes.

How so ?

Here are the scenarios when initiator wants to use immediate data and
target supports it, first with default ImmediateData set to "yes" and
then, with default Immediatedata set to "no". In both cases, a single
login handshake occurs. The only difference being that when
ImmediateData defaults to "yes", the key need not be sent in either
direction, whereas when it defaults to no, the ImmediateData key travels
in both directions in the login payload.

(FFP = FullFeaturePhase).

Default ImmediateData="yes"
---------------------------
Initator wants immediate data & targets supports it.
----------------------------------------------------

I -> T : (no key sent).
         (CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent).
         (CSG=Operational, NSG=FFP). T=1


Default ImmediateData="no"
--------------------------
Initiator wants immediate data and target supports it.
-----------------------------------------------------------

I -> T : ImmediateData="yes"
         (CSG=Operational, NSG=FFP). T=1

T -> I : Immediatedata="yes"
         (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.)

Same number of handshakes in both cases. The only difference is that the
key is not sent in the first case, and key is explicitly exchanged in
the 2nd case.


> If they say No they clearly do not care about extra handshakes sense
R2T is
> all they have and it requires extra handshakes.

Hmm.... The way I see it, an initiator that does not use ImmediateData
is a simple initiator and is more interested in seeing a simpler login
(completed in a single login req/rsp) than one that does support
ImmediateData.

Those implementations that can do the extra work of supporting
ImmediateData can well do the extra work of negotiating for its use.

Regards,
Santosh