A Terabit Is Not a Terabit: What DDoS Capacity Numbers Actually Mean

The DDoS industry has largely standardized on one number for describing mitigation capacity: terabits per second.

It is an understandable metric. Transit is purchased in bits per second, interfaces are sold in gigabits, and aggregate bandwidth is easy to calculate. Add the capacity of every port in the network and the result fits neatly on a product page.

The problem is that it does not tell you how much attack traffic a network can actually mitigate.

A 1 Tbps flood of full-sized Ethernet frames is roughly 81 million packets per second. The same 1 Tbps composed of minimum-sized frames is roughly 1.49 billion packets per second. Both consume one terabit of bandwidth. One requires the dataplane to process more than eighteen times as many packets.

And packet rate is only one additional constraint.

Where the traffic enters, how much capacity exists at that location, how it is distributed between carriers, what the filtering dataplane can process, how much clean traffic still needs to leave, and how much headroom remains after a failure all affect the amount of capacity that is actually usable.

So when we say Wirescope is designed to mitigate attacks above 1 Tbps in-house, the qualifier matters.

A terabit is not a workload. It is one dimension of one.

One terabit, eighteen times the packet rate

Forwarding hardware does not make decisions on a continuous stream of bits. Many of the operations that matter happen once per packet: parse headers, perform lookups, evaluate policy, update counters or state where required, and decide whether to forward or discard the packet.

The amount of useful data inside that packet can vary enormously.

Once Ethernet framing overhead is included, the difference becomes easy to see:

The bandwidth at the top and bottom of the table is identical.

The packet-processing requirement is not.

That distinction matters because a platform can have enough interface capacity to receive an attack while reaching a packet-processing limit well before those interfaces are full.

A mitigation system that performs comfortably at hundreds of gigabits of large amplification traffic may behave very differently when presented with the same bandwidth in minimum-sized packets.

This is why a useful capacity figure needs both Gbps and pps.

A smaller attack can be a harder attack

The same arithmetic also works in reverse.

Consider a 1 Tbps flood of 1,518-byte Ethernet frames. That is approximately 81 million packets per second.

Now consider 100 million minimum-sized packets per second.

On the wire, the second attack is only about 67 Gbps.

Measured purely by bandwidth, the first attack is almost fifteen times larger. Measured by packet rate, the second requires more per-packet processing.

If those packets are also intended to create connection state, trigger application behaviour, or exercise some other resource beyond basic forwarding, the operational difference can become larger still.

That does not make 67 Gbps universally "harder" than 1 Tbps. Different vectors stress different parts of the system.

It does demonstrate why a statement such as "we mitigated a 1.2 Tbps attack" is incomplete without more information.

How many packets per second were involved? What was the packet distribution? Did filtering require connection state? How many destination addresses were targeted? Where did the traffic enter the network?

Those details determine which resources were actually being tested.

Aggregate capacity is not usable capacity

Packet rate is only part of the problem.

The other major issue with headline capacity figures is that they are usually aggregate figures.

Suppose a provider operates 600 Gbps of external capacity in Virginia, 600 Gbps in Frankfurt, and 600 Gbps in Amsterdam. It can accurately say that its network has 1.8 Tbps of aggregate connectivity.

That does not mean 1.8 Tbps is available to defend a customer whose traffic enters primarily in Virginia.

Attack traffic does not arrive at an aggregate number. It arrives over specific paths, into specific locations, according to BGP and the networks from which the traffic originates.

Unused capacity on another continent is not automatically interchangeable with capacity at the constrained edge.

Transport can move traffic between locations, and routing policy can influence how traffic enters a network, but neither makes geographically separated capacity perfectly fungible.

This is why we think capacity should be understood at the relevant ingress, not just across the fleet.

The same principle applies within a location.

Four 400GbE interfaces give a network 1.6 Tbps of physical port capacity. But those ports may not be equally useful during a particular attack. They may connect to different carriers, receive very different traffic distributions, share another internal bottleneck, or need to retain capacity for ordinary production traffic and failure scenarios.

Adding the labels on the optics is easy.

Determining how much of that capacity can be relied upon during an incident is the more important calculation.

The smallest relevant bottleneck sets the limit

There are several different figures that are often collapsed into "mitigation capacity":

Physical port capacity is the sum of the interfaces installed in the network.

