When a Successful ESRO Result Still Ends in Failure

Summary

• RFC 2188’s acknowledged-result mode deliberately allowed a performer to report failure after sending a successful result even when the invoker may already have received and accepted that result. The two endpoints could therefore finish with different but individually honest evidence.
• ESRO separated invocation, execution, result construction, result delivery, acknowledgement and local confirmation. Invoke IDs correlated exchanges, but did not authenticate peers, make operations idempotent or prove durable business completion.
• The protocol’s two handshake modes traded information for overhead. Acknowledged results gave the performer peer-derived evidence through an ACK; non-acknowledged results ended locally without that knowledge.
• RFC 2188 was published in September 1997 as an Informational RFC, not an Internet Standard. Its status also recorded that it had not undergone IETF working-group review and carried an IESG concern about scalability.
• Its operational lesson remains narrow but important: a timeout, retransmission limit or local failure indication is evidence about a particular protocol observation, not a universal statement about what another endpoint executed, received, committed or later reconciled.

A success that ends as failure

Imagine the performer first.

It receives an invocation, carries out the requested operation and constructs a successful result. It sends that result toward the invoker. At the other end, the invoker receives it and treats the operation as successfully performed. From the invoker’s perspective, the exchange has delivered what it needed.

The performer is not yet necessarily entitled to the same conclusion.

In ESRO’s three-way acknowledged-result mode, the performer expects an ACK after sending the result or error. Its local RESULT.confirm or ERROR.confirm follows receipt of that ACK. If the acknowledgement never arrives, retransmission can continue until the configured limit is exhausted. The performer may then receive FAILURE.indication.

That sounds, at first glance, like a contradiction. How can the performer report failure if the operation actually succeeded?

Because the failure is not a retrospective verdict on the whole remote operation. It is a statement about what the performer-side protocol machinery could establish.

The result PDU might have been lost. Or the result might have arrived while the invoker’s ACK was lost on the return path. Or the local ESRO provider could have failed. Those cases produce different remote realities while presenting the performer with evidence that can collapse into the same local failure indication.

That distinction is the centre of RFC 2188.

A performer-side failure does not robustly prove that the invoker failed to receive a successful outcome. The RFC therefore suggests, among possible remedies, using a separate verification operation when the application needs to discover what happened.

The point is not that ESRO was careless about state. It is almost the reverse. Its specification is valuable because it is unusually explicit about whose state is known, at which stage, and on what evidence.

The protocol was designed to be small

RFC 2188 specified Efficient Short Remote Operations, or ESRO, as a low-overhead protocol for reliable connectionless remote operations over UDP. The design paid particular attention to links where protocol overhead mattered, including wireless environments such as CDPD.

ESRO did more than send one request and one reply. It included facilities for segmentation and reassembly, concatenation and separation, and application multiplexing. It also provided two different result-handling modes rather than assuming every operation required the same confirmation semantics.

Its UDP service used port 259.

The protocol appeared in September 1997 as an Informational RFC. It was not an Internet Standard. The RFC’s status material said it had not received IETF working-group review, while the IESG attached a warning about scalability. Those details matter because they define the document being read: an explicitly documented protocol proposal and operational design, not a claim that the architecture represented universal Internet practice.

RFC 2524 later used ESRO as a basis for efficient mail submission and delivery. That later layering shows an intended application of the mechanism. It does not establish present-day deployment, commercial prevalence or universal operational success.

Invoker and performer do not occupy the same viewpoint

ESRO names two roles: the invoker and the performer.

That vocabulary does useful work. It stops a remote operation from being described as though a single observer watched it happen from nowhere in particular.

The invoker asks for an operation. The performer receives the request and attempts the operation. The performer may then report either successful performance through ESROS-RESULT or unsuccessful performance through ESROS-ERROR.

Those service primitives concern the performed operation. Subsequent confirmations and failures belong to another evidentiary layer.

This separation is easy to blur. A successful result says something about performer execution. Delivery of that result says something else. An invoker indication says that the invoker-side ESRO service has observed the corresponding protocol event. An ACK, in acknowledged mode, contributes still another fact: the performer has received peer-derived confirmation that reaches back from the invoker side.

