TCP congestion control and large router buffers

Sam Stickland sam_mailinglists at spacething.org
Tue Dec 21 19:21:58 UTC 2010


On 21 Dec 2010, at 07:18, Mikael Abrahamsson <swmike at swm.pp.se> wrote:

 On Mon, 20 Dec 2010, Jim Gettys wrote:

Common knowledge among whom?  I'm hardly a naive Internet user.


Anyone actually looking into the matter. The Cisco "fair-queue" command was
introduced in IOS 11.0 according to <
http://www.cisco.com/en/US/docs/ios/12_2/qos/command/reference/qrfcmd1.html#wp1098249>
to somewhat handle the problem. I have no idea when this was in time, but I
guess early 90:ties?


200ms is good; but it is often up to multiple *seconds*. Resulting latencies
on broadband gears are often horrific: see the netalyzr plots that I posted
in my blog. See:


I know of the problem, it's no news to me. You don't have to convince me.
I've been using Cisco routers as a CPE because of this for a long time.


Interestingly I've just tried to enable WRED on a Cisco 877 (advsecurity
15.1) and the random-detect commands are missing. Cisco's feature navigator
says it's supported though. Weird.

Also, there doesn't appear to be a way to enable fair-queue on the wireless
interface. Is fair-queue seen as a bad strategy for wireless and it's
varying throughput/goodput rates?

And finally it doesn't support inbound shaping so I can't experience with
trying to build the queues on it rather than the DSLAM.

I'm a little nonplussed to be honest.

However, I did notice the output queue on the dialler interface defaults to
1000 packets. (Perhaps that's a hangover from when it had to queue packets
whilst dialling? I've come too late to networking to know). Reducing that
number to 10 (~60ms @ 1500 bytes @ 8Mbps) has noticeably increased the
latency response and fairness of the connection under load.

Sam



More information about the NANOG mailing list