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.
Why build such a demanding test? The targeted Oracle qualification framework requires a QUIC stack's capacity to be expressed in packets per second per CPU — packets/s/CPU — so that the actual protocol-processing cost cannot be hidden by adding vCPUs. Our gate is therefore set at a minimum of 150,000 packets/s/CPU. The bench sends one million 64-byte IP packets: this small size maximises the number of decisions, cryptographic protections, acknowledgements and stack traversals per unit of data. It is the condition that genuinely exercises the CPU.
| 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/CPU |
| Worst run | 351,816 packets/s/CPU, i.e. 2.35× the qualification gate of 150,000 packets/s/CPU |
| Test suite | 86 out of 86 tests passing in Release |
Building SwQuic was quite a story. QUIC is not merely encryption placed on top of UDP: the implementation has to master the TLS 1.3 handshake, packet-number spaces, header protection, acknowledgements, loss detection, congestion and flow control, path migration and datagrams at the same time. Early benches exposed encapsulation and accounting defects that easier tests would have missed. Relentless correction, measurement and optimisation paid off: the stack now delivers one million packets without loss, while even its worst run clears the gate by 2.35×.
Standards implemented and verified in SwQuic
The Oracle condition concerns performance per CPU; protocol conformance comes from IETF standards and their test vectors. The timed path above is QUIC/TLS 1.3 transport with raw public keys. SwQuic also covers the HTTP/3 and WebTransport layers used by the platform.
- RFC 9000 — QUIC v1 transport: packets, frames, streams, flow control, migration and path validation.
- RFC 9001 — use of TLS in QUIC, packet protection and separation of cryptographic levels.
- RFC 9002 — loss detection, PTO and NewReno congestion control.
- RFC 8446 and RFC 8448 — TLS 1.3 and key-schedule validation against official test vectors.
- RFC 7250 — TLS authentication with raw public keys, used by the measured path; RFC 7748 and RFC 8410 for X25519 and the associated modern identities.
- RFC 9221 — QUIC DATAGRAM for real-time data that must not wait for retransmission.
- RFC 9114 and RFC 9204 — HTTP/3 and QPACK; RFC 7301 for h3 ALPN negotiation.
- RFC 9220 and RFC 9297 — HTTP/3 Extended CONNECT mechanisms, HTTP Datagrams and the Capsule Protocol used by the browser transport.
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.