RE: iscsi : originating & responding parties in login.

["Dev - Platys" <deva@platys.com>]

Santosh-

I agree with you. The initiator will (should) always be the originator
either
by explicitly sending the key value or not sending and thereby implicitly
negotiating
for the default value. This simplifies a lot, in  my opinion.

Julian-  is there any
specific reason, why would an initiator explicity a value even if it is
default? Can
the target not determine that by sending no keys, initiator is actually
sending a default
value? Am I missing something otherwise?

Thanks

Deva


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Santosh Rao
Sent: Wednesday, October 03, 2001 2:24 PM
To: Julian Satran
Cc: IPS Reflector
Subject: Re: iscsi : originating & responding parties in login.


Julian Satran wrote:

> Julian Satran wrote:
>
> > As negotiations can start at either initiator or target the
> originator
> > the one that starts the negotiation.
>
> Julian,
>
> OTOH, since the initiator did offer a value (the default value), is'nt
> it always the originator ? In which case [other than a target vendor
> specific proprietary key] would an operational negotiation start at
> the
> target ?
> +++ offering a value is an active thing. Defaults and previous values
> don't count. +++


This is intriguing. If an initiator explicitly sent a key value (albeit,
with the key initialized to the default), the initiator is considered
the originator. However, if the initiator chose to not send the key
explicitly, but use the default, it then becomes the responder. [if
target does not accept the default.]

This leads to different on-the-wire login behaviour if the initiator
chose to use defaults instead of sending those same key values
explicitly. It also causes an additional dummy login hand-shake for no
purpose.

Thus, in the case where initiator wants to use, say, FirstBurstSize=128
& target allows FirstBurstSize to be 8, then, the behaviour on the wire
is different depending on whether the initiator used the default or
explicitly sent the key.

Case 1) Initiator sends the default value as an explicit offering
------------------------------------------------------------------
I -> T : FirstBurstSize=128 (initiator is the originator)
	 (CSG=Operational, NSG=FFP). T=1

T -> I : FirstBurstSize=8 (target responds with lower value it
supports.)
	 (CSG=Operational, NSG=FFP). T=1

Negotiation ends at initiator with both sides picking FirstBurstSize=8.
Single login handshake.

Case 2) Initiator does not send the key. (default is in use).
-------------------------------------------------------------
I -> T : (no key sent). (defaults to 128.)
	  (CSG=Operational , NSG=FFP). T=1

T -> I : FirstBurstSize=8
	 (CSG=Operational, NSG=Operational). T=0

I -> T : FirstBurstSize=128 (initiator explicitly resends the default
!).
	(CSG=Operational, NSG=FFP). T=1

T -> I : (no key sent. but a dummy login response to conclude login is
sent).
	 (CSG=Operational, NSG=FFP). T=1

Negotiation ends at the target, with both sides settling at
FirstBurstSize=8
Login phase ends at the initiator. 2 login handshakes.


Julian : What is the benefit of the above behaviour ? It results in
inconsistent login behaviour and will only cause initiators to send
login keys explicitly, defeating the purpose of defining defaults.

I would rather the spec state that the initiator is the originator of
the key when it uses default values, so that the login behaviour is the
same in both scenarios above.

Thanks,
Santosh



> >
> > Julian,
> >
> > I've YET another login question for you :
> >
> > Please refer the following text in Section 2.2.4 of the Rev 08 draft
> :
> >
> > "For numerical negotiations, the responding party MUST respond with
> > the
> > required key."
> >
> > When the initiator uses the default settings for a login key (i.e.
> > does
> > not send the key) and a target does not support that default, it has
> > to
> > originate the key in its login response to notify the initiator that
> > it
> > does not support the default.
> >
> > In the above example, who is the originating party & responding
> party
> > ?
> > Is the initiator always considered an originating party for all the
> > operational and security keys, even if it did not explicitly send
> that
> > key in its login ?
> >
> > If the target originated a login key, say DataPDULength, (and is
> > therefore, to be considered as the originating party ?), based on
> your
> > rule quoted above, the exchange would be :
> >
> > I -> T : (no key is sent for DataPDULength. Assumes default of 16
> > units.
> > (8K).)
> >
> > T -> I : DataPDULength=8
> >
> > I -> T : DataPDULength=8  (See quoted rule above.)
> >
> > The definition of originating & responding party is not clear when
> > defaults are used by the initiator and can lead to [mis-
> > ?]interpretations  such as the above.
> >
> > The above response from I -> T seems redundant to me. I suggest that
> > the
> > draft clearly state who the originating & responding party are when
> > defaults are used, so as to avoid confusion along the above lines.
> >
> > Thanks,
> > Santosh

--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################