why upload with adsl is faster than 100M ethernet ?

Fri Oct 15 15:58:57 UTC 2004

--On 15 October 2004 11:46 -0400 Andy Dills <andy at 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