nanog mailing list archives
Re: why upload with adsl is faster than 100M ethernet ?
From: Alex Bligh <alex () alex org uk>
Date: Fri, 15 Oct 2004 16:58:57 +0100
--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
Current thread:
- Re: why upload with adsl is faster than 100M ethernet ?, (continued)
- Re: why upload with adsl is faster than 100M ethernet ? Jay Hennigan (Oct 14)
- Re: why upload with adsl is faster than 100M ethernet ? Joe Shen (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Iljitsch van Beijnum (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Joe Shen (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Iljitsch van Beijnum (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Alex Bligh (Oct 15)
- RE: why upload with adsl is faster than 100M ethernet ? Mike McSpedon (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Gordon (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Marc Binderberger (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Andy Dills (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Alex Bligh (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Andy Dills (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Alex Bligh (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Alexei Roudnev (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? sergei (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Joe Shen (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Jay Hennigan (Oct 14)
- Re: why upload with adsl is faster than 100M ethernet ? Marc Binderberger (Oct 15)
- Re: why upload with adsl is faster than 100M ethernet ? Jay Hennigan (Oct 15)