iSCSI: error recovery proposals from London

["Mallikarjun C." <cbm@rose.hp.com>]

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