Re: iSCSI connection recovery

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

Simplifying the spec is one aspect.  The other issue is that 
there is a quite some overlap in the various sections.  As 
details have got added everywhere, the sections have expanded 
and now seem due for a "realignment". 

Someone with a fresh eye, who is reading this document for 
the first time, could be able to suggest a better format.

Let me, however, just point out a few things to illustrate :

1) Security issues :
   Described are Sec 4.2, Sec 9 and Appendix A 
   Section 9 is IETF-recommended (Security Considerations)
   but the other sections got added as details evolved.
2) Login processing:
   Described in Sec 1.2.3, Section 4, Section 2.10 and 2.11
3) Synch & Steering (hopefully gets absorbed into Framing draft)
   Described in Sec 1.2.9.2 as well as Sec 8.5
4) Error Handling 
   Sec 7.4, Sec 7.5  and Sec 7.11.1 seem to overlap at a 
   sentence level.  One must also correlate it with Appendix F.
5) Text negotiation
   Sec 7.7 talks of operational negotiation failures
   Sec 4.3 talks of operational negotiation
   Sec 2.8 and Sec 2.9 also describe negotiation details.

-Sandeep

Somesh Gupta wrote:
> 
> The victory of the dull, detail-oriented engineer over
> elegance :-) I would also prefer a very formal and
> fully specified 10 - 20 page document which leaves no
> ambiguity and no holes. But for that we would have to
> simplify the spec a lot.
> 
> regards,
> Somesh
> 
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Julian Satran
> > Sent: Monday, July 30, 2001 11:34 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI connection recovery
> >
> >
> >
> > 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
> > > > > >
> > > > > >
> > > > > >
> >
> >
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com