Documentation
Performance: measurements and objectives
This page rigorously separates three things: what we have measured, what is demonstrated by test, and what the architecture aims for. A measured figure always comes with its bench condition; a design objective is always announced as such. We never publish an objective as if it were a measurement.
MeasuredWhat we have measured
Our measurements come from a multi-process bench: three distinct OS processes exchanging over real UDP sockets, not an in-memory simulation inside a single process. All the values below come from this bench.
| Indicator | Measured result |
|---|---|
| Packets delivered | 1,000,000 64-byte IP packets, zero loss, zero duplication, zero corruption, zero reordering |
| Average receive throughput — raw-public-key TLS 1.3 path | 366,543 packets/s |
| Average receive throughput — legacy path | 389,225 packets/s |
| Worst run | 351,816 packets/s, i.e. 2.35× the internal threshold of 150,000 packets/s |
| Test suite | 86 out of 86 tests passing in Release |
DemonstratedWhat is demonstrated by test (not timed)
Beyond throughput, several behaviours are demonstrated by real end-to-end tests. They are not timed: we verify that they work, not yet how fast.
- Real end-to-end between two nodes via a vigie: mutual raw-public-key TLS 1.3, deterministic path election, bidirectional delivery.
- Real QUIC migration to a new address tuple, without breaking the session.
- Fail-closed traversal: on failure, the connection closes instead of falling back to an unprotected path.
- Embedded vigie (milestone 1).
Design goalWhat the architecture aims for (objectives, not measurements)
The architecture aims for service objectives. These are design targets, not measurements: we publish them to state what the system must sustain, not what it has already demonstrated.
- Session ready: p95 ≤ 1 relayed RTT + 100 ms.
- First payload: p95 ≤ 1.5 × RTT + 100 ms.
- 0-RTT resumption: p95 ≤ 0.5 × RTT + 100 ms.
- Election of a simple direct path: p95 < 3 s.
- Datagrams strictly prioritised over service streams.
- Relay gate: ≥ 1 Gbps and ≥ 150,000 pps per core.
Why direct latency is that of your network
On a validated direct path, VIGIL-MESH adds only a single layer of end-to-end encryption to the network journey: no tunnel-in-tunnel, no double encryption. The latency you feel is therefore essentially that of your own network.
The design objective is that the elected path stays within max(5 ms, 10%) of the best validated path.
Where we stand
We have an advanced protocol and transport core, several real end-to-end paths demonstrated across multiple processes, and an architecture designed for network continuity. We are now funding multi-host qualification, the platforms and the first pilots.