None of those facts is identical to authentication, idempotency, durable application commit or later reconciliation.

RFC 2188 becomes clearer when the exchange is read as a sequence of evidence boundaries rather than as a single binary transaction:

1. an invocation request exists;
2. the invocation is delivered;
3. the performer executes or rejects the requested operation;
4. a result or error is constructed;
5. that result or error is delivered, or is not;
6. the invoker receives the corresponding indication;
7. in acknowledged mode, an ACK returns;
8. each endpoint produces its own local confirm or failure events;
9. authentication, if any, is handled outside ESRO;
10. the application decides how repeated requests are recognised;
11. durable business state, if relevant, is committed elsewhere;
12. discrepancies may later be reconciled.

A later layer may depend on an earlier one, but it is not proven merely because the earlier one occurred.

Three messages buy more knowledge

The acknowledged-result mode uses a three-way exchange.

The performer sends a result or error. The invoker receives it and sends an ACK. Once the performer receives that acknowledgement, it can generate RESULT.confirm or ERROR.confirm.

That last step gives the performer information derived from the peer.

The ACK does not authenticate the invoker. It does not demonstrate that some external database transaction is durable. It does not say a downstream physical action happened. It does not create exactly-once execution.

What it does is narrower: it changes what the performer can know about the protocol exchange.

The asymmetry becomes especially visible when packets disappear. Suppose the successful result reaches the invoker but the ACK does not make it back. The invoker can possess a success indication while the performer eventually runs out of retransmissions and records failure. The endpoints disagree only if their observations are mistakenly treated as declarations of one global state. At the protocol level, their local evidence is simply different.

RFC 2188 also identifies a directional implication in the other case. In acknowledged mode, an invoker-side failure implies performer failure as well. That still does not make the endpoints’ observations generally interchangeable. The specification defines particular relationships between particular events; it does not collapse the two endpoints into a shared oracle.

Two messages deliberately buy less

The non-acknowledged-result mode removes the third message.

Here, performer RESULT.confirm and ERROR.confirm are generated without information from the peer. Their meaning is therefore local. They mark the performer-side end of the operation; they do not establish that the invoker received the result or error.

The difference is architectural, not cosmetic.

In this mode, the protocol does not generate performer FAILURE.indication. There is no awaited ACK whose absence could support the same performer-side failure path. The performer can finish locally without learning the invoker’s receipt state.

The invoker can still fail. An invoker-side failure may mean that no result, error or failure arrived, or that a local invoker provider failure occurred.

Again, several possible histories can map onto the same local observation.

The two-way mode therefore does not make remote certainty cheaper. It chooses not to obtain some of that certainty.

That is exactly the kind of trade-off a low-overhead protocol might make. Saving a message is not merely saving bytes and delay; it also removes evidence that the omitted message could have supplied.

Correlation is not identity, and identity is not commitment

ESRO uses invoke IDs to correlate protocol activity.

That is useful, but correlation can attract capabilities it does not possess if its role is described too loosely.

An invoke ID does not authenticate a peer. RFC 2188 leaves authentication outside ESRO and assigns responsibility for performer authentication to mechanisms beyond the protocol itself.

Nor does an invoke ID make an operation idempotent. If a request causes an irreversible or non-repeatable side effect, identifying two messages as related does not by itself ensure that the side effect occurs once.

And an invoke ID does not prove business commit. A protocol can correlate an invocation and its result while an application still has its own persistence, authorisation and reconciliation rules.

The same discipline applies to parameter encoding. RFC 2188 can carry or tag information about encoding type, but the semantic definition of the parameters themselves is outside the protocol’s scope.

This boundary is important because encoding syntax and application meaning are different design layers. A protocol can successfully deliver an encoded parameter whose meaning is rejected by the application, or whose requested action is authorised differently, or whose eventual side effects require another consistency mechanism.

Reliability depends partly on deployment choices

ESRO specifies protocol machinery, but it does not eliminate deployment judgement.

Implementations and deployments must work with retransmission intervals, maximum retransmission counts, inactivity time and reference-number lifetime. These values are chosen for the network in which ESRO is expected to operate.

