Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt

[Mikael Abrahamsson <[e-mail]>]

On Wed, 13 Mar 2013, Andrew McGregor wrote:

> A Netgear WNDR3800 (680MHz MIPS) can handle fq_codel on two flat out 
> 802.11n interfaces at the same time and still be very lightly loaded. 
> CPU is not a problem because fq_codel is a tiny fraction of the usage of 
> the firewall, connection tracking and 802.11 AP code, all of which are 
> necessary (in IPv4 the NAT also uses more CPU than fq_codel).

I'll have to look into what devices we're using and what CPUs they're 
using. The WNDR3800 seems to be a fairly high end device when I look at 
the price point.

However, the other part of your reply sounds hopeful. I read 
draft-nichols-tsvwg-codel-01 and I now realise that yes, it shouldn't be 
too cpu intensive as the hashing into bins sounds efficient on a 
per-packet level.

Would having multiple bin "trees" increase CPU usage a lot? I'm thinking 
of the use case where there are 10 computers in the home, of which one is 
doing 100 upload TCP sessions (bittorrent). If there was some mechanism 
that could identify a source IP address that caused most of the congestion 
and put them in a separate bin "tree" (basically each source IP would get 
its own set of bins, up to a maximum of perhaps 16 trees) and then these 
sets of bins would be emptied in a round-robin fashion (MDRR perhaps?). Or 
perhaps there would just be a "high volume speaker" tree and a "low volume 
speaker" tree, and it would be enough to just MDRR between these two 
trees. I realise we're now into "flow" territory which is exactly what 
Codel doesn't need to bother with currently, but just checking...

I saw in ICCRG that some testing was done with LEDBAT which I would 
imagine would help for the bittorrent case, but what about trying to 
achieve some of that without needing LEDBAT by using the above technique?

-- 
Mikael Abrahamsson    email: [e-mail]