Summary

  • RFC 2357 did not select one reliable-multicast transport. It defined how IETF Transport Area reviewers would distinguish an experiment worth publishing from a mechanism safe enough to support on the Standards Track.
  • The danger was structural: one flow could cover a global tree, continue without a human watching until every receiver finished, and provoke ACK, NACK or status traffic whose repair effects reached far beyond one failed endpoint.
  • Analysis, simulations, trials, congestion control, failure containment and security were separate receipts. Publication remained evidence of review at a stated maturity, not proof of deployment or Internet-wide safety.

The efficient copy had an expensive shadow

In June 1998, reliable multicast appeared to offer a compelling bargain. Collaborative workspaces, software distribution and bulk data transfer could avoid sending an identical unicast stream to every participant. One source could inject a packet once; a multicast tree could reproduce it where paths diverged.

RFC 2357 began with the demand, then refused to treat efficiency as the conclusion. It was an Informational memo by Allison Mankin, Allyn Romanow, Scott Bradner and Vern Paxson, working with the Transport Area Directorate. It specified no reliable-multicast protocol and no Internet Standard. Its subject was the review procedure for proposals that wanted to become RFCs.

That procedural focus carried a technical judgment. Multicast amplified useful data, but it could also amplify bad control. A single flow might span a large global tree. File transfers would often run between unattended computers, without a listener leaving when quality became intolerable. A transfer could continue until all intended receivers obtained all data, so the flow had no natural duration comparable to a conversation or broadcast programme.

Reliability added return traffic. Receivers might send acknowledgements, negative acknowledgements or status reports. Loss could prompt repair. At scale, an apparently small receiver-side rule could create a feedback implosion or cause one request to trigger a retransmission toward a large group.

The memo called the possible result a congestion disaster. That was not a record that such a disaster had occurred. It was a reason to demand evidence before giving a protocol a status likely to encourage broad use.

Reliability was not one service

The easiest administrative answer would have been to choose one transport and make every application fit it. RFC 2357 explained why that shortcut was unsound.

Some applications needed total ordering; others did not. Some had one sender, some many. A receiver might fetch interchangeable data from replicated sources or depend on one source of truth. Membership could be small and fixed or dynamic and very large. Interactive tools cared about delay and might accept incomplete delivery; software distribution could prefer completion and tolerate waiting. Bandwidth patterns ranged from bursts to sustained bulk transfer.

The word reliable therefore did not identify one invariant. It named a family of application promises. The shared layer still needed protections—especially a credible response to congestion—but the completion semantics could remain local to the application.

This distinction mirrors the minimum-common-layer principle in Lu Heng’s writing. A common specification should carry what participants need to coexist and verify, not every future policy or product decision. For reliable multicast, congestion restraint, bounded feedback and defined failure behaviour belonged in the common burden. Whether an application required total order or partial completion did not have to be settled by one universal interface.

Publication became a bounded gate

RFC 2357 turned that burden into a status decision. If a Standards Track submission failed the criteria, the Transport Area Directors could decline support; that was enough to stop Standards Track publication. An Experimental or Informational document was treated differently. At minimum, reviewers could recommend publication with an IESG note saying the proposal did not meet the criteria.

The distinction matters. A useful experiment could remain visible without being mistaken for a mature shared rule. When the criteria were met, the default publication status for reliable-multicast proposals was still Experimental. The process preserved room for implementation and learning while refusing to convert novelty directly into standardisation.

The memo compared this arrangement with RFC 1264. In 1991, limited operational experience with dynamic routing protocols had led the IETF to require implementation, analysis and evidence before advancing them. The analogy was not that multicast transport and routing were identical. It was that a protocol capable of imposing wide costs justified a review burden greater than elegance on paper.

RFC 2026 supplied the surrounding standards vocabulary. Standards Track, Experimental and Informational were different publication claims. RFC 2357 made those labels carry a particularly explicit safety meaning in its domain.

The criteria asked where the damage stopped

For Standards Track consideration, a proposal had to do more than describe packet formats. The review asked for analysis, simulations or trials, and for evidence at a scale relevant to the claims. It asked how congestion was detected and how senders reduced load; how the protocol interacted with competing traffic; what happened when members, paths or control messages failed; and whether harmful behaviour remained contained.

The TCP algorithms recorded in RFC 2001 were the contemporary reference point because TCP’s response to loss helped prevent congestion collapse. But RFC 2357 did not say multicast must reproduce TCP exactly. The harder question was coexistence: would the proposal respond to scarcity in a way that did not transfer its completion objective onto every other flow?

Security was part of that question, not an appendix. A receiver’s repair request could be valuable evidence that data was missing. It could also be forged or manipulated. If the protocol did not inherently limit retransmission requests, the memo required cryptographically strong signing or placed a heavy burden on the proposer to demonstrate another adequate defence. Authenticity alone would still not prove current membership, sensible rate, correct request scope or safe group-wide effect. Those remained distinct controls.

The memo also said two earlier reliable-multicast RFCs, RFC 1301 and RFC 1458, should be deprecated because they had been published before the congestion impact was adequately appreciated. It did not document that either had caused a collapse. The recommendation demonstrated a narrower point: an RFC number was not permanent certification. Later understanding could reduce the weight of an earlier publication.

A trial was a receipt, not a passport

Running-Code Primacy gives the process its strongest modern reading. A specification states what a mechanism is meant to do. A working implementation shows that one set of code can do something under observed conditions. A simulation exposes behaviour inside its model. A trial records a topology, workload, receiver population, failure pattern and measurement method.

None of those receipts should be enlarged silently.

A small trial cannot prove global scale. A model cannot prove that production implementations share its assumptions. One receiver’s completed file does not prove every receiver completed. A signed NACK does not prove that the sender should retransmit to the whole group. An Experimental RFC does not prove deployment. A Standards Track RFC does not prove universal adoption or flawless operation.

RFC 2357’s review regime was therefore not a central command over networks. It bounded one decision: what claim the IETF would attach to publication. Operators and implementers still decided whether to build, deploy and trust a mechanism. Reviewers could demand that the proposal explain its externalities before lending it a stronger status.

This is why the memo belongs in Internet history even though it did not crown a protocol. It identified a governance surface that was genuinely technical. When one application’s completion strategy could consume a shared resource across a global tree, evidence about containment was not a private implementation detail. It was part of interoperability.

Sources and limits

The publication facts, review procedure and criteria come from the RFC Editor record for RFC 2357 and the full RFC 2357 text. The status vocabulary comes from RFC 2026; the earlier evidence-review analogy from RFC 1264; and the contemporary TCP congestion-control reference from RFC 2001. The two documents RFC 2357 recommended deprecating are RFC 1301 and RFC 1458. The separation among specification, implementation and observed outcome follows Lu Heng’s essays on Running-Code Primacy, Minimum Initial Specification and Reality Layers. These sources do not establish present deployment share, a documented collapse caused by either deprecated RFC, or universal safety of any later reliable-multicast protocol.