Re: iSCSI connection recovery

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

Sandeep,

Don't blame me for size.  I would prefer the spec to be 10-20 pages and
have a formal spec.
The past of this list has clearly shown that more text helps at least to
gain consensus :-)

Regards,
Julo

Sandeep Joshi <sandeepj@research.bell-labs.com> on 30-07-2001 21:03:04

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

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI connection recovery





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

No I was not :-)  I missed reading the 4th paragraph of
Section 2.14 which alludes to this logout processing.
The spec is getting monstrous at 185 pages.

regards,
-Sandeep


Julian Satran wrote:
>
> 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
> > > >
> > > >
> > > >