Subject: Re: iscsi : OpParmreset

From: "Julian Satran" <[email-masked]>
Date: Thu, 27 Sep 2001 21:01:48 +0300

Mallikarjun,

What you are suggesting is:

abort for the initiator

reject for the target.

It is feasible but not nice.

Let me think if we can have a better alternative.

07-98 still has OpParmReset.

Julo

                    "Mallikarjun                                                                 
                    C."                  To:     ips <[email-masked]>                           
                    <[email-masked]       cc:                                                     
                    om>                  Subject:     Re: iscsi : OpParmreset                    
                    Sent by:                                                                     
                    owner-ips@ece.                                                               
                    cmu.edu                                                                      

                    27-09-01 19:10                                                               
                    Please respond                                                               
                    to cbm                                                                       

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.
[email-masked]

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 <[email-masked]>
>                     <[email-masked]       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.
> [email-masked]
>
> 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        [email-masked]
> >                     m,ex2)"                cc:
> >                     <matthew_burbrid       Subject:     RE: iscsi :
> OpParmreset
> >                     [email-masked]>
> >                     Sent by:
> >                     [email-masked]
> >                     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:[email-masked]]
> > Sent: Friday, September 21, 2001 4:34 PM
> > To: [email-masked]
> > 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
> > <[email-masked]>
> >                     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

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 28 Sep 2001 20:06:06 -0700

Julian,

Thanks for incorporating the suggestion in 07-99
as the change log indicates.

However, I see that my option (b) for the initiator
is still allowed (empty text command abort)in 3.11.3.
Is there an unrelated reason for that?

Thanks.
-- 
Mallikarjun 

Mallikarjun Chadalapaka