RFC 3135: When a Proxy ACK Was Not Application Delivery

Summary

RFC 3135 surveyed proxies that improved TCP over satellite and wireless links by spacing, filtering or generating acknowledgements, retransmitting locally, splitting connections, compressing traffic or hiding disconnections.
A local TCP ACK could mean that the proxy had accepted custody, not that the distant TCP stack or application had received the bytes. The speed gain therefore created new evidence, trust, fate-sharing and diagnostic boundaries.

The acknowledgement stopped halfway

A sender transmits data toward a distant application across a long satellite hop. The intermediary nearest the difficult link responds first. From the sender's point of view, progress has been acknowledged. Its congestion window can advance without waiting for a signal to make the entire round trip. The slow path appears shorter.

But the data has not acquired magical distance. It may be buffered at the proxy. It may still face the satellite hop, a wireless outage, the second proxy, the receiver's TCP stack and the application above it. If loss occurs after the local acknowledgement, the original sender has already surrendered part of its ordinary recovery evidence. The proxy must retain enough state and data to repair the loss.

That was one of the mechanisms surveyed by RFC 3135 in June 2001. The document called the class Performance Enhancing Proxies, or PEPs. Its purpose was neither to canonise a product nor to condemn every intermediary. It catalogued ways of making Internet protocols behave better over links whose latency, bandwidth, asymmetry, error pattern or disconnections made native performance unsatisfactory. Then it catalogued what those optimisations could cost.

The most important cost was semantic distance. An acknowledgement could arrive sooner precisely because it came from a nearer actor. The sender obtained a useful transport event, but its authority had changed. The signal described custody at the proxy, not delivery to the intended endpoint—and still less acceptance by the application.

Not one machine called a PEP

RFC 3135 did not describe a single architecture. That restraint matters, because the word proxy can make unlike mechanisms sound interchangeable.

A PEP could operate at the transport layer, observing TCP and changing only transport behaviour while leaving the application protocol end to end. It could operate at the application layer, terminating an application exchange and using knowledge of that protocol. It could be one integrated component where a wired network met a wireless link, or a distributed pair surrounding a satellite segment. The two halves could perform different work because the forward and reverse paths had different capacities.

The PEP could split the TCP connection. The incoming connection would end at the intermediary, which would originate a second connection toward the destination. Two distributed proxies might use a third, link-specific connection between them—perhaps an altered TCP, perhaps a proprietary protocol over UDP—and might multiplex several user connections through it.

Or the mechanism could be much less invasive. ACK spacing could smooth a burst of acknowledgements without claiming receipt for data. ACK filtering could remove redundant acknowledgements from a scarce return channel and reconstruct a useful stream later. A Snoop-style link-layer function could cache and retransmit a lost wireless segment while suppressing duplicate acknowledgements. Compression could reduce the bytes crossing the constrained link. None of those descriptions alone tells us whether the end-to-end semantics survived.

RFC 3135 therefore separated transparency from semantic preservation. A mechanism could be invisible to the host and still alter who terminated the connection. Another could be visible to the user yet leave application receipt end to end. “Transparent” answered who knew. It did not answer who had acknowledged, where state lived or what failure the endpoints could observe.

Faster feedback moved responsibility

Local acknowledgement was the revealing case because it changed both time and obligation.

Ordinary TCP acknowledgements are already bounded evidence. RFC 3135 reminded readers that a TCP ACK indicates delivery to the TCP implementation at the peer end system; it does not guarantee that the application has received, stored or acted upon the data. Applications that require reliable completion need their own end-to-end check or acknowledgement suitable to the work they perform.

A PEP inserted another boundary before even that limited peer receipt. When the PEP acknowledged data locally, the sender learned that the PEP had accepted it. The memo was explicit about the consequence: the burden of recovering any data dropped after that acknowledgement fell on the proxy.

That burden is not a metaphor. The proxy needs buffers for unacknowledged downstream data, timers for the impaired segment, sequence state, a view of downstream acknowledgements and a rule for local retransmission. If the link disconnects, a split proxy can stop accepting new data, advertise a closed window toward the sender, preserve state and resume when the link returns. The sender's TCP connection may survive an outage it would otherwise interpret as failure.

The mechanism can be valuable. It can avoid forcing a global congestion response to a local radio loss. It can keep a session usable across a temporary disconnection. It can prevent a long propagation delay from governing every feedback loop. RFC 3135 was written because operators and users had real performance problems, not because the end-to-end argument was a decorative principle.

