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




    it is alredy in - julo


    pat_thaler@agilent.com
    Sent by: owner-ips@ece.cmu.edu

    08/09/2002 08:10 PM

           
            To:        Shahram_Davari@pmc-sierra.com, pat_thaler@agilent.com, pkoning@equallogic.com
            cc:        ips@ece.cmu.edu
            Subject:        RE: iSCSI question

           


    Shaharam,

    I agree that the table by itself is not clear, but that the text of the section clearly states things. That is why I suggested a change to that table:

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

    Pat


    -----Original Message-----
    From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
    Sent: Friday, August 09, 2002 6:48 AM
    To: 'pat_thaler@agilent.com'; pkoning@equallogic.com
    Cc: ips@ece.cmu.edu
    Subject: RE: iSCSI question


    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
    >




Home

Last updated: Fri Aug 09 18:18:55 2002
11598 messages in chronological order