The Four Walls of Rate Limiting: Why One Threshold Is Never Enough

The Blunt Instrument Problem

In the early days of network defense, rate limiting was a straightforward proposition: determine the maximum packets per second the application could handle, set a global threshold just below that number, and drop everything that exceeded it.

This approach is no longer functional.

When a modern volumetric assault hits a network protected by a single, monolithic rate limit, the system inevitably enters a state of indiscriminate dropping. The firewall does not distinguish between a spoofed UDP flood packet and a legitimate customer’s TCP SYN request; it merely sees that the global threshold has been breached and activates the drop policy. The attacker successfully achieves their objective — taking the application offline — not by overwhelming the server, but by forcing the defender’s own firewall to shut the door on legitimate users.

To defeat modern multi-vector campaigns, mitigation cannot be a single wall. It must be a progressive series of intelligent filters. Recognizing this, CoreEdge was engineered with a sophisticated 4-Tier Rate Limiting Architecture that evaluates and shapes traffic at four distinct levels of granularity simultaneously.

Wall 1: The Global Subnet Limit

The first layer of defense is the Macro tier. Before analyzing individual connections, CoreEdge evaluates the total volume of traffic destined for a specific protected /24 or /32 subnet.

This outer wall is designed to absorb the sheer brute force of catastrophic volumetric events — such as 100+ Gbps amplification floods. It utilizes an ultra-efficient token bucket algorithm implemented directly in the eBPF datapath. If a specific subnet is targeted by a volumetric blast that threatens the physical capacity of the upstream links, this macro limit engages. However, unlike legacy systems, this wall is only the beginning of the filtering process, designed solely to trim the absolute peak of the flood so the subsequent granular layers can perform their surgical inspection.

Wall 2: The Per-Rule Enforcement

Traffic that clears the global subnet limit then encounters the Policy tier. CoreEdge networks are protected by thousands of specific mitigation rules (e.g., “Allow gaming traffic on UDP 27015,” or “Inspect HTTP traffic on TCP 443”).

Each of these rules possesses its own independent rate-limiting bucket. This prevents a targeted attack against one specific service from degrading the performance of neighboring services. If an attacker launches a massive DNS flood against port 53, the Per-Rule rate limit for port 53 will engage and absorb the excess traffic. Meanwhile, traffic flowing to the HTTP service on port 443 remains completely untouched, operating well within its own independent bucket. This ensures strict operational isolation across protocols and services.

Wall 3: The Per-Source Penalty

The third wall shifts the focus from the destination to the origin. Advanced attacks frequently attempt to stay below global and per-rule thresholds by distributing their traffic across millions of botnet IPs, with each IP sending only a trickle of packets.

CoreEdge’s Per-Source layer tracks the precise packet velocity of every individual IP address communicating with the protected network. If a specific source IP begins behaving aggressively — generating requests faster than physically possible for a human user, or exhibiting the rhythmic pulsing characteristic of automated scripting tools — this specific source is dynamically rate-limited or dropped. This capability isolates the hostile nodes of a botnet without restricting access for legitimate users sharing the same destination rule.

Wall 4: The Protocol Defaults

The final, innermost wall is the Protocol Baseline. CoreEdge inherently understands the standard operational behavior of internet protocols.

Even if an attacker manages to spoof perfectly formed packets, distribute them broadly enough to evade the Per-Source limit, and target an allowed open port, they must still comply with mathematical protocol defaults. For example, ICMP (ping) traffic fundamentally requires vastly less bandwidth than HTTPS traffic. CoreEdge enforces strict, protocol-specific sane defaults at the foundational level. Any traffic profile attempting to force a protocol to behave outside of its mathematical baseline — such as attempting to push 10 Gbps of ICMP data — is instantaneously throttled based on these unyielding protocol profiles.

The Cumulative Effect

The power of the 4-Tier system lies not in any single wall, but in their simultaneous, progressive execution. A packet attempting to breach a CoreEdge-protected network is evaluated against the Global Limit, the Rule Limit, its Source Velocity, and its Protocol Baseline in a single, unified execution cycle taking less than 100 nanoseconds.

This multi-dimensional approach to rate shaping ensures that when an attacker attempts to overwhelm a network with sheer volume, CoreEdge does not respond with a blunt, indiscriminate block. It responds with a surgical, progressive reduction that systematically strips away the malicious traffic while preserving the clear path for legitimate users. It is the difference between pulling the plug on your network, and intelligently disarming the attack packet by packet.