Re: iSCSI: error recovery proposals from London

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

Needless to say up-front that I am strongly in favor of this recovery
hierachy.

The only point I would like to make is that I would like to reduce the
implementation options to 2 (or maximum 3) levels by
combining the levels in a reasonable view.

By this we could simplify testing and interoperability.

The levels would be:

0 - session recovery
1 - your current level 4

I would also suggest reexamining the introduction of a data-ack (using the
F bit of the input sequences) and a special form of SNACK for ACK to limit
the resources a tape target will have to dedicate to recovery.

Julo

"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 16-08-2001 04:10:17

Please respond to cbm@rose.hp.com

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: error recovery proposals from London



All:

During the just concluded IETF-51 in London, I made a presentation
on error recovery status in iSCSI and made certain specific proposals
on behalf of Julian Satran, Randy Haagens and myself.  This message
is intended to give an overview of the presentation, and to seek
WG consensus on these issues.

The slide set that I used for the presentation is on Julian's website
at:
       http://www.haifa.il.ibm.com/satran/ips/iscsi_errsimpl_london.pdf

The first few slides summarize the challenges of error recovery design
in iSCSI and outline the current (as of rev07) philosophy of iSCSI to
address these challenges.

The three specific proposals that I presented are -

1. Continued definition of SNACK:  Though continuing to define SNACK in
   iSCSI does not involve any changes to the draft, I thought it is fair
   to bring up this issue since there had been much debate about the
   need for SNACK in this forum and ERT.

   The slides present the pros and cons of SNACK (essentially the reasoning
   for the current support of SNACK).  While the negative aspects of SNACK
   are presented with possible options to address those, the slide set
   points out the solid positive aspects of SNACK.  In particular,
following
   are the factors that swayed the decision in favor of SNACK.

            a)There has been a disproportionate amount of focus on the
              data recovery capability of SNACK, but a much more important
              aspect of SNACK is the ability to recover statuses (thus
              StatSNs), in turn preventing connection failures due to
              status sequence holes.

            b)Philosophically, the draft supports the notion of
              "retransmission" of PDUs by defining transparent failover
              of commands to different connections.  SNACK merely makes
              this implicit allowance for retransmission into an explicit
              statement.  Remember, neither SNACK nor command failover
              is mandatory.

            c)Partial I/O recovery has been considered a requirement for
              tape devices in the FC world.  SNACK satisfies this
requirement.
              (Two tape experts present in the WG meeting strongly
supported
               this reasoning.)

There was a strong consensus in the meeting to continue defining SNACK.

2. Need for a hierarchy: The proposal here was to define the error recovery
   capabilities as a hierarchy of recovery levels, with each layer being a
   superset of the capabilities of the level below.  This has the benefit
of
   significantly decreasing the test matrix, and requires only incremental
   capabilities for increasingly sophisticated implementations.

There was a strong consensus in the meeting to define an iSCSI error
recovery hierarchy.

3. Proposed hierarchy: This proposal outlines a specific hierarchy of
   recovery levels.  The features of this are -

        - Four optional error recovery levels.
               *Level1:Within-connection recovery
               *Level2:Within-command recovery
               *Level3:Connection recovery
               *Level4:Command replay
        - One mandatory recovery level
               *Level0:Session recovery
   Following are the incremental book- keeping & resource requirements
   with going up each level.

   Recovery Level transition         Incremental requirement
    0 -> 1                      Atmost one PDU retransmission per task.
    1 -> 2                      Retransmit possibilities include data PDUs.
    2 -> 3                      Retransmission across connections.
    3 -> 4                      Replaying the entire command.

The consensus call on this one was deferred in London, in favor of taking
it to the reflector to solicit more comments.

   Let me add one comment here - the proposed hierarchy is based on what
   I called as the "incremental aspirations" (please refer to slide 13)
   of increasingly sophisticated implementations.  There are different
   ways of approaching this layering (for ex., it is *not* SNACK-centric -
   ordering layers based on their reliance on SNACK).  In the presenters'
   opinion, the proposed approach was deemed the most reasonable.


Your comments are welcome.
--
Mallikarjun


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668   Hewlett-Packard, Roseville.
cbm@rose.hp.com