Understanding DDoS Capacity: Gbps, Mpps and the Questions That Matter
Large capacity figures alone say little about protection for your services. Compare bandwidth, packet rate, measurement conditions and the agreed service scope.
When choosing DDoS protection, you will encounter large numbers: terabits per second, millions of packets or requests. These describe different kinds of load. An investment decision also requires a connection to your access service, applications and agreed protection scope.
Three metrics answer three different questions
- Gbps describes the amount of data transferred each second. It helps characterize the load on a transmission path.
- Mpps means millions of packets per second. It describes the number of individual packets that need processing.
- Requests per second describes application operations. A login attempt and a small static file download can create very different amounts of work despite similar data volumes.
DDoS can consume bandwidth, packet-processing capacity or application resources. RFC 4732 describes these different bottlenecks. A high bandwidth figure therefore does not automatically establish how a service will handle many small packets or expensive requests.
RFC 4732: different resources as denial-of-service targets
A calculation makes the difference visible
Assume one million IP packets per second, each containing 1,000 bytes. The calculated data rate is 8 Gbps: 1,000,000 × 1,000 × 8. At 100 bytes per IP packet, the same packet rate produces 0.8 Gbps. This deliberately excludes Ethernet overhead and other transmission components. The example is not a measurement of AS51202.
The packet rate is identical in both cases, while the data rate differs by a factor of ten. Compare values only when packet size and measurement point are defined consistently. RFC 2544 uses different frame sizes to characterize network devices; one test case does not describe their entire performance.
RFC 2544, Section 9: frame sizes in device benchmarks
A network total is not a commitment for one connection
The sum of capacity across multiple locations, the capacity of a filtering platform and the bandwidth of your connection have different scopes. A worldwide total cannot therefore be read as guaranteed protection for a particular prefix. Similarly, the largest documented attack is an observation under specific conditions, rather than a commitment covering every future event.
Create a separate comparison row for each claim: metric, geographical scope, measurement method and contractual meaning. An empty field identifies a useful follow-up question. This gives technical and commercial stakeholders a shared interpretation of each number.
Five questions to ask about a proposal
- 1Which service, prefix and location does the figure apply to?
- 2Is it total installed capacity, an observed measurement or an agreed service commitment?
- 3Which packet sizes, protocols, time intervals and simultaneous loads were considered?
- 4How were successful user requests or sessions checked while the load was present?
- 5Which limits, customer responsibilities and escalation procedures apply to my specific order?
Choose evidence that matches the service outcome
For a game server, the important outcome may be that new players can join and existing sessions continue. For a customer portal, it may be a completed login. Agree these criteria before evaluating results. A chart of discarded packets provides only part of the answer.
Plan the right kind of test
A functional check and a capacity benchmark have different purposes. RFC 2544 overload tests belong in isolated environments; RFC 6815 explicitly warns against their use on production networks. Agree the scope and environment of a protection test with the operators involved.
RFC 6815: limits of RFC 2544 testing on production networks
For a discussion with AS51202, prepare a short description of your services, typical peaks and any available attack reports. These provide a starting point for discussing the required protection scope and recording it in the proposal.