WTFast Headend Multi Path Packet Race & WebRTC
Two copies. The faster one wins.
Every packet is sent twice over independent paths, and the receiver uses whichever arrives first. A packet that is lost, or that arrives too late to be used, is covered by its twin. We injected 10% packet loss into a live Google Meet call and a live Counter-Strike 2 session and measured what each application actually received. Nothing was installed on the subscriber's device.
The race, packet by packet
To an application, a packet that arrives too late is the same as one that never arrives. Both miss the playout deadline. This is the one thing Multi-Path changes.
Illustrative model, not measured data. Arrival times are simulated from a heavy-tailed delay distribution plus a loss rate, which is how real access networks behave: most packets arrive on time, a few are badly late, some never arrive. Multi-Path takes the lower of two independent draws. Run against the bench conditions we actually tested, the model predicts 9.9% and 1.0% unusable against measured results of 9.65% and 0.79%. The measured figures are below.
Google Meet, downstream
the garbling a listener hears
over a five-minute call
Counter-Strike 2
Google Meet, 10% packet loss, measured by the browser
Downstream is the direction a subscriber notices first: the other person's voice breaking up, their video freezing. These figures come from Chrome's own WebRTC statistics, recorded during live calls.
Impairment was applied by a transparent Linux bridge placed physically between the test PC and the headend, using tc netem at 10% loss on both interfaces. Statistics were exported from chrome://webrtc-internals at the end of each five-minute call. Single variable: Multi-Path on or off. Nothing installed on the test PC.
| Measure | Single path | Multi-Path | Change |
|---|---|---|---|
| Audio | |||
| Packets received | 6,817 | 6,917 | matched |
| Packet loss | 9.65% | 0.79% | −92% |
| Concealment (invented audio) | 4.701% | 0.371% | −92% |
| Concealment events | 91 | 24 | −74% |
| Video | |||
| Packet loss | 8.65% | 0.89% | −90% |
| Freeze events | 99 | 35 | −65% |
| Total time frozen | 32.9 s | 9.5 s | −71% |
| Video packets delivered | 29,131 | 54,584 | +87% |
| Measure | Single path | Multi-Path | Change |
|---|---|---|---|
| Audio packet loss | 9.94% | 0.74% | −93% |
| Audio concealment | 9.431% | 0.846% | −91% |
| Concealment events | 93 | 11 | −88% |
| Video freeze events | 61 | 31 | −49% |
| Jitter buffer depth | 302 ms | 183 ms | −119 ms |
For data to be lost, both copies must fail. At 10% loss per path that is 10% × 10% = 1%, and the measured result is 0.79%. The mechanism is arithmetic, not tuning.
More video, not just fewer freezes
Multi-Path delivered 87% more video packets in the same five minutes. Under loss, the conferencing client backs off and drops resolution to protect the call. With the loss removed it sustained a higher bitrate, so the picture was sharper as well as less interrupted.
A shallower jitter buffer
The receiver buffers incoming audio to smooth out irregular arrival. In run 2 that buffer fell from 302 ms to 183 ms, because arrivals were more predictable. That is 119 ms of added delay removed from the conversation, on top of the loss recovery.
Counter-Strike 2, with the server confirming what it received
Upstream is harder to prove. A client cannot see what the far end received, so a browser reports only the raw gaps in its own sequence numbers. Counter-Strike 2 solves this: its networking layer reports back which of the player's inputs the game server acknowledged. That is a direct measurement of what survived the upstream path.
Same rig, same 10% loss on both interfaces. Figures are from Counter-Strike 2's end-of-session networking summary, aggregated over tens of thousands of ticks and frames. Round-trip time is deliberately excluded: the single-path routing logic was under repair and would not have made a fair baseline.
| Measure | Single path | Multi-Path | Change |
|---|---|---|---|
| Upstream: player inputs reaching the game server | |||
| Ticks arriving on time | 90.1% | 99.5% | +9.4 pts |
| Ticks dropped in the network | 9.6% (2,150) | 0.0% (0) | eliminated |
| Upstream frames dropped | 9.50% (2,160) | 0.00% (0) | eliminated |
| Downstream: game state reaching the player | |||
| Network frames dropped | 11.06% | 1.09% | −90% |
| Sample size (frames) | 8,446 | 28,169 | n/a |
Under 10% injected loss, the game server received every single one of the player's inputs. On single path it lost 2,150 of them. In a competitive shooter an input that never arrives is a shot that never happened, and unlike a late server update it cannot be superseded by the next one.
In the same session, the packet-level loss figure still read 9.8%. That is correct behaviour. A transport layer counts gaps in its own sequence numbers and has no visibility of a duplicate that arrived by a different route. The recovery is only visible one layer up, where the application reports whether it could reconstruct its state: 9.8% of packets missing, 1.09% of frames lost.
The same impairment, the same access line, many applications
Multi-Path is workload independent. It does not inspect or understand the application. Any continuous real-time media on the subscriber's connection benefits from the same mechanism, whether it is carried by WebRTC or by a vendor's own protocol.
Cloud voice and meetings
Teams, Zoom, Meet, Webex. The largest category by volume, and increasingly carried on residential lines as hybrid work becomes permanent.
Measured hereRemote contact-centre agents
A home-based agent's call quality is entirely dependent on their residential connection. The employer already measures handle time and customer satisfaction.
Direct cost attachedTelehealth
Patient at home, clinician often also remote. Consultation quality depends on two access lines neither party controls.
Browser based, WebRTCVoice AI agents
Browser and app-embedded conversational agents hold an open bidirectional stream for minutes at a time. Fastest growing segment in the category.
WebRTCOnline and cloud gaming
The most latency-sensitive workload of all, and the one where a lost upstream input is unrecoverable.
Measured hereRemote desktop and live production
VDI, remote workstations, and low-latency streaming contribution. Continuous, upstream heavy, and quality-visible.
Same mechanismWebRTC dominates browser-based real-time media and is the only common transport that exposes usable statistics, which is why it was used for these measurements. Several native desktop clients use their own protocols instead. The network characteristics are the same either way: continuous UDP, latency sensitive, no time to retransmit. Multi-Path helps regardless of which protocol carries the media.
We are looking for ISP partners for the next phase
These results come from a controlled bench: one subscriber line, one headend, a network emulator producing repeatable impairment. What they cannot show is how the technology behaves across a real subscriber base, on real access networks, at scale. That is the work we want to do next, with operators who are willing to measure it properly.
- Zero touch deployment The headend installs at the distribution point. Nothing is installed at the household or business, and no CPE change or truck roll is required.
- Your subscribers, your data We are interested in results from real access networks: DOCSIS, fibre, fixed wireless. Impairment in the field does not look like a test bench.
- A product you can bundle A premium tier, a remote-work offering for business customers, or a default network improvement to reduce support contacts and churn.
- Traffic classification included The headend identifies real-time flows in real time, which is the input a QoS policy needs and the thing conventional inspection is steadily losing the ability to provide.
If you operate an access network and want to see whether this holds up on yours, we would like to hear from you.
What these results do not show
This is a bench measurement, not a field trial. One subscriber line, synthetic impairment, a small number of runs. The downstream result has been reproduced across two independent sessions and two unrelated applications, but it has not been tested across a subscriber population.
Multi-Path does not fix congestion. When an uplink is saturated, both copies of a packet queue behind the same backlog and arrive equally late. Redundancy protects against loss, not against waiting. Reducing that delay requires prioritisation at the queue itself, which is why the classification capability matters alongside the redundancy.
It does not repair a broken line. Physical degradation, a failing access circuit, or sustained interference need fixing at the physical layer. No amount of redundancy substitutes for that.