Summary

  • RFC 1301 let an MTP master mark a message accepted after seeing its end marker and every intervening packet, then distribute accepted, pending or rejected status in a rolling twelve-message vector.
  • MTP ran above best-effort multicast, used transmit tokens, heartbeat, window, retention, NAKs and duplicate suppression, and normally received no positive acknowledgement from successful consumers.
  • accepted was a defined transport agreement, not proof that every consumer application parsed the bytes, authorized an operation, changed state or delivered an operational outcome.

The verdict rode with the next packet

RFC 1301 did not design reliability as a row of individual delivery receipts. It designed a continuing conversation in which new packets carried decisions about earlier messages. The message-acceptance record held a synchronization flag, a message sequence number, a packet sequence number and a compact two-bit status vector. Twelve positions described the preceding twelve messages. A process could learn that an earlier message had become accepted, remained pending or had been rejected while the group continued moving.

That is a clever use of scarce header space. It is also a warning to later historians. A value called accepted is meaningful only after its decision-maker, inputs and retention period are named. In MTP, the decision-maker was the master. It did not collect a signed success statement from every application. It observed the transport exchange and applied the protocol's rules.

The distinction does not make the state weak or false. Within RFC 1301, accepted was the authoritative transport result. The error begins when a collector silently changes the question. “What did the MTP master decide about this message?” is not the same as “What did every receiver application do with it?”

Best-effort multicast supplied the floor, not the guarantee

RFC 1112 defined IP multicast as sending one datagram to a host group whose membership could change. Its reliability was the same best effort offered to ordinary IP datagrams. The datagram was not guaranteed to arrive intact at every member, nor in the same order as its neighbours. A group address named a delivery set; it did not provide group agreement.

MTP attempted to build the missing transport machinery above that substrate. RFC 1301 called the collaborating set of processes a web. One process had to be the master. Other members were producer-consumers or pure consumers. The master instantiated the web, controlled membership and performance parameters, and allocated transmit tokens. A producer could not simply multicast ordinary client data whenever it wished; it first obtained a token carrying the next message sequence number.

The arrangement separated network replication from transport order. IP could distribute datagrams. The master serialized permission to produce messages, and the acceptance record made a common decision visible. Neither layer interpreted the application's data.

Successful consumers were normally silent

MTP was a negative-acknowledgement protocol. A consumer that detected missing data sent a NAK. A consumer that saw what it expected did not send a positive success indication to the producer. RFC 1301 explicitly used silence to reduce reverse traffic.

Silence therefore had protocol meaning, but it was conditional meaning. It meant that no recoverable gap had caused this consumer to issue a NAK within the relevant state and timing assumptions. It was not a durable statement that the consumer existed forever, that its application parsed the message, that a user saw it or that an external effect occurred.

This trade was central to multicast scaling. If every packet to a large group produced an acknowledgement from every receiver, reverse traffic could overwhelm the useful transmission. NAKs concentrated traffic on exceptions. The price was an evidentiary asymmetry: failure could become an explicit packet, while ordinary success was inferred from continued protocol behaviour.

Accepted meant the master saw a complete message

RFC 1301's rule was precise. If the master had seen data[eom] and every intervening packet, it marked the message accepted. If the message was incomplete but the master believed the sender remained operational and connected, it marked the message pending. If the message was incomplete and the sender appeared failed or partitioned away, it marked the message rejected.

Those states combined observation and judgement. Completeness at the master produced acceptance. Incompleteness plus a liveness belief produced pending or rejected. A packet trace from one member could show the published result without showing every observation that led the master to it. A later audit therefore needs both the decision and its provenance: what the master received, which end marker it associated with the sequence, and why it believed a producer was still connected or had disappeared.

The rule also reveals why accepted was not an application verdict. The master needed the bytes and their end marker. It did not need to understand those bytes. RFC 1301 described client data as uninterpreted. A perfectly accepted message could contain an invalid command, a duplicate business instruction, a stale document or data that the application deliberately ignored.

Twelve positions bounded memory and progress

