Technology
This page describes the technical problems Tillered is designed to address and the architectural approach used to improve network performance across distributed systems.
The problem: TCP over long distances
TCP is a reliable, congestion-controlled transport protocol designed for correctness and fairness. While this makes it robust on local and moderately sized networks, it also introduces performance limitations when used over long-distance or high-latency links.
Latency and round-trip time (RTT)
TCP relies on acknowledgements to confirm data delivery. As round-trip time increases, the sender must wait longer to receive acknowledgements before transmitting additional data. This directly limits throughput, even when sufficient bandwidth is available.
Congestion control behaviour
TCP congestion control algorithms increase sending rates gradually and reduce them sharply in response to packet loss. On long-distance paths, a single loss event can cause significant throughput reduction, followed by slow recovery due to increased RTT.
Bandwidth-delay product
High-latency links require large congestion windows to fully utilise available bandwidth. In practice, default TCP configurations often underutilise long fat networks, resulting in lower-than-expected throughput.
These effects compound across multiple hops and regions, making distributed systems slower and less predictable as physical distance increases.
Tillered's approach
Tillered addresses these limitations by optimising how traffic is carried between nodes rather than relying on end-to-end TCP behaviour alone.
The system establishes optimised paths between nodes and manages traffic flows based on observed network characteristics. This allows performance to be improved without requiring application-level changes.
Segmented paths and locality
By reducing the effective distance of individual transport segments, Tillered limits the impact of RTT and packet loss on any single connection. When packet loss or corruption occurs, the affected segment can detect and retransmit locally rather than requiring a round trip across the entire path. Localised congestion control reacts more quickly and recovers faster than a single long-haul TCP flow.
Continuous measurement
Nodes observe latency, loss, and throughput characteristics over time. This information is used to inform routing and transport decisions, improving predictability under changing network conditions.
Control plane and data plane separation
Tillered maintains a strict separation between control-plane operations and data-plane traffic. Control-plane components coordinate configuration and topology, while data-plane traffic flows directly between nodes.
This separation allows the same core technology to operate in both centrally managed and fully decentralised deployment models.
What Tillered does not do
Tillered is intentionally focused in scope. The system does not:
- Inspect or modify application payloads
- Proxy traffic through external services
- Require application-level integration
- Depend on continuous internet connectivity
These constraints simplify deployment, reduce trust assumptions, and make behaviour easier to reason about in regulated environments.
Network layer operation
Tillered works at the network infrastructure layer. It accelerates TCP traffic transparently, meaning existing applications and transfer tools continue to work without modification. If you already use specialised transfer software, Tillered provides additional acceleration underneath, complementing application-level optimisations.
Zero-risk integration
Deployment uses policy-based routing configured on your firewall or network hardware to steer selected traffic through Tillered nodes. If a node becomes unavailable, the firewall falls back to the direct path and can load-balance across links -- no traffic is dropped. Tillered nodes do not need to sit on your LAN. They can be deployed in a DMZ or isolated VLAN, with routing handled entirely by the firewall.
Relationship to deployment models
The technology described here is shared across all Tillered deployment models. Differences between Tillered Cloud and Tillered Self-Hosted relate to control-plane placement and operational responsibility, not core functionality.