Here is a small fact that explains a surprising amount of bad network behavior: to an ordinary router, a Zoom call and a nightly file backup look identical. Both are HTTPS. Both ride port 443. Both are just "encrypted traffic to somewhere." The router has no idea that one is a live conversation where a half-second of delay is a disaster, and the other is a background transfer that nobody is watching.
That blind spot is why, when a link gets congested, everything degrades at once. The call and the backup compete for the same path at the same priority, because the network can't tell them apart. Fixing that requires the network to understand what it's carrying — and, more to the point, to understand it in time to do something about it. That's what this post is about.
The classification gap
Traditional routers and most SD-WAN products classify traffic with static rules: port 443 is "web," port 53 is "DNS," and so on. That worked when ports mapped cleanly to applications. It doesn't anymore. Today an enormous share of traffic is encrypted and multiplexed over a handful of ports, so "port 443" tells you almost nothing. A Zoom call, a Netflix stream, a Slack message, and a 40-gigabyte backup can all look the same to a port-based rule.
Deep packet inspection products exist, and many are very good at identification. But they're typically built for security monitoring — the output is a log line, a dashboard, an alert. The classification and the forwarding live in different systems, on different timescales. So even when something on the network knows what an application is, that knowledge usually isn't wired into the moment-to-moment decision of which link a packet should take.
Which reframes the problem. It isn't "can anything identify this flow" — plenty of things can. It's whether the thing that identifies it can sit inside the forwarding decision, at the moment that decision is made, without slowing it down. That's an architecture question, not a detection question.
Split the work by how often it has to happen
The trick is noticing that the two halves of this job have completely different duty cycles.
Identifying a flow happens once per flow. It's comparatively expensive — you watch a few packets, look at handshake structure, match signatures. Choosing a link happens once per packet. It has to be cheap enough to do millions of times a second.
Most designs conflate the two and end up paying the identification cost on the packet path. Weavian separates them. A userspace engine built on nDPI does the identification, once, off the forwarding path. A small eBPF program in the Linux kernel does the per-packet work: read the flow's five-tuple, look up its class, look up the policy for that class, pick the link, forward. The two halves meet in a single shared BPF map — written by userspace, read by the kernel, with no per-packet handoff between them.
Classification isn't a report the router consults afterward. It is one of the four constant-time lookups the forwarding decision already performs.
Two clocks
Because the work is split, there are two different latencies here, and it's worth being precise about both — this is exactly the place where marketing copy tends to blur things.
How long it takes to know — 7 ms median
Across 120 ground-truth flows spanning six protocol families, the classifier reaches a confident verdict with a median of 7 milliseconds. The distribution is bimodal, for a reason that makes sense once you see it. Protocols that announce themselves in their first packet — DNS, STUN, NTP, plain HTTP — resolve in 5 to 8 milliseconds. Protocols whose identity is only visible once a handshake completes — TLS, QUIC — have to wait for the handshake, and land between roughly 110 and 330 milliseconds. The 90th percentile across everything is 329 ms.
How long it takes to act — 3.5 µs per packet
Once the class is in the map, the per-packet cost of the classified data path is about 3.5 microseconds on a four-core Atom field unit — roughly 9,300 CPU cycles — which puts the ceiling near 280,000 packets per second per core. That number doesn't grow as more flows open, because the lookups are constant-time hash reads rather than a walk down a rule list.
Milliseconds to learn. Microseconds to act. Three orders of magnitude apart, doing different jobs.
What happens in the gap
The obvious question: what about the packets that arrive before the verdict?
They ship. A packet belonging to an unrecognized flow takes the best-effort default and goes out immediately, while a copy is sampled up to the classifier. Nothing blocks, nothing buffers, nothing waits on a decision.
That's the right trade, and it's worth saying why rather than glossing it. The first few milliseconds of a video call are signalling and handshake, not audio. The first few milliseconds of a backup are irrelevant by definition. The failure mode that actually hurts people is a long-lived flow that spends its whole life on the wrong link — and that is precisely the case where a 7-millisecond verdict is early enough to be effectively instantaneous.
The network gets faster at knowing
There's a second mechanism that narrows the gap further, and it's the most satisfying part of the design.
Some protocols hand you a destination without telling you what the flow is. A DNS response, a STUN exchange, an mDNS announcement — each reveals where something is about to talk. So the classifier caches that: destination address to class, held for five minutes.
The effect is that a call sticks. A video conference isn't one flow; it's a handful of them, opened over several seconds as media negotiates. Once a single STUN exchange fingerprints the conferencing relay, every later flow to that address is classified as real-time on its first packet — no sampling phase, no waiting. The box gets faster at recognizing the things it has seen recently, which is exactly the traffic that matters most.
Two levels, and why
The taxonomy has two tiers. Eight broad categories — real-time, interactive, streaming, bulk, background, critical, diagnostic, and best-effort — cover everything. Underneath them sit specific applications: Zoom, Teams, Netflix, YouTube, Signal, Dropbox and the rest.
You can write policy at either level. "All real-time traffic prefers fiber" is a category rule. "Zoom specifically uses this link" is an application rule. An app inherits its category's policy unless you give it one of its own, so you never have to enumerate the world to get sensible behavior — you write the coarse rules once and add exceptions only where you actually have an opinion.
Switching the data plane between category-keyed and app-keyed operation is a single map write. Both maps are kept populated at all times, so the switch is instantaneous and no flow is dropped or misrouted across it.
A label you can't act on is trivia
Classification only matters if the routing layer can be changed to respond to it, and changed quickly. So we measured that too. Across 296 policy changes, the time from the control-plane API accepting a change to that change being observable in the kernel's policy map had a median of 5.9 milliseconds. The worst case observed was 364 milliseconds.
For context, a mobile WAN routinely imposes more jitter than that on its own. Policy reconvergence isn't visible to the applications riding on top. In practice it means an operator can drag an application onto a different link in a console and the kernel is enforcing it before the page finishes re-rendering.
Routing by intent, not by accident
Once the network knows what each flow is, routing stops being one blunt decision and becomes many specific ones. Real-time calls take the lowest-latency path. Streaming gets the path with bandwidth headroom. Bulk transfers go to the cheap link so they don't crowd out anything that matters. The congested link no longer drags your call down with your downloads, because the call and the downloads were never being treated as the same thing.
That's the direct effect. The indirect ones are bigger.
- Failover stops being all-or-nothing. If you can name a class, you can move a class. When a link degrades you can migrate the traffic that's suffering and leave everything else where it is, instead of picking up the whole site and putting it somewhere else.
- Redundancy becomes affordable. The last post in this series was about duplicating packets across multiple links so that loss on any one of them is invisible. Duplication buys reliability with bandwidth, which means you want it on the surgeon's video feed and emphatically not on the 40-gigabyte backup. Without classification, duplication is a blanket setting you can't afford to leave on. With it, it's a targeted spend.
- Visibility gets specific. The same label that steers a packet also attributes it. Joined with the edge's own view of which device on the LAN opened the flow, the answer to "what is that tablet doing" stops being "it sent 40 GB" and becomes "it streamed for two hours and backed up overnight."
A vocabulary that security can use too
Everything so far has been about routing. There is a second use for a network that can name its own traffic, and it is worth flagging here because it is where this series is heading.
Zero Trust architectures all converge on one question: should this particular thing be allowed to talk to that particular thing? Every serious version of it eventually asks for segmentation at the application level — and that is where most enforcement points run out of road, because the vocabulary they have is addresses and port numbers. We have already established what port 443 tells you. You cannot write "the guest tablet may not reach the control network, and nothing may run file sync over the satellite link" when your only nouns are an address and a port.
Classification supplies the nouns. And the machinery that would act on them is already in place, doing something else. On every packet the kernel program parses the flow, resolves it to a class, looks up a policy, and takes an action. Today that action is a WAN link. The same policy record is one field away from also carrying a verdict — allow, deny, or log-only — and the program that reads it already sits at the one point in the system that every packet has to cross.
Log-only is the commercially interesting one. It lets a site run enforcement in observation mode and produce a report of what would have been blocked, before anything is actually blocked. That is how an operator builds confidence in a policy without discovering its mistakes as an outage.
Two caveats worth stating plainly, because this is an area where vendors routinely overclaim. First, the policy is keyed on traffic class alone today; an access decision also needs a subject, and a subject is only as strong as whatever attests to it. An observed device — address, MAC, DHCP hostname, hardware vendor — is a useful starting point and a spoofable one. It is not an identity, and calling it one is the kind of claim that does not survive scrutiny. Second, we do not intend to author policy. The right shape is an enforcement point that compiles someone else's decisions into kernel maps, not another policy engine competing with the identity platform a customer already runs.
None of that ships today. What ships today is the part that is hard to build: a programmable enforcement point in the kernel that already knows what every flow is. The verdict is a field.
Where this doesn't work
Four honest limits, because a classifier described only by its wins isn't really described.
- Outbound vantage point. The program runs on the outbound path, which means protocols identified by the server's first message are invisible from that vantage point. SSH is the textbook case, since its dissector keys off the server banner. Labelling those requires a complementary program on the inbound side.
- Encrypted DNS. It hides the lookups that seed the destination cache, so the classified-on-first-packet shortcut degrades on networks that lean on it. Those flows still classify; they just take the slower road.
- Accuracy is a routing claim, not a forensic one. Accuracy is very high on clean protocol families and around 95% on a messy hand-labelled application trace. That is more than good enough to make a routing decision. It is not a forensic claim, and we don't make one.
- Churn costs something. A workload made entirely of short-lived connections runs about 1.4 times the per-packet cost of a long-lived one, because nothing gets to amortize — every new flow pays the sampling path and a fresh map entry.
Why the next classifier will be learned, not written
Every limitation in the previous section has the same root: signatures are written by hand, and the things they key on keep disappearing. TLS 1.3 with encrypted client hello removes the field that a great deal of identification leans on. QUIC variants obfuscate. New applications ship faster than anyone can write rules for them. The trend line is not in favour of pattern matching.
But one thing survives all of that encryption, because it cannot be encrypted: the shape of the traffic. A video call has a rhythm — small packets, regular intervals, roughly symmetric, sustained. A backup has the opposite one — large packets, one direction, as fast as the link will allow. No amount of encryption changes either, because they are properties of what the application is doing, not of what it is saying.
So the direction is a model that classifies on shape: packet size distribution, inter-arrival timing, burst structure, direction ratio, how a flow behaves across its first few dozen packets. Those features are cheap to extract in the kernel, because they are counters rather than content.
The useful part is that there is no cold-start problem. Every flow the deterministic classifier identifies confidently today is a labelled training example, produced for free as a side effect of doing its job. The signature-based classifier bootstraps the learned one, and the learned one covers the cases signatures cannot reach. Where the two disagree is the most valuable training data in the set.
Three commitments come with that, and we would rather state them than be asked. The learned classifier runs behind a confidence threshold with the deterministic path as fallback — a model that is not sure does not get to make the call. Latency-critical traffic stays exempt from model override, because a novel failure in a classifier should never be able to put a surgeon's video feed on the wrong link. And any fleet-wide learning has to be privacy-preserving by construction: statistical features and model gradients, never traffic.
Point the same machinery at links instead of flows and you get the other half of it. Link quality is a time series — latency, jitter, loss, throughput — and time series can be forecast. A network that can predict which path is about to degrade can move traffic before the degradation is something a person feels, rather than after. That is a later post, and it is the one I am most interested in, because the successful version of it is invisible.
A note on privacy
"Understanding your traffic" can sound invasive, so it's worth being precise. The system classifies on statistical and protocol-level characteristics — packet timing, packet sizes, handshake structure, destinations. It does not decrypt, and it does not store the contents of your sessions. It learns that a flow is a video call; it does not learn what was said on it. A routing decision doesn't require the payload, so the system is built not to have it.
The flip side deserves the same precision. Per-device, per-application attribution is genuinely sensitive data, whether the site is a household or a forward-deployed unit. Something that useful needs retention limits, access control, and a clear answer to who can see it. That's an engineering obligation, not a footnote.
This is one piece
Classification is what gives the network a vocabulary for its own traffic. The next post puts that vocabulary to work: now that we can name every flow, we can move them with precision — a single class, or a fraction of the load — instead of the all-or-nothing failover most systems are stuck with.
After that, the threads flagged above. Cost: knowing what your traffic is is not free, and we would rather publish the per-packet number than imply it is zero. Prediction: moving traffic off a path before it degrades rather than after. And enforcement: what it actually takes to turn a routing decision into an access decision, and what we would have to be able to prove before claiming one.
If a one-size-fits-all network is costing you call quality,
get in touch.
We'll show you what per-flow routing looks like in your environment.
Request a demo