--On 15 October 2004 11:46 -0400 Andy Dills <andy@xecu.net> wrote:
Hmm...I'd have to disagree. Are you perhaps assuming a certain threshold (>100mbps, for instance)?
I use rate limiting for some of my customers, and when correctly configured (you _must_ use the right burst sizes), you will get the exact rate specified, TCP or not. However, I've never had to rate-limit above 30mbps, so perhaps you have some experience that I don't.
I can support what Iljisch said. In a former life I ran extensive tests on the effect of CAR on TCP (no longer have the data to publish, but it's out there), and it's "just plain broken" - if your purpose is to simulate a lower amount of bandwidth with or without a burst. In a nutshell the problem is that the sliding window algorithm expects RTT to gradually increase with congestion, to find the optimum window size - the increased RTT stops the window growing. With rate-limiting that does not also shape (i.e. buffer the packets - this is true of token based systems such as CAR), the window size just keeps on expanding in leaps and bounds until there's a packet drop, whereupon it shrinks right down, rinse and repeat, so you get a sawtooth effect. Adding burst sizes just moves the problem around - you don't see the effect until later in the stream - because the excess of traffic over committed rate just sits there using up the burst and there is no signal to slow down; it /somewhat/ hides the effect in a lab if you are using short single requests (e.g. short HTTP) but not if you aggregate multiple parallel requests. If you want to simulate lower bandwidths through a high bandwidth interface, and you want to be TCP friendly, you HAVE to use shaping. That means buffering (delaying) packets, and at gigabit line rates, with multiple clients, you need BIG buffers (but set sensible buffer limits per client). You can reasonably trivially do the above test with ftp, ethereal, a bit of perl, and something to graph sequence numbers and throughput. There certainly used to be very few devices that did this properly, AND cope with a saturated GigE of small packet DDoS without dying spectacularly. This may or may not have changed. Alex