Summary

  • RFC 992 proposed that failure and recovery notices travel as ordered group multicasts, so surviving processes could attach the same membership view to the messages they received.
  • Its three primitives charged different prices for agreement: GBCAST ordered membership changes, ABCAST aligned shared operations, and CBCAST preserved cause and effect while leaving unrelated work free to run.

Imagine three copies of a queue. A client asks them to remove the first job. One computer crashes at almost the same instant. The survivors can probably continue. But suppose one copy sees the request before the crash notice while another sees the crash notice first. They have the same surviving hardware and two different stories about what happened. That is a particularly expensive form of resilience: the machines stay up long enough to disagree.

In November 1986, Kenneth Birman and Thomas Joseph at Cornell published RFC 992, a proposal born from their ISIS work on fault-tolerant process groups. The earlier RFC 966 and RFC 988 discussed host groups and multicast delivery. Birman and Joseph were staring at a nastier edge: group membership can change while a message is in flight. The message's meaning may depend on who was still in the group when it arrived. Their answer was to make the change itself an event that the group delivers in order.

The most ceremonial primitive was GBCAST. When a member recovered, it announced its return. When one failed, the system issued a group multicast on its behalf. That is the dark joke at the center of the design: the departed member gets a farewell speech, but somebody else has to deliver it. GBCAST ordered that speech against other multicasts. If a process received an ordinary message before the failure announcement, overlapping recipients would see the same order. A failed sender's earlier messages came before its own failure notice.

Each member kept a VIEW, its list of the group. The views did not flip at one magic universal instant. They advanced through the same sequence of membership changes, and processes receiving a particular multicast could agree about the view associated with it. The distinction matters. A distributed service cannot make every clock read the same moment; it can arrange for the participants to read the same chapter. The researchers also used this ordered mechanism for member rankings, checkpoints and process migration. A seating-chart update could carry operational consequences.

Putting every message through that ceremony would have made the group unbearably polite. The memo presented two cheaper tools. ABCAST gave multicasts with the same label the same delivery order at shared destinations. A replicated queue could use it for operations that must stay aligned. CBCAST kept causally related messages in order and let unrelated work proceed without a global procession. If one message could have informed the sender of another, their order mattered; two independent messages could take separate lanes. The system paid for the order the job required, rather than buying the strongest guarantee for every packet.

The proposal assumed fail-stop crashes and a monitoring mechanism that detected them. That assumption defined the problem it tackled. Its examples of workstation clocks and network transit were drawn from the mid-1980s laboratory, where the authors saw clock skew large enough to make timing a poor referee for many message races. Their paper reported a completed earlier ISIS prototype and work on a new implementation; the three-primitives design was a research architecture in motion. The historical achievement was the shape of the question: if a failure changes who may act, its announcement belongs inside the communication contract.

A crash is already disruptive. Letting every survivor invent its own order of events turns one failure into a committee of mutually incompatible eyewitnesses. RFC 992 gave that committee a shared minutes book. The dead computer still missed the meeting; at least its departure reached the agenda in the right place.