The vector was a moving window. When a token for message m was sent, its first position described m − 1, its second m − 2, and so on. Older state eventually shifted out. RFC 1301 did not pretend this header was a permanent ledger.

It did, however, prevent unresolved state from being quietly erased. Only the master could change status, and it could not shift a pending message past the final vector position. If the oldest visible message was still pending, the master had to stop confirming new token requests until it could mark that message accepted or rejected.

That backpressure made uncertainty operational. The group could not maintain apparent progress by pushing an unresolved decision beyond its memory horizon. But once a final status moved out normally, the protocol header no longer carried it. An archive that stores only current vectors will eventually forget what the group once agreed. Durable history requires a separate record.

Message numbers were sixteen-bit values controlled by the master. Granting a token consumed a number, and the associated message eventually had to reach accepted or rejected. This established a protocol epoch and order; it did not create an immutable global identity for the application's act.

Token confirmation contained its own ambiguity

Control packets did not consume ordinary sequence numbers, so repeated token requests were not self-explanatory. If the master had granted a token but had not observed data under it, a repeated request might mean the producer missed the confirmation. Or the producer might have sent data that the master missed. A retry might even have passed the original confirmation in flight.

RFC 1301 made an explicit assumption: missing one unicast token confirmation was considered more likely than the master missing all packets of a deliberately multi-packet message. The master could reassign the pending token. A producer receiving a duplicate token confirmation treated it like a NAK and retransmitted data already sent under that message number. If it no longer needed the token, it returned it with empty[cancel].

This was not a defect hidden by the prose. It was a protocol response to ambiguous evidence. The retry carried a recovery instruction, not proof of which packet had been lost. A sound log keeps the request, each confirmation, the master's observation state and the retransmission separate instead of rewriting them into one certain story.

Heartbeat, window and retention priced recovery

Three shared parameters shaped the web. Heartbeat set the time rhythm. Window limited the number of new and retransmitted data packets a producer could multicast during one heartbeat. Retention set how many heartbeat intervals transmitted data and recovery state had to remain available.

When a producer lacked enough client data for a full packet but still owed activity, it sent empty[dally]. Short messages were padded with empty packets until they occupied at least the retention count. The purpose was to improve the chance that consumers observed at least one packet and could identify the producer. It was probability engineered through repetition, not a receipt from every destination.

A consumer could notice a gap in packet sequence numbers, or an unfinished fragment followed by more than a heartbeat of silence. It then sent a unicast NAK listing missing ranges. The producer multicast requested packets to the entire web, even if only one consumer had complained. Those retransmissions used part of the window and took priority over new data. Other consumers had to discard the resulting duplicates.

If the requested data had already left retention, the producer returned nak[deny]. The receiver reported failure to its client and could withdraw from the web. Recovery thus had a bounded evidence horizon: while data was retained, a gap could be repaired; after release, the protocol could only name the failure.

The Internet mapping added another boundary

MTP over IP required RFC 1112 Level 2 support for sending and receiving multicast. RFC 1301 assigned permanent host group 224.0.1.9. Because IP itself did not provide process ports, the specification inserted a bridge header with source port, destination port, length and optional checksum, carried under IP protocol number 92.

These identifiers located a transport instance. They did not authenticate a member. The memo's security section said security was not discussed. A TSAP, connection identifier, token or master role could support protocol routing and state without proving who controlled the process or whether it was authorized to act for an organisation.

A later review exposed the cost of concentrated control

RFC 1458 revisited MTP while considering large image-distribution workloads. It recognized the master, transmit-token rate control, selective NAK recovery and duplicate handling. It also pointed to external group-address and identifier dependencies, and to the delay and congestion created when almost all control traffic passed through the master. For that workload, the authors judged MTP inappropriate.

The review does not cancel RFC 1301's semantics. It shows that an agreement mechanism also has a control topology and a workload envelope. The same master that made order explicit could become a bottleneck. The same NAK economy that saved ordinary reverse traffic could multicast repair data to members that had not lost it.

Sources

These sources establish protocol definitions and a later design review. They establish no live MTP web, receiver population, authenticated member, application action, incident, adoption level or present deployment.