Headend Multi Path Demo
Every packet sent twice, over two independent paths.
WTFast Multi-Path duplicates each game packet and races the copies over separate routes. A packet lost on one path is covered by its twin on the other, with no retransmission and no added latency. Under 10% injected packet loss, the share of player inputs the game server never received fell from 9.6% to zero.
Across a 447-second Counter-Strike 2 session, the game's networking layer counted 100,839 duplicate packets, 46.71% of everything received. On the same connection without Multi-Path: zero. Both copies cross the access line, so a loss there is covered in the same way a loss in the WAN is.
Multi-Path absorbs loss
WTFast runs it · covers device → access line → WAN → server
- How it works
- Two identical copies are in flight at once over independent routes. The receiver takes whichever arrives first and discards the other. No retransmission, so no round-trip penalty.
- What it fixes
- Loss. Both copies must fail for data to be lost, so a 10% loss rate on each path leaves roughly 1% of packets genuinely gone.
- What it does about jitter
- It does not make delayed packets arrive sooner. What it does is stop a delayed packet becoming a lost one. Its twin on the other path arrives in time, so the game still assembles the frame.
- Cost
- Roughly double the game traffic. WTFast plans at ~100 kbps per session, so a duplicated session is on the order of 200 kbps, negligible on any modern access line.
QoS removes queueing delay
ISP applies the policy · WTFast supplies the classification
- What redundancy cannot fix
- When the uplink is congested, both copies sit in the same buffer and arrive equally late. Duplication protects against loss, not against waiting in a queue.
- Where it bites
- Home uplinks are asymmetric and saturate easily. One cloud backup or video call adds tens of milliseconds to every game packet leaving the house.
- Who can fix it
- Only the ISP. It owns the CPE and the access network: the queue where the delay is created.
- The hard part
- Identifying game traffic. It is UDP on arbitrary ports and increasingly encrypted, so conventional DPI classification is losing ground.
Impairment applied by a transparent Linux bridge placed physically between the test PC and the headend, using tc netem on both interfaces so upstream and downstream degrade together. All figures are from Counter-Strike 2's own end-of-session networking summary, aggregated over tens of thousands of ticks and frames. Single variable: Multi-Path on or off, everything else held constant.
| Measure | Single path | Multi-Path | Change |
|---|---|---|---|
| UPSTREAM: player inputs reaching the server | |||
| Ticks arrived on time | 90.1% | 99.5% | +9.4 pts |
| Ticks dropped in the network | 9.6% (2,150) | 0.0% (0) | eliminated |
| DOWNSTREAM: server updates reaching the player | |||
| Network frames dropped | 11.06% | 1.09% | −90% |
| Sample size (frames) | 8,446 | 28,169 | n/a |
| Measure | Single path | Multi-Path | Change |
|---|---|---|---|
| Network frames dropped | 2.46% | 0.22% | −91% |
| Frame misdelivery (dropped + out of order) | 19.1% | 6.1% | −68% |
| Frames arriving out of order | 16.65% | 5.92% | −64% |
| Sample size (frames) | 8,953 | 4,545 | n/a |
upstream, 10% loss test
downstream, 10% loss test
marginal Wi-Fi test
by the game's transport
Under single path, the same impairment produced continuous network warnings in the game console and repeated failures to reconstruct game state ("cannot process snapshot tick … which we do not have"): the stutter a player actually feels. With Multi-Path those warnings stopped entirely. Round-trip time is deliberately excluded from these figures: the single-path routing logic is under repair and would not make a fair baseline.
Why a packet-loss counter will still show the raw loss
Anyone reproducing these tests should expect the packet-level loss figure to keep reading close to the injected rate, around 9.8% in the test above, whether Multi-Path is on or not. That is correct behaviour, not a contradiction.
A game's transport layer tracks sequence numbers on its own connection. It has no visibility of a duplicate that travelled a different route, so a packet killed on one path simply looks like a gap. The recovery is only visible one layer up, where the game reports whether it could reconstruct its state: 9.8% of packets missing, 1.09% of frames lost.
The practical rule: measure loss at the application layer (frames delivered, ticks acknowledged, inputs received) rather than at the packet counter. Some titles expose those figures and some do not.
WTFast already knows which flows are games
The headend is proxying the session, so it holds the thing a QoS policy needs and DPI struggles to get: a positive identification of game traffic, per flow, in real time. That identification can be handed to the access network as DSCP marking or through the ISP's own policy engine, turning a classification problem into a policy decision.
Subscriber launches a game. Traffic routes through the headend.
The headend identifies the flow: title, endpoint, protocol, packet rate.
That classification is signalled to the access network.
The ISP prioritises the flow in the CPE and upstream queues.
on 4 cores / 10 W
at 44.8% CPU
~200 KB per connection
on 32-core hardware
Measured on a Protectli VP2410 (Intel Celeron J4125, 4 cores, 10 W, passively cooled). Headend cost scales with packet rate rather than bandwidth, so capacity depends on game type: an MMO player costs roughly a fifth of a competitive FPS player. The 32-core figure is a projection scaled by core count and expected per-core performance; it has not yet been validated on target hardware.
Where each layer stops
Multi-Path protects everything that happens after duplication, which begins on the subscriber's device. It cannot help with impairment introduced before that point, and it cannot recover a packet the game never sent.
Multi-Path does not fix congestion. Both copies queue behind the same backlog on a saturated link and arrive equally late. Reducing that delay requires prioritisation at the queue itself.
QoS prevents delay and loss caused by congestion in a queue the ISP controls. It does not help with a marginal Wi-Fi link, interference, or a degraded access line. Those need fixing at the physical layer.