Re: iSCSI connection recovery

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

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
> >
> >
> >