XXXX REFEREE EVALUATION FORM
      (Please return within approximately six weeks.)

Please  see  ``Information  for Referees''  below.  Fill out
this  form,  including  detailed  comments to the  author(s)
and email  the completed form  to the Subject Area Editor at
xxxxxxxxxxxxxxxxxxxxx


Paper Number: xxxxxxx      Referee: B      Date Sent to Referee: xxxxxxxxxxxxx

Paper Title: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Author(s): xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Subject Area Editor: xxxxxxxxxxxxxxxxx           Return Review By: xxxxxxxxxxxx


Please Rate the Paper in each category (mark your choice with an "X")

                          Excellent    Good     Fair    Poor

Originality:                 ___       ___      _X_     ___

Technical soundness:         ___       _X_      ___     ___

Written organization:        ___       _X_      ___     ___

Overall rating:              ___       ___      _X_     ___



Recommendation (mark your choice with an "X")

                                              Regular Paper   Research Note
     
1. Accept with minor revisions                     ___             ___

2. Needs a major revision and re-evaluation        _X_             ___

3. Reject as it is for publication in xxxx         ___             ___



Comments to the Author to explain ratings and recommendation: (enter below)

Presents a communication-induced checkpoint (CIC) protocol in a stepwise 
fashion.

The paper should not be accepted as it is. It lacks an adequate discussion of 
relevant work. The protocols against which they compare their work are not CIC
protocols. It's impossible to evaluate their contribution without going back
and reading all of the work that the authors did not cite. Examples include:

  R. Baldoni et. al. A communication-induced checkpointing protocol
  that ensures rollback-dependency trackability. FTCS 1997. (they cite,
  but not in Section 8.3)

  J-M Helary et. al. Preventing useless checkpoints in distributed 
  computations. SRDS 97.

  D. Briatico et. al. A distributed domino-effect free recovery
  algorithm. IEEE International Symposium on Reliability, Distributed
  Software, and Databases	December 1984.

  R. Baldoni et. al. A VP_accordant checkpointing protocol preventing
  useless checkpoints. SRDS 1998.

In addition, I am somewhat suspicious of CIC protocols. They do indeed
allow independent checkpointing and than no checkpoints are useless,
but it seems that they would also force many checkpoints. After all,
it's a kind of "lazy" coordinated checkpoint protocol. As long as
there is no communication among a set of processes, then the
independent checkpoints would be usable, but how often does this
occur? A recent paper I've seen says that for realistic applications
"not very often":

  L. Alvisi et. al. An analysis of communication-induced checkpointing.
  FTCS 99.

The latter is not enough for me to recommend that the paper be
rejected, since CIC are interesting as an intellectual exercise. But,
if they are comparing performance values, they should at least mention
that there are some performance issues that they don't address and
compare their protocol with other CIC protocols. Hence, a major
rewrite is warranted.

Individual points:

1) Page 2, sentence before "Paper Objectives". Can you give a citation
on the performance of optimistic message logging versus pessimistic?
And, I think that if you are going down this path, you should also
mention the class of causal message logging protocols as well.

2) Page 3, system model: How important is it that "All failures are
detected immediately?" Can there be failure detection latency?

3) Page 4, Definition 1, this definition requires C to be an event as
well as a checkpoint.

4) Page 4, Definition 2, "the same or later checkpoint interval" is
not defined at this point.

5) Page 5, line -10: "... is picked from a local counter..." This is
unusual wording. Even after reading the entire paper I don't
understand what you mean by "picked".

6) Page 6, line 1: "When it is time for a process to take a
checkpoint", you should make it clear that this holds for both basic
and forced checkpoints.

7) Page 6, line 8, "would help" and line 10 "basically" are waffle
words. Can you clarify this text?

8) Page 7, line 12 (immediately above the figure): "the receiving
process to take" should be "receiving process take".

9) Page 10, Figure 2 is wrong. It appears to be identical with Figure
3, and the text seems to go with another figure.

10) Page 11, Delayed Messages: I could not figure out the difference
between lost and delayed messages from this text. Later on it became
clear. Can you rewrite this definition so that it stands by itself?

11) Page 11, Duplicate Messages: You've not yet defined (even
obliquely) what a message log is and why messages would be replayed
from it.

12) Page 11, last line, second word "the" should be deleted.

13) page 12, last line, last words "assigns the concatenation..." is
an awkward sentence and should be rewritten.

14) Page 13, discussion on duplicate messages: You seem to be
implicitly assuming lossless channels. Otherwise, duplicate messages
can arise by having the crashed process taken a checkpoint before an
acknowledgement is finally delivered at the sending process.

15) Page 14, line 13: "came" should be "comes". In the next line,
"would have rolled" should be "will roll".

16) Page 18, Section 6.1: Your way of representing a pair is an
implementation detail. Why don't you just represent it as a pair and
note in a footnote that such a pair can easily be encoded as a single
integer?