In message <Pine.NEB.4.53.0303111553210.4571@reva.sixgirls.org>,
John Klos writes:


>What IS the limiting factor in high packet rate DDoS attacks? I've spent a
>month under DDoS attacks which peaked at 200 Mbps. On a 350 MHz 604ev with
>a Realtek card, the system could only handle 30-40 mbps, or up to around
>80,000 SYN packets a second. A 933 MHz Pentium 3 system with a 3com card
>could only handle somewhere between 80-90 Mbps, or around 200,000 SYN
>packets.

First step is, replace the RealTek card.

Next question: are you actually concerned about NIC interrupt rate or
about processing the flood of SYNs? One of my pet wishes is for the
kernel to keep separate load ticks for hardware interrupts and
software interrupts. That way, systat could show whether the true
culprit was servicing hardware interrupts or running through IP/TCP code.


>Has anyone considered any sort of contingency plan for what a kernel can
>do when it has too much work to do? 

There were some interesting research papers on polling (rather than
interrupting) in the late 90s. FreeBSD has had polling support for
some drivers for some time. Of course this only helps the
hardware-interrupt load, not the IP/TCP protocol processing.

I think the best short-term approach is to rework the NIC drivers, to
autotune for higher throughput/high latency under extreme CPU load--
to where we build a standing ip_intrq.  When ip_intrq hits its limit,
it'll start dropping anyway.