Re: iscsi : originating & responding parties in login.

[Santosh Rao <santoshr@cup.hp.com>]

Julian,

I don't understand why that requirement exists. An initiator should be
considered as the originator if he sends a login key implicitly thru the
use of defaults. This ensures that the login process ends at the
initiator and avoids redundant login handshakes.

Could you please explain further as to why you need to differentiate b/n
an initiator that sent keys explicitly and one that used defaults ? 

Thanks,
Santosh


Julian Satran wrote:
> 
> Santosh,
> 
> The reason for this negotiation rule is to make it stateless.
> 
> Julo
> 
>   Santosh Rao
>   <santoshr@cup.hp.com>                 To:        Julian
>   Sent by: santoshr@cup.hp.com  Satran/Haifa/IBM@IBMIL
>                                         cc:        IPS Reflector
>   03-10-01 23:23                <ips@ece.cmu.edu>
>   Please respond to Santosh Rao         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
> ##################################

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