Re: iSCSI connection recovery

["Julian Satran" <Julian_Satran@il.ibm.com>]

Sandeep,

There is nothing to stop them sending the state but there is no way for the
initiator to acknowledge those (Logout takes it out of the full feature
phase - nothing valid after) and a new connection is a new day ...

I assume you are not suggesting a FinalLogout ;-), are you?

Regards,
Julo

Sandeep Joshi <sandeepj@research.bell-labs.com> on 30-07-2001 18:38:48

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Re: iSCSI connection recovery





Julian

Wait..!  I was proposing that the expStatSN could be used to send back
the responses (even *before* commands get retried)   See below

-Sandeep

Julian Satran wrote:
>
> Sandeep,
>
> Both Login (with the X bit it is a logout/login) and Logout have an
> ExpStatSN just for this reason.
> If this does not come through clear in the text please let me know.
>
> Regards,
> Julo
>
> Sandeep Joshi <sandeepj@research.bell-labs.com> on 30-07-2001 17:33:49
>
> Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI connection recovery
>
> Julian,
>
> The explanation helps.  Now that the model is clear, let me
> ask if something like this would work..
>
> It seems possible for the target to send back SCSI responses
> during recovery logout, even before commands are retried.
> The recovery logout could act as a final (& appetizing) SNACK.
>
> Since the target still has a statSN index on the responses,
> it could use the expStatSN field in the Logout Command
> and send all responses from [expStatSN-endStatSN].
>
> Initiator            Target
> ---------            ---------
> Logout (for recovery) ---->>
>    <<--- SCSI Data+Responses from [expStatSN-endStatSN]
>    <<--- Logout Response
>
> Once the logout occurs, the statSN ranges for the CID are
> lost and command retry cannot be avoided.
>
> This logout optimization has larger benefits for Writes.
> Retrying Write Commands (e.g. tape backup) may involve
> sending all the data (or minimally FirstBurst) all over
> again!   Of course, cost-benefit depends on queue lengths,
> bandwidth, frequency of connection recovery, transfer
> sizes, ULP timeouts, etc.
>
> Comments ?
>
> -Sandeep
>
> Julian Satran wrote:
> >
> > Sandeep,
> >
> > Your status cache is made of some task  related structures.  You can
> reuse
> > those - just link them to a new connection.
> > As for StatSN - you can't reuse those as each connection establishes
its
> > own (new) StatSN at login (even if reusing the old CID).
> >
> > Regardless of what CID the connection bears - it is a new connection
and
> > you can issue new commands. Even for the old ones by reissuing you in
> fact
> > indicate the new allegiance (the logout suspended them and the retry
> > establishes the new allegiance).
> >
> > sandeepj@research.bell-labs.com (Sandeep Joshi) on 29-07-2001 01:01:54
> >
> > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  Re: iSCSI connection recovery
> >
> > Er..I mixed up the terminology.  By "same connection", I meant
> > "same CID" - so one could retry cmds ONLY on the new TCP connection
> > with the same CID, after the old TCP connection had failed.
> > This avoids having to change connection allegiance on
> > the stuck commands, as part of connection logout.
> >
> > The main questions, however, were these :
> >
> > 1) What is the effect of a CID logout on the status (statSN)
> >    cache ?  Can it be reused when the commands are retried ?
> >    (Think not..)
> >
> > 2) After one does a login for recovery using an old CID,
> >    can new SCSI commands be issued on that new TCP connection.
> >    (though it bears an old CID identifier)
> >
> > -Sandeep
> >
> > > Sandeep,
> > >
> > > Retry over any connection was always the case.
> > > Commands can change allegiance only after a logout.
> > > The commands get quiesced anyway and you have to mark them ready for
a
> > > retry anyhow (you don't want retry at arbitrary times to hit
unpunished
> > the
> > > target). After that it doesn't matter where you retry (same
connection,
> > > another old one, a new one).
> > >
> > > The only new thing is command replay (after status was sent but
before
> it
> > > is acked).
> > >
> > > Regards,
> > > Julo
> > >
> > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 28-07-2001
06:37:33
> > >
> > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)
> > >
> > > To:   ips@ece.cmu.edu
> > > cc:
> > > Subject:  iSCSI connection recovery
> > >
> > >
> > >
> > >
> > > I had a "big-picture" question about the connection
> > > recovery model.
> > >
> > > The current draft suggests that, once the broken connection
> > > is logged out, the commands allegiant to the old connection
> > > can now be retried over *any* connection. (See Section 7.11.3
> > > bullet 1 and also Appendix F Session Recovery algo for
> > > initiator.)
> > >
> > > I may be mistaken, but in previous drafts, this was not
> > > the case and commands always stayed allegiant to a CID.
> > >
> > > So the question is.. how does one use a Status cache
> > > belonging to the old connection in this new model (now that
> > > the commands are going to be retried over any connection)
> > > Doesnt this become more complex ?
> > >
> > > Secondly, this also means that one must walk the command
> > > list at the target and quiesce connection allegiance during
> > > logout - which may not be required if the commands were to be
> > > retried over the same connection always.
> > >
> > > Comments  ?
> > >
> > > -Sandeep
> > >
> > >
> > >