RE: iSCSI question

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Pat,

Thanks for your excellent description. I now fully understand the
issue.

However, I disagree that the text is clear on the difference between
error recover classes and error recovery levels. As a proof, look at figure 2, in section 5.15:

  +-------------------+--------------------------------------------+
  |ErrorRecoveryLevel |  Associated Error recovery capabilities    |
  +-------------------+--------------------------------------------+
  |        0          |  Session recovery class                    |
  |                   |  (Section 5.14.4 Session Recovery)         |
  +-------------------+--------------------------------------------+
  |        1          |  Digest failure recovery (See Note below.) |
  +-------------------+--------------------------------------------+
  |        2          |  Connection recovery class                 |
  |                   |  (Section 5.14.3 Connection Recovery)      | 
  +-------------------+--------------------------------------------+

In which, each recovery level is associated with only one recovery class.


Yours,
-Shahram

> -----Original Message-----
> From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
> Sent: Thursday, August 08, 2002 5:58 PM
> To: Shahram Davari; pkoning@equallogic.com
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI question
> 
> 
> Shahram,
> 
> There are two recovery heirarchies. You seem to be confusing 
> error recovery level with error recovery class.
> 
> One is the heirarchy for implementation requirements. With 3 
> forms of recovery, there are 8 possible combinations but to 
> simplify interoperability and to specify minimum acceptable 
> operation, we don't want to allow all eight. Session 
> qualifies two ways to be level 0 of this heirarchy - it is 
> simplest to implement and it should be able to recover from 
> any recoverable error. 
> 
> Note that these are the error recovery levels that are 
> described in 5.15. A sessions recovery level indicates the 
> set of recovery classes it is capable of using. The recovery 
> levels are defined such that a lower recovery level includes 
> a subset of the recovery classes available at a higher recovery level.
> 
> The other heirarchy is the order in which the available 
> classes are applied once an error occurs. This is the subject 
> of 5.14. The classes are disjoint. 
> 
> Once an error occurs, the device will choose an error 
> recovery class from the set of recovery classes in its 
> recovery level. If that recovery class fails, it may try the 
> next higher class.
> 
> Error recovery level 0 includes the Session recovery class.
> Error recovery level 1 includes the two classes useful for  
> Digest failure recovery (Within-Command and 
> Within-Connection) plus the Session recovery class from level 0.
> Error recovery level 2 includes  Connection recovery class 
> plus the classes included in level 1. 
> 
> I think the text already makes this clear and the pyramid 
> correctly represents this, but perhaps the chart below the 
> period could add "plus the capablilities of 
> ErrorRecoveryLevel n" to the boxes for Associated Error 
> recovery capablities for levels 1 and 2 ("n" = 0 and 1, respectively).
> 
> I hope this helps remove some of the confusion.
> 
> Pat
> 
> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Thursday, August 08, 2002 2:22 PM
> To: 'Paul Koning'
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI question
> 
> 
> Paul,
> 
> 
> > But that's not what "hierarchy" refers to here.
> > 
> > The hierarchy is one of increased capability, not increased
> > desperation.  Session recovery is the minimum required; the 
> additional
> > levels are optional capabilities in addition to the minimum.  Each
> > higher level in the hierarchy is a superset of the one below.
> 
> It all depends on the definition of these recovery classes.
> 
> 1) If they are defined in a superset/subset fashion, then I agree
> that level of complexity increases as: Session->PDU->connection.
> Then I suggest changing texts in other parts of the draft such as
> section 5.14 to indicate that if you have the capabilities of
> class X, then you don't need to escalate to lower classes, because
> class X already has those capabilities itself. Also I suggest
> changing the hierarchy figure as following:
> 
> 
>                              +
>                             / \
>                            / 2 \      
>                           +-----+
>                          /  1,2  \     
>                         +---------+
>                        /   0,1,2   \   
>                       +-------------+
> 
> 
> 2) If they are defined as disjoint classes, then the hierarchy for
> complexity makes no sense. Rather you need a hierarchy for escalation
> or transition.
> 
> 
> Based on the emails that I have received so far it seems that 
> the intent is the former definition.
> 
> Yours,
> -Shahram 
>