SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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 
    
    


Home

Last updated: Thu Aug 08 21:18:54 2002
11581 messages in chronological order