That means reliability is not reducible to a protocol name.

A retransmission policy that suits one delay and loss environment may behave poorly in another. A reference-number lifetime that is too short for the actual network and retry behaviour can create correlation hazards. A long inactivity interval can retain state longer than needed; a short one can expire it before delayed traffic has finished arriving.

The RFC therefore belongs to a class of protocols in which correctness depends not only on packet format but also on the relationship between state-machine assumptions and the network being used.

The design remains connectionless at the transport layer. ESRO runs over UDP, whose basic service does not itself create a reliable remote-operation abstraction. ESRO builds its own operation-oriented reliability mechanisms above that substrate.

Not RPC history in miniature

It is tempting to turn ESRO into a parable about remote procedure calls in general.

That would be too broad.

RFC 1831, describing ONC RPC, belongs to the wider history of remote invocation mechanisms, but RFC 2188 is its own design with its own primitives, roles and failure semantics. Its significance here lies in the specificity of those semantics, not in making it stand for every RPC system.

Likewise, ESRO should not be drafted into an argument about generic “exactly once” claims.

The RFC does not grant that abstraction merely because it has invoke IDs, retransmissions and acknowledgements. Retransmission can make duplicate protocol traffic possible. Application behaviour under duplicate invocation is a separate question. A protocol-level success does not by itself prove that an external, durable, non-idempotent action happened exactly once.

Nor is this a 1997 version of a modern distributed transaction protocol. There is no basis for treating an ESRO ACK as equivalent to a transactional commit record spanning multiple systems.

The useful history is smaller and more precise: RFC 2188 explicitly modelled efficiency choices and endpoint-relative knowledge within a short-operation protocol.

What each event can actually support

A disciplined reading of ESRO resists the urge to promote a local event into a universal fact.

An invocation request proves that an invocation was issued, not that it arrived.

Delivery to the performer proves reception, not successful execution.

ESROS-RESULT represents a successfully performed operation, but later delivery can still fail.

An invoker result indication proves that the invoker-side protocol observed the result, not that an independent business ledger was durably updated.

An ACK in acknowledged mode gives the performer additional peer-derived evidence about the protocol exchange, but not authentication or idempotency.

A performer FAILURE.indication after result transmission can be consistent with several histories, including one in which the invoker already received the successful result.

A timeout proves that a timer expired.

That final sentence sounds almost pedantic. It is also the operational heart of the matter.

Turning “timeout” into “the remote action did not happen” adds a claim the timer itself cannot establish.

Verification is a protocol-level admission of uncertainty

RFC 2188’s suggestion of a separate verification operation is revealing.

It recognises that once an acknowledged exchange ends in performer-side uncertainty, blind repetition is not the only possible response. The application can ask a different question: what is the state now?

That changes the recovery strategy from attempted inference to explicit observation.

The distinction becomes crucial when operations are not safely repeatable. If a remote request means “return this status”, repetition may be inexpensive. If it means “perform an external action whose duplicate cannot simply be undone”, retrying after an ambiguous timeout may be the dangerous choice.

A verification operation does not magically remove all uncertainty. Its own request and response still run through a distributed system. But it gives the application a way to represent the uncertainty honestly rather than disguising it as certainty.

That, more than any individual opcode, is the intellectually durable feature of RFC 2188.

Efficiency and knowledge were traded explicitly

ESRO was designed to make short reliable operations efficient. The protocol therefore made message cost visible.

The three-way mode expends an acknowledgement to obtain additional performer-side knowledge. The two-way mode avoids that exchange and accepts a more local notion of completion.

This is not simply “safe mode” versus “unsafe mode”. Both have defined semantics. The important question is what evidence an application needs.

Where peer-derived knowledge matters, the ACK has value.

Where the performer only needs to know that its own result-processing path has ended, the non-acknowledged mode can avoid a message whose information is unnecessary to that application.

The design thus treats protocol overhead and epistemic strength as linked choices.

That is an unusually useful way to read a protocol from 1997: not as a list of packets, but as a price list for knowledge.