Upstream capacity is the amount of traffic the network can actually exchange with carriers and peers under its commercial and physical arrangements.

Filtering capacity is the rate at which the mitigation dataplane can classify and act on traffic.

Ingress capacity is what is available on the paths through which a particular customer's traffic actually enters.

Clean egress capacity is what remains available to deliver legitimate traffic after filtering.

Failure capacity is what remains when an interface, carrier, transport path, or other significant component is unavailable.

None of these figures is sufficient independently.

Effective mitigation capacity is bounded by the path traffic takes through all of them.

A network with several terabits of upstream connectivity and an undersized filtering layer has a filtering problem.

A network with an enormous filtering platform behind a constrained transit edge has an ingress problem.

And a network that can absorb the attack but cannot reliably deliver the clean traffic has not solved the customer's problem.

Not every DDoS attack is a bandwidth attack

Bits per second and packets per second are the two easiest dimensions to quantify, but they are not the only resources an attacker can target.

Connection state

A SYN flood, or another attack that causes state to be created, may be aimed at exhausting connection tables, memory, or new-connection processing rather than saturating a link.

The relevant limits may therefore be measured in connections per second or concurrent state entries rather than Gbps.

Source cardinality

A policy that is inexpensive to enforce against a relatively small number of sources may behave differently when the same traffic is distributed across hundreds of thousands or millions of addresses.

The bandwidth can remain unchanged while the amount of state or classification work increases substantially.

Destination distribution

Carpet-bombing attacks distribute traffic across many addresses in a prefix rather than concentrating the flood on one destination.

Per-host thresholds that work well against a conventional single-target flood can become much less useful when no individual address appears exceptional.

The important capability becomes visibility and policy across the prefix as a whole.

Fragmentation

Fragmented traffic introduces another set of decisions.

Depending on the protocol and mitigation policy, fragments may be classified, dropped, normalized, tracked, or reassembled. Each approach has different processing and state implications.

Again, those costs do not appear in a bandwidth number.

This is why there is no single benchmark that represents every attack a mitigation platform can encounter.

Headroom is part of capacity

Another number missing from most public capacity figures is how much of the network is already in use.

A network running its links near saturation may have impressive installed capacity and very little capacity that can safely be used during an incident.

Operational headroom matters because attacks do not occur under ideal conditions.

A carrier can fail during an event. Routing can shift unexpectedly. Multiple customers can be attacked simultaneously. A traffic engineering decision can move hundreds of gigabits from one path to another.

Rerouting only helps if the destination path has somewhere for the traffic to go.

For that reason, we consider deliberate headroom part of the mitigation platform rather than wasted capacity.

It also means the theoretical maximum that can be pushed through a network is not necessarily the amount that should be sold.

There is an important difference between maximum demonstrated throughput and capacity that can responsibly be committed to production customers.

We care much more about the second.

Ask what remains after something fails

A useful way to evaluate a mitigation network is to change the question.

Instead of asking:

How much capacity do you have?

Ask:

How much capacity do you have after your largest relevant path disappears?

Interfaces fail. Optics fail. Carriers have outages. Fiber is cut. Maintenance occurs.

If the advertised number assumes every component remains available simultaneously, it describes the network's best case rather than its operating condition.

No practical architecture can make every failure irrelevant, but failure states should be part of capacity planning.

The redundancy behind a terabit often matters more than the terabit itself.

Routing determines where capacity is useful

Even with sufficient physical capacity, DDoS traffic rarely distributes itself evenly.

BGP determines how traffic reaches the network, and that distribution varies according to source networks, route propagation, carrier relationships, local preference, and interconnection topology.

Two mitigation providers with the same amount of installed capacity can therefore experience the same attack very differently.

One may receive the event across several well-provisioned paths. Another may receive the majority through a single constrained interconnection.

Carrier diversity is useful partly because it increases bandwidth, but more importantly because it creates additional paths and additional options for traffic engineering.

The quality and behaviour of those interconnections matter as much as the number of carrier logos attached to them.

This is also why capacity planning at Wirescope is tied closely to routing. Capacity that cannot be placed on the path where it is needed is much less useful than its headline number suggests.

What Wirescope actually has

With that context established, we can describe Wirescope v1 more precisely.

Three core locations

Wirescope currently operates three core metros: Ashburn, Frankfurt, and Amsterdam.