Yet custody is now part of the protocol's operational truth. If the proxy says “received” before the destination says it, the system needs evidence that the proxy retained what it promised and later fulfilled the promise. Without that evidence, the local ACK becomes a speed signal whose reliability meaning is assumed rather than demonstrated.

Five receipts for one byte stream

The cleanest way to read the architecture is to keep its receipts apart.

First, the sending application hands bytes to its local transport. That says the local system accepted work. Second, the PEP may acknowledge and buffer those bytes. That says an intermediary assumed some responsibility. Third, the data crosses the degraded subpath. That is a network observation, with its own loss and delay. Fourth, the remote TCP implementation acknowledges receipt. That is stronger than the proxy's custody receipt but still ends below the application. Fifth, the remote application confirms the event its protocol cares about: parsing a command, storing a message, committing a transaction or completing a transfer.

Even the fifth receipt needs a declared meaning. An application ACK can mean “parsed,” “queued,” “durably stored” or “completed,” depending on the protocol. RFC 3135's email-relay example made responsibility transfer concrete. A relay Mail Transfer Agent could receive a message, write it to non-volatile storage, acknowledge it at the application layer and assume the duty of later delivery. That architecture abandoned a single end-to-end exchange, but it made the handoff and retry obligation explicit.

An invisible transport PEP is different. It normally leaves application acknowledgements end to end, which protects the application's final check. But the sender can still see transport progress disconnected in time and authority from the far endpoint. If monitoring records only sender-side ACKs or apparent RTT, it can declare success while the proxy is still holding the risk.

The lesson is not that local ACKs are false. They are true statements from a nearer actor. Trouble begins when a dashboard, test or operator silently promotes that actor's receipt into evidence owned by the destination.

A connection could survive the link and die with the optimiser

Moving state into the path changed fate sharing. With ordinary endpoint-held connection state, a failed router need not destroy the connection if another route becomes available. The packets can take a different path while the endpoints preserve the transport state.

If a PEP contains indispensable per-connection state and buffered data, the failure of that intermediary can terminate the connection even when an alternate network path still exists. The path survived; the optimiser did not. Because the optimiser had become part of the connection's memory, its crash became an application-visible event.

RFC 3135 did not treat that trade as automatically irrational. PEPs were often placed on last-hop or private networks with no meaningful alternate path. A wireless outage might already threaten the session. A user might reasonably accept the additional proxy risk in exchange for a usable service. The document's condition was governance: the user or responsible administrator should know the implication, control the choice and retain the ability to use ordinary end-to-end IP without the enhancement.

That condition is easy to lose in operation. Once a PEP is transparent, always on and owned by the access network, the party enjoying the aggregate performance gain may be different from the party carrying the application risk. Buffer exhaustion, process restart and state loss become internal events until a user asks why acknowledged data did not complete.

Encryption removed the optimiser's eyesight

Many PEP techniques depended on visibility. To space ACKs, the intermediary had to recognise them. To split TCP, it had to terminate transport state. To compress application headers or alter application behaviour, it had to read still more.

End-to-end IPsec ESP challenged that arrangement. When the TCP header and payload were protected between the actual endpoints, an intermediate PEP could not reliably inspect or modify the information on which its optimisation depended. RFC 3135 described the choice bluntly for many designs: end-to-end IPsec or the PEP.

One workaround was to terminate security at the proxy and establish separate protected legs. That preserved encryption on the links, but it did not preserve end-to-end security. The traffic was exposed inside the PEP for processing. The endpoints had to trust a network intermediary, and different protection levels on the two legs could create a misleading sense of what the connection had negotiated.

Other mitigations—selectively bypassing PEP processing, protecting only the proxy-to-proxy segment, or building tunnels to the PEP—shifted the boundary rather than erasing it. Each added configuration and a new statement about who could see plaintext and who was authorised to alter transport behaviour.

Later documents show that the conflict did not disappear with the early satellite era. RFC 3449 made header visibility and per-flow identification prerequisites for several asymmetry mechanisms. RFC 8404 and RFC 8517 later recorded how encryption limits transport-centric network functions and why operators had deployed them. RFC 8684 even had to consider proactive PEP acknowledgements in Multipath TCP's retransmission rules. Those later sources do not prove adoption in 2001. They show that the boundary RFC 3135 named became a recurring protocol-design fact.

