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

[Mikael Abrahamsson <[e-mail]>]

On Wed, 13 Mar 2013, Fred Baker (fred) wrote:

> That depends on how FQ is implemented. The implementation I did in 1994 
> probably would have been high overhead. It has been minted by others, 
> and I believe rewritten to be a calendar queue implementation. For that, 
> I would not expect it was that much higher. I'll go take a look, though.

To be concrete, turning on fair-queue (and some other stuff to assure bw 
for certain tcp/port combinations) on a Cisco 7200 style device seems to 
give 2-3x CPU usage for the same traffic. This is with just 30-100 flows. 
This is in latest code available (15.2).

So since in my market we have gig speeds (we have low cost residential 
CPEs capable of moving ~600 megabits/s in a single tcp session), CPU 
impact of these queueing mechanisms is important.

And yes, I feel doing AQM at 100/100 speeds is still important, but here 
the limiting factor for speed might actually be the CPU of the CPE, so the 
queueing mechanism should preferrably be able to prioritize and gracefully 
handle the case where the links are not full but instead the CPE CPU is 
insufficient and that's what causing congestion/drops.

-- 
Mikael Abrahamsson    email: [e-mail]