Our footprint includes Equinix DC2 and CoreSite VA1 in Ashburn, Equinix FR4 in Frankfurt, and Nikhef, Equinix AM3, and Digital Realty Science Park in Amsterdam.

We describe those as three core locations because they represent three geographic ingress regions. Counting every facility separately would make the network sound larger without meaningfully changing where an attack can enter.

Our current and planned footprint is published on the PoP roadmap.

Multiple 400GbE upstream interfaces

Each location is built around multiple 400GbE upstream interfaces.

Wirescope's current carrier blend includes Zayo, GTT, and RETN, with Arelion and NTT planned as part of v2.

A single 400GbE interface has a theoretical line rate of roughly 595 million 64-byte packets per second.

That is useful context for understanding the scale of the physical edge, but it is not itself a claim that every component behind that interface can filter 595 Mpps under every policy.

The port is one component of the system.

More than 1 Tbps in-house

Our own edge is designed to handle attacks exceeding 1 Tbps in-house, depending on the attack vector and where the traffic enters the network.

That qualifier is intentional.

A terabit of large amplification responses is not equivalent to a terabit of minimum-sized packets. A terabit arriving across several paths is not equivalent to a terabit concentrated through one. A stateless flood is not equivalent to an event designed to exhaust connection state.

We therefore do not treat "1 Tbps" as a universal guarantee that ignores the workload behind it.

It describes the scale at which the v1 architecture has been designed to operate using Wirescope's own edge.

A volumetric backstop beyond the edge

For events where continuing to absorb the entire flood locally no longer makes operational sense, Cloudflare provides an additional volumetric backstop.

That is an additional layer rather than part of the capacity we describe as in-house.

From the customer's perspective, the relationship remains with Wirescope. It does not introduce per-prefix pricing, require DNS migration, or remove control over BGP.

Capacity with deliberate headroom

We also purchase and operate capacity with headroom rather than designing around the assumption that every interface can remain heavily utilized during normal operation.

Traffic can be steered at the prefix level using the same BGP communities exposed to customers.

That gives us the ability to change how one network is handled during an incident without treating the entire customer base as a single routing object.

Why we do not lead with an aggregate Tbps number

We could add every external interface across every Wirescope location and publish the result.

It would be a larger number.

It would also be less useful.

Ports in Amsterdam do not automatically increase the amount of traffic an Ashburn deployment can receive. Filtering capacity and upstream capacity are not interchangeable. Capacity reserved for failure headroom should not be presented as though it is permanently available to one customer.

And every time we installed another port, the number would increase whether or not anything had changed for the customer reading it.

For those reasons, we do not use a single fleet-wide Tbps figure as the primary description of Wirescope's mitigation capability.

For larger deployments, we would rather provide the specific numbers that matter: available capacity at the relevant ingress, packet-rate characteristics, path diversity, failure behaviour, and the point at which additional mitigation layers become involved.

Under NDA, that conversation can extend to dataplane architecture and available capacity by location.

Better questions to ask a mitigation provider

If you are comparing mitigation networks, the headline Tbps figure is a reasonable place to start. It should not be where the evaluation ends.

Ask what capacity exists in the locations where your traffic will actually enter.

Ask for the corresponding packet rate, particularly for minimum-sized packets.

Ask what happens after the largest relevant carrier or interface fails.

Ask how much capacity is normally reserved as operational headroom.

Ask how the platform handles attacks distributed across an entire prefix, rather than a single destination.

Ask what happens when the limiting resource is connection state rather than bandwidth.

Ask whether attack traffic is billed and whether that changes at particular thresholds.

And if a provider offers a leakage or availability commitment, ask exactly where it is measured.

Those answers describe a deployment.

A single capacity figure describes only one dimension of it.

Test the deployment, not the marketing number

Ultimately, mitigation capacity is testable.

Put a representative workload behind the network. Establish an agreed measurement point. Generate or observe realistic attack conditions. Measure what reaches the origin while mitigation is active.

Look at legitimate packet loss, latency, jitter, attack leakage, convergence, and behaviour when paths change.

That tells you considerably more about a mitigation service than comparing two aggregate numbers on a pricing page.

You can start a trial or talk to an engineer about the capacity available for a specific deployment.

For organizations planning to build services on top of Wirescope, our founding partner programme is also open during v1.

A terabit is still a useful measurement.

It just is not, by itself, a description of a mitigation network.