The proxy could hide exactly the failure an operator needed to see

PEPs were often designed to conceal impairment. During a wireless disconnection, a proxy could freeze the sender's progress, retain data and keep the connection from collapsing. For the user, that could be the feature.

For diagnosis, it could be an ambiguity. The remote endpoint might be unreachable while the sender remained in a plausible transport state. Failure detection could be delayed, including the trigger for switching to an alternate communication path. The intermediary had improved continuity by changing when the endpoint was allowed to learn that continuity had failed.

Common tools could tell a different story from the proxied TCP flow. Ping might be routed around the PEP. It might pass through without receiving the same treatment as TCP. The PEP might answer on behalf of the distant system. Traceroute could expose network hops without exposing the connection split or the state held inside it. A successful probe could prove reachability to the proxy, or reachability for ICMP, while the application path remained blocked.

Asymmetric routing complicated placement further. A distributed mechanism might need both directions to traverse its two components, yet routing could return traffic along another path. Mobility could move a host to a new serving node and require fast transfer of PEP state. Scaling required more processing and memory than ordinary forwarding, because the proxy inspected higher layers and commonly retained state per connection. Parallel proxies then required another control system to keep flows attached to the correct state.

Each optimisation created a second question: what evidence would reveal its own failure? Without that receipt, a device installed to hide a bad link could also hide itself.

A survey, not a universal verdict

RFC 3135 was careful about its authority. It was Informational. It surveyed mechanisms and environments. It did not recommend PEPs in general, and it did not claim that all link problems should be solved end to end at any cost.

The examples—VSAT satellite networks, wireless WAN systems, WAP arrangements and Snoop-style wireless LAN recovery—illustrated design families. They were not a census of the Internet, a controlled product comparison or evidence that every named mechanism produced the same result. The document also said new link technologies should, where possible, be designed so that PEP techniques were unnecessary.

That balance is why the memo remains useful. It did not reduce the debate to purity versus performance. It asked which function moved into the network, whether the user controlled the move, what security became impossible, where indispensable state now lived, what acknowledgement meant and how failure could still be diagnosed.

RFC 3234 later placed PEPs in a broader middlebox taxonomy. RFC 3426 used RFC 3135 as a case study in weighing architectural benefits against costs. Those documents retained the same discipline: an improvement is not complete until its new failure and control surfaces are counted.

Measure the gain without laundering the receipt

A credible evaluation would begin with the performance problem. Record the path, direction, link characteristics, native RTT, error and disconnection pattern, offered workload and application objective. Identify the PEP version, owner, placement and mechanisms enabled. State whether it is integrated or distributed, transparent or explicit, split or end to end, and whether the user can bypass it.

Then record the evidence chain. When did the sender transmit? When did the proxy acknowledge? How many bytes entered its buffer? Was that buffer volatile? When did the data cross the impaired link? Which component retransmitted after loss? When did the remote TCP ACK arrive? What application response followed? Was the result merely parsed, queued or durably committed?

Measure both local and end-to-end retransmissions. Preserve proxy restart and buffer-pressure events. Record security endpoints and which headers or payload were visible in every segment. Verify both traffic directions, flow affinity, mobile state transfer and alternate-path behavior. Compare application completion and correctness with throughput, apparent RTT and congestion-window growth.

The red flags are mismatches. A local ACK precedes durable custody. A proxy restart loses bytes the sender believes were accepted. Ping stays green while the TCP flow stalls. Encryption disables the optimisation. Return traffic bypasses one half of a distributed pair. Sender throughput improves while application completion worsens. Failure is hidden long enough to delay failover.

None of those observations makes the earlier ACK invalid. It makes its jurisdiction visible.

The proxy in RFC 3135 was built to shorten a loop. Historically, it also forced the Internet to name what a loop was allowed to prove. A transport acknowledgement from the middle could be useful, honest and performance-enhancing. It was still not the distant application's receipt. The architecture remained trustworthy only when that missing distance was measured rather than wished away.

The Proxy Acknowledged the Bytes. The Application Had Not Received Them: RFC 3135

Why it matters

Summary

The acknowledgement stopped halfway

Not one machine called a PEP

Faster feedback moved responsibility

Five receipts for one byte stream

A connection could survive the link and die with the optimiser

Encryption removed the optimiser's eyesight

The proxy could hide exactly the failure an operator needed to see

A survey, not a universal verdict

Measure the gain without laundering the receipt

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing