Summary

  • RFC 3018 exposed a distributed 128-bit memory space through remote read, write, allocation, object and control-transfer instructions; a transaction could require its buffered instructions to execute together or not at all.
  • The same RFC expressly supplied no cancellation after execution and named control transfer as an effect that could be impossible to undo. Complete transfer and atomic release therefore did not prove reversibility, security or the intended application result.

The transaction waited on the far machine. Its instructions were complete. A final command could release all of them together; another could delete them before they ran.

That sounds like a clean decision boundary. Before release, the bundle could disappear. After release, every instruction belonged to one atomic act.

Then one instruction transferred control to code on a remote node.

RFC 3018 was unusually candid about what happened next. It supplied no cancellation after execution. If reversal was needed, the virtual machine had to implement it, because a transaction could contain operations—control transfer was the example—that were impossible to cancel.

The distinction is the most durable part of a remarkable Experimental RFC. Published in December 2000, the Unified Memory Space Protocol Specification proposed something more ambitious than remote procedure calls. It gave an application a 128-bit address space spanning Internet nodes and let a virtual machine turn memory and control instructions into network commands. A thread could read or write remote memory. It could allocate or free storage, move code, call an object procedure or jump to a remote address that created a new thread there.

The network had not vanished. It had been hidden inside an instruction set.

One address space concealed several owners

UMSP divided computation into jobs, tasks and threads. A job represented the distributed application. Each node held at most one task for that job, and a task could contain several control threads. A Job Control Point, or JCP, centrally tracked the job's tasks and assigned control identifiers.

The address looked unified, but authority was not. The JCP controlled job coordination. Each node controlled its local memory. The virtual machine managed memory, pointers and execution order. The transport carried instructions between nodes. User code initiated operations whose effects could occur elsewhere.

RFC 3018 repeatedly preserved these divisions. The protocol did not control local job memory. It did not trace user control threads. The VM had to invalidate pointers when tasks ended. A continuous code segment could not span nodes, even though a control transfer could create a new remote thread.

This is a useful warning against taking the metaphor literally. A sixteen-octet pointer could name a distant location, but it did not make distant memory behave like a local register under one clock, one failure domain or one recovery authority. The address joined namespaces. It did not merge custody.

The operations made that governance problem concrete. UMSP included immediate reads and writes, memory allocation and release, comparisons, synchronization, JUMP, CALL, object creation and deletion, and execution of object procedures. A mistake was not merely a malformed message. It could be a mutation, a resource allocation or a new locus of control on another machine.

The chain had three moments, not one

RFC 3018 defined several kinds of instruction chain. A sequence joined dependent operations: the next could execute only after the previous one, and failure cancelled the remaining instructions. A transaction could join instructions that were not otherwise related. All had to execute at once or none could execute.

The transaction still moved through distinct states.

First came transfer. Its length had to be known in advance because the receiver might need to buffer the entire bundle. _BEGIN_TR described how the transaction should behave, and _END_CHAIN marked its final instruction.

Second came readiness. If TRR was set, completion of the transfer caused immediate execution. If it was clear, the receiver held the transaction until a separate EXEC_TR arrived. Before execution, CANCEL_TR could discard the stored instructions without restoration.

Third came execution. TRE could even require a complete but still unexecuted transaction to run when its lifetime expired or its session ended abnormally. A flag intended to prevent indefinite uncertainty could therefore change a network failure into an execution trigger. The lifetime clock began only after all instructions had arrived; a zero value imposed no limit.

These controls answered precise questions: Is the bundle complete? Should it wait? Which chain should be released? When should an unexecuted chain expire? They did not collapse into a single “committed” bit.

A useful audit would retain at least four receipts: the digest and identity of the complete transaction, the receiver's buffered-ready state, the release or cancel decision, and the observed results of every consequential instruction. Without them, an operator facing a broken session could not tell whether the bytes were partial, the bundle was complete but waiting, an expiry rule released it, or execution began before the link failed.

Atomic execution was not compensation

The word transaction invites database assumptions that the RFC did not make. RFC 3018 required its instructions to execute all at once or not execute. It did not promise that an already executed world could be restored.

The document states the boundary directly: transaction cancellation after execution is not stipulated. A compensating mechanism, if needed, belongs at the VM layer. The reason is not a missing opcode. Some operations cannot be cancelled. A remote CALL may create another effect. A JUMP can create a new thread of control. A write may be observed by code that is not part of the original transaction. A FREE may invalidate a pointer held elsewhere. An object procedure can do work whose inverse is neither known nor safe.

Even a perfectly atomic bundle can therefore be operationally irreversible.

Suppose a transaction allocates memory, installs code and transfers control to it. All three instructions might enter execution together. If the new thread sends a message, actuates a device or mutates state outside the job's reversible domain, deleting the original instruction chain afterwards would not recall the effect. The protocol's atomicity governs admission to execution. It is not a time machine.

This is why the release receipt and the outcome receipt must remain separate. EXEC_TR proves that a command to execute a named chain was transmitted under the protocol. It does not by itself prove which VM actions completed, what downstream code did, whether the job reached its goal or whether compensation later succeeded.

The RFC's honesty here is more valuable than a broader, ambiguous promise would have been.

Reliable transport could not close the evidence gap

UMSP required TCP availability for reliable exchange and allowed UDP for data that did not require acknowledgement. It also described properties that an alternative transport would need, including delivery reporting, duplicate avoidance and identification of segments after emergency restart.

TCP solves a real problem. RFC 793 gives applications a reliable ordered octet stream and recovers from damaged, lost, duplicated or disordered segments. That means a UMSP implementation need not reinvent delivery of every byte carried over a live connection.

But transport acknowledgement is not a virtual-machine receipt. TCP can show that the receiving TCP accepted octets. It cannot say that an instruction passed UMSP validation, entered the right transaction, survived a node reload, was released by the intended authority, ran against the expected memory, or produced the application result the caller wanted.

The adjacent ONC RPC specification, RFC 1831, makes the uncertainty concrete. With TCP, a reply can support an inference that a procedure ran exactly once under that model. Without a reply, the caller cannot assume it did not run. A server may have executed the request before the connection failed. ONC RPC also warns that remote calls differ from local calls in failure handling, side effects, performance and authentication.

UMSP went further by presenting control transfer and remote memory access as instructions. That made the local illusion stronger, not the failure semantics simpler.

The job controller coordinated identity, not omniscience

The JCP gave a distributed job a center. It assigned the global job identifier, tracked task creation and completion, and could serve as a place for centralized user identification and attack protection.

Centrality can make records easier to correlate. It does not automatically make them complete.

A JCP could know that a task registered, a session opened or a job reported completion. The VM still controlled memory and pointers. A remote thread could produce effects outside the controller's direct observation. A transport could fail after execution but before a response. A node could reload while old session segments remained a concern. The controller therefore needed evidence from each layer rather than authority borrowed from its position in the diagram.

The distinction matters for completion. “All tasks ended” is a job-lifecycle fact. It is not proof that every intended write persisted, every object procedure produced the correct result, every externally visible effect occurred once, or every leaked capability was revoked.

Security was deliberately outside the initial mechanism

RFC 3018's security section begins by saying that safety questions were not included in the document in order to reduce initial protocol complexity. The section's proposals were recommendations for future expansion.

That admission must travel with any account of the protocol. UMSP could expose remote write, allocation, active code and control transfer. The initial specification did not define a complete security construction for those powers.

It suggested using protection available in TCP/IP, placing integrity or encryption algorithms in specially processed chains, and sending authentication parameters in extension headers. It proposed authentication relationships among the communicating nodes and the JCP. For man-in-the-middle detection, it described a topology in which paths among those parties did not overlap—and acknowledged that a common gateway weakened the scheme.

The document also identified JUMP and CALL as denial-of-service risks whose resource control belonged to the VM. It recognized that downloading active code to a client exposed the client, while executing client code on a server increased the server's protection burden.

Those observations identify the danger surface; they do not instantiate keys, algorithms, identities, authorization policy, replay defense, revocation or audit.

RFC 3552, published later, provides a useful retrospective contrast. Its Internet threat model assumes an attacker may read, remove, change or inject traffic on the communications channel. That later guidance should not be projected backwards as a rule RFC 3018 was obliged to have followed. It does show why route separation and unspecified extension headers cannot be treated as a finished security receipt.

Experimental meant archival proposal, not deployed fact

RFC 3018 was published as Experimental. RFC 2026 places Experimental documents off the standards track and says they are not Internet Standards. Such a document may preserve research or development work for the technical community.

That status is not a verdict that the ideas were foolish, nor proof that they were implemented. The sources reviewed here establish the design, its explicit boundaries and its relationship to TCP, UDP and RPC. They do not establish a UMSP product, deployment, interoperability event, outage, adoption rate or operational success.

The document is historically useful precisely because it makes an ambitious abstraction legible. It tried to let application code ignore the network and use 128-bit instructions instead. In doing so, it exposed the receipts that the abstraction could not erase.

The address could be unified while control remained distributed. The transaction could be atomic while its effects remained irreversible. The bytes could arrive while execution remained uncertain. A job could finish while its intended real-world outcome remained unobserved.

Lu Heng's Running-Code Primacy supplies an analytical lens for that sequence: a protocol statement becomes operational fact only through running systems and observable effects. Reality Layers keeps the encoded instruction, buffered chain, release, execution and result from borrowing one another's authority. Minimum Initial Specification explains why a thin experimental core can leave choices open, but also why security, compensation and observation must be named as missing contracts rather than inferred from the word “transaction.”

These are later lenses, not claims about the RFC author's motives.

The transaction was real. Its boundary was simply narrower than the world it could change.

Sources