Re: iscsi : OpParmreset

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

> >From your answer it looks like you agree that we need a way to reset/abort
> a negotiation 

Sure, I agree we need a mechanism.

>but you object to the OpParmReset.

Not specifically.  I was only concerned that there seem to be several 
ways of aborting/terminating a negotiation.  I can count three
mechanisms
for initiator -
       a) Abort Task
       b) Empty text command with TTT=0xffffffff
       c) OpParmReset

And two for the target -
       a) Timing out the bookmark state, and Reject ("no bookmark for
          this ITT" - 0x09) the TTT.
       b) OpParmReset


I suggest that we retain only the option-(a)'s for both, and 
drop the rest.  For this to happen, the case (b) for initiator 
should probably be a Reject("Illegal bookmark") - since as you
say, it does seem ambiguous.

Regards.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com

Julian Satran wrote:
> 
> Mallikarjun,
> 
> >From your answer it looks like you agree that we need a way to reset/abort
> a negotiation but you object to the OpParmReset.
>  Abort task has the disadvantage that the target can't issue it (so that
> the target has no means to force an abort).
> An empty task request or response is ambiguous.
> We could introduce a binary field meaning goon/abort?  Is that better that
> OpParmReset (by which we can always introduce a richer semantics - like
> rest to default).
> 
> Julo
> 
> 
>                     "Mallikarjun
>                     C."                  To:     ips <ips@ece.cmu.edu>
>                     <cbm@rose.hp.c       cc:
>                     om>                  Subject:     Re: iscsi : OpParmreset
>                     Sent by:
>                     owner-ips@ece.
>                     cmu.edu
> 
> 
>                     27-09-01 03:26
>                     Please respond
>                     to cbm
> 
> 
> 
> Julian,
> 
> I assume you mean terminate/end a negotiation by "rest a
> negotiaion".  If so, I can see two more ways to do the same -
>     - aborting the task (changes from rev06 to rev07),
>     - sending an empty text command with TTT=0xffffffff.
> 
> Either should undo the results of the partial negotiation
> in FFP, as we described in "Negotiation failures" section.
> During the login, as Matthew pointed out, we don't seem to
> need OpParmReset either.
> 
> Can you please confirm if you see the same choices?  If so,
> I do not see the need for OpParmReset.
> 
> Regards.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668         Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> Julian Satran wrote:
> >
> > OpParmReset is the only way we have now to rest a negotiation in FFP
> > (public or vendor specific).
> > The restriction about R2T is related to a deadlock that can result when
> you
> > change from no to yes.
> >
> > Julo
> >
> >
> >                     "BURBRIDGE,MATTH
> >                     EW                     To:     Julian
> Satran/Haifa/IBM@IBMIL,
> >                     (HP-UnitedKingdo        ips@ece.cmu.edu
> >                     m,ex2)"                cc:
> >                     <matthew_burbrid       Subject:     RE: iscsi :
> OpParmreset
> >                     ge@hp.com>
> >                     Sent by:
> >                     owner-ips@ece.cm
> >                     u.edu
> >
> >
> >                     24-09-01 13:36
> >                     Please respond
> >                     to
> >                     "BURBRIDGE,MATTH
> >                     EW
> >                     (HP-UnitedKingdo
> >                     m,ex2)"
> >
> >
> >
> > Is OpParmReset still needed now that there is no operational parameter
> > negotiation until after the security phase?  Why would both sides
> > negoitiate
> > a set of parameters only for one side to reset.  Surely if one side
> during
> > login is not happy then it should close the connection.  In FFP, as there
> > is
> > no way to re-negotiate (after the OpParmReset) again if one side is not
> > happy then should it not close the connection and start a new one.
> >
> > Also if in FFP, if OpParmReset is sent then does it just reset those
> > parameters that can be negoiated during FFP and not those restricted to
> the
> > login phase?  If so would it be easier to negotiate those parameters
> using
> > the explicit name (e.g. InitialR2T) and remove the restriction of
> (example)
> > "Once set to no, it can not be set back to yes" - as this is what using
> > OpParmReset permits.
> >
> > Matthew
> >
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Friday, September 21, 2001 4:34 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iscsi : OpParmreset
> >
> > Santosh,
> >
> > The main purpose of this key was to explicitly cancel the effects of a
> > running negotiation and restart anew.
> > As the draft stands now there is no much difference between the two - but
> > on basic principles the purposes are different (as you well stated).  We
> > may change the value to be:
> >
> > OpParmReset=<default|current>
> >
> > to accommodate both semantics.
> >
> > Julo
> >
> >                     Santosh Rao
> >
> >                     <santoshr@cup.       To:     IPS Reflector
> > <ips@ece.cmu.edu>
> >                     hp.com>              cc:
> >
> >                     Sent by:             Subject:     iscsi : OpParmreset
> >
> >                     owner-ips@ece.
> >
> >                     cmu.edu
> >
> >                     20-09-01 22:19
> >
> >                     Please respond
> >
> >                     to Santosh Rao
> >
> > All,
> >
> > Please refer the definition of OpParmReset login key.
> >
> > " 30 OpParmReset
> >
> > OpParmReset enables an Initiator or Target to request the operational
> > parameters to be reset to the values they had before the negotiation."
> >
> > I suggest that the definition be re-worded to state that the OpParmReset
> > enables an initiator or target to reset the operational parameters to
> > their DEFAULT VALUES. [instead of the current definition that states
> > that the parameters are reset to the values they had prior to the
> > current negotiation.]
> >
> > The current definition requires the initiator to maintain 2 sets of
> > operational parameter values, the current and the previous. In the case
> > where initiator is just booting up, if the target sets OpParmReset to
> > "yes", the initiator does not know what to set the op params to, since
> > it has lost its prior state information.
> >
> > Comments ?
> >
> > Thanks,
> > Santosh
> >
> >  - santoshr.vcf