Measurements

To measure the performance of IPRateMonitor, a simple Click configuration was run in a Linux kernel 2.2.16 on an off-the-shelf PC (700 Mhz Pentium III, 256 KB cache, 256 MB memory) that sends packets through an IPRateMonitor element. Bogus UDP packets were generated by Click itself to avoid time consuming interaction with network interfaces. IP spoofing attackers were simulated by generating UDP packets with an IP source address picked from a fixed set of IP addresses in round-robin fashion. Measurements were done for different memory limits and for an expand threshold of 0, i.e., maximum expansion.

Figure 5: Packet rate as a function of memory limit

The graph in Figure 5 shows the number of packets that IPRateMonitor can handle as a function of its imposed memory limit. The graph shows this for 5 UDP flood attacks that differ only in the number of attackers (i.e., IP source addresses) involved. The IP source addresses used in the malicious UDP packets constitute a worst-case scenario (see Section 5.4).

The graph shows that IPRateMonitor performs better when it has little memory at its disposal. A small tree fits in cache entirely and is, therefore, fast. When more memory is available, the tree size increases up to the point where it is too big to fit in cache, and cache misses result. The performance of IPRateMonitor for 256, 512, and 1024 addresses is roughly the same (270,000 packets/sec), because in these cases the tree is small enough to fit in cache entirely. For 2048 and 4096 addresses, rates drop proportional to the total memory consumption of the tree, up to the point where the tree reaches its maximum size, after which memory consumption--and thus performance--fluctuates around the same point.

Figure 6: CPU cycles per packet as a function of memory limit

The graph in Figure 6 shows the number of CPU cycles that IPRateMonitor consumes per packet as a function of its imposed memory limit. IPRateMonitor consumes more CPU cycles when it has more memory at its disposal. These extra cycles are, most likely, spent on waiting for a memory fetch after a cache miss. Unsurprisingly, the graph in Figure 6 is essentially the reciprocal of the graph in Figure 5.

IPRateMonitor performs better when it has little memory at its disposal. Unfortunately, its ability to expand and, therefore, to precisely determine the source(s) and/or target(s) of the attack, is also more limited. Thus, the tradeoff is precision vs. performance.