[Bloat] Some updates on hacking on AQMS

[Dave Taht]

On Fri, Jun 24, 2011 at 3:10 AM, Dave Taht <dave.taht at gmail.com> wrote:
> On Thu, Jun 23, 2011 at 11:01 PM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
>> Once qdisc queue is _full_, its too late, you have to drop packets
>> anyway. And its not because at least one flow is not responsive :
>> It might be because one thousand flows began their life at the very same
>> moment :(

Oh, and while I'm touching upon this subject, by default openwt
enables 'syn flood support', which (by default) rate limits syn
attempts to 25/second, bursting to 50, dropping new attempts long
before they can introduce the TCP mice problem, and introducing long
retries for the re-attempted connections.

That's not bandwidth or workload relative, or related to the number of
users, but a flat limit.

While the syn flood rate is configurable (and I've either disabled it
entirely or bumped it up a lot in my own testing - it's easy to see if
you try to, say, access the top 100 web sites all at once - try 100,
see 50 fail..... retry 50, see 25 fail...) ...

Arbitrarily dropping syn attempts at a level well below what a single
browser can introduce today has a dramatic effect on perceived
performance and latency.

This again points to the need for in depth knowledge of what packets
are being dropped, where, why, and when, when evaluating the behavior
of todays networking subsystems. I'm looking forward to being able to
analyze packet drops extensively in the future with the packet drop
analysis tool recently discussed here.

No doubt other routers, gateways and firewalls are making similarly
desparate attempts to smooth the flow of traffic above and beyond the
basic effects of the qdiscs.

by default Openwrt also clamps MSS... blocks icmpv6 'etoobig' messages
to internal networks... and limits 6in4 ipv6 mtu to 1280.

In addition to all the other heroic measures being done elsewhere in
the networking subsystems (forget about wireless for a bit... cable
modems often do synack optimization as one example, and a recent paper
by cablelabs pointed to overbuffering in most modems incorrect by an
order of magnitude) it would be good to have a clearer picture of what
is REALLY going on before making any clear determinations as to the
real effacy of any qos subsystem.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com