The threshold problem
Every traffic-based DDoS detector eventually comes down to one decision: how much traffic is too much? Cross some line and an attack is declared. Stay under it and the traffic is treated as normal. That line is the baseline, and the quality of the whole detector depends on it.
Set the line too low and ordinary busy moments trip it constantly. The team learns to ignore the alerts, and a real attack arrives in a stream of noise nobody is reading anymore. Set the line too high and a genuine attack can ramp up underneath it, large enough to hurt, small enough to stay quiet. Worse, the right line for one server is the wrong line for another, and the right line today is the wrong line in three months once traffic has grown.
So the baseline cannot be a fixed number, and it cannot be hand-tuned per server forever. It has to be learned, per node, and it has to keep up. The interesting question is which statistic you learn it from.
Why a plain average is the wrong statistic
The obvious choice is the average. Take your packets-per-second over some window, average it, and base the threshold on that. It is simple, and it is also fragile, because the average is pulled around by every outlier.
Real traffic is full of brief, legitimate spikes: a cron job, a cache flush, a backup kicking off, a burst of real visitors. None of those are attacks, but every one of them lifts the average. An average baseline therefore drifts upward to accommodate noise that is not normal at all, and a threshold built on top of it sits higher than it should. The gap between "normal" and "alarm" quietly widens, and a real attack has more room to hide inside it.
Look at a single minute of one server's packets-per-second, with one legitimate spike in it:
per-second PPS samples (one busy minute): 120 130 118 125 140 122 119 ... 2,400 ... 128 124 131 average of the window: ~180 PPS <- dragged up by the one spike 99th pct of the window: ~145 PPS <- the spike barely moves it
One transient burst nearly doubled the average. The 99th percentile barely noticed it. That difference is the entire argument.
What a percentile actually is
A percentile answers a question about ranking rather than about sum. The 99th percentile of your packets-per-second is the level that 99 percent of your one-second readings fall at or below. Put plainly: it is your traffic on a busy second, but not your traffic on a freak second.
That is exactly the number you want a baseline to capture. It represents "normal, including the genuinely busy moments" while structurally ignoring the rare outliers, because a handful of extreme samples cannot move a percentile the way they move an average. The percentile describes the shape of normal. The average describes normal plus whatever noise happened to land in the window.
An average asks "what is the typical value, give or take the outliers." A percentile asks "what level does normal traffic actually stay under." For a detection baseline, the second question is the one that matters.
How Flowtriq builds the baseline
Flowtriq samples each node's packets-per-second once per second and keeps a rolling window of the last 300 samples, which is five minutes of recent traffic. From that window it computes the 95th and 99th percentiles, and the detection threshold is set at three times the 99th percentile.
window: 300 samples (1 per second = 5 minutes) tracked: p95 and p99 of packets-per-second threshold: 3 x p99 recompute: roughly every 10 seconds
The window slides continuously. Every second the oldest sample falls off and the newest is added, and the percentiles are recomputed every few seconds rather than on every single tick, which keeps the math cheap enough to run constantly with no measurable load. The result is a threshold that tracks each node individually and keeps tracking it. As a server's real traffic grows over weeks and months, the rolling window grows with it and the threshold rises naturally. There is nothing to revisit and nothing to retune.
The choice of three times p99 is deliberate headroom. The p99 already represents a genuinely busy second. Multiplying it by three leaves comfortable room above normal peaks for legitimate bursts, while staying tight enough that a real attack, which does not arrive at 1.5 times normal but at many times normal, crosses the line in its first second of elevation.
The cold start: protecting a brand-new node
A percentile needs samples, and a node that came online thirty seconds ago does not have 300 of them yet. Until the window fills, roughly the first five minutes, there is no mature baseline to multiply.
Flowtriq handles that gap with a floor. Before the window is full, the threshold is the greater of three times the p99 of whatever samples exist so far, or a fixed floor of 150 packets per second. A new node is therefore protected from its very first second. The threshold is provisional and gets sharper as the window fills, but there is never a window of time where a fresh node is simply unguarded waiting to learn.
What this means in practice: no tuning
The practical payoff of all of this is that there is nothing to configure. You do not set a packets-per-second threshold. You do not pick a sensitivity level. You do not maintain a different number for the game server than for the API gateway, and you do not revisit any of it next quarter when traffic has changed.
Each node learns its own normal from its own traffic, the percentile keeps that baseline honest in the face of everyday spikes, the rolling window keeps it current, and the cold-start floor covers the first five minutes. A threshold that is wrong is one of the most common reasons a DDoS detector either drowns a team in false positives or misses the real thing. Building the baseline from the 99th percentile is how Flowtriq avoids both, on every node, without asking anyone to tune anything.
Detection thresholds that learn each node and never go stale. Flowtriq builds a percentile-based baseline per node, with no thresholds to set and no tuning to maintain. Start a free 7-day trial at flowtriq.com/signup.