User: Password:
|
|
Subscribe / Log in / New account

The CHOKe packet scheduler

The CHOKe packet scheduler

Posted Jan 13, 2011 22:50 UTC (Thu) by paulj (subscriber, #341)
In reply to: The CHOKe packet scheduler by marcH
Parent article: The CHOKe packet scheduler

Yes, buffer-bloat is just a plain bug. RED and CHOKe are means to tickle sender TCP's congestion control to activate in a more progressive fashion, which is more network friendly and less likely to cause those TCPs to synchronise (i.e. all back off at same time, and all ramp up again at same time) if congestion is applied uniformly to most flows. As the queue size increases above the min-threshold, the probability of dropping a newly arrived packet linearly increases, until it reaches 1 at the max-threshold.

The problem with fixing buffer-bloat is finding an economic justification for reducing buffers. Other than in quite high-rate routers, memory for buffering is generally cheap and there's little economic incentive to not over-spec buffers. The crux of the problem is that it is not entirely clera what the correct smallest size is. Indeed that optimal size may vary for different deployments. If you make the buffers too small, your router will under-perform - especially in benchmarks in high-bandwidth settings. Making them too large OTOH is unlikely to cost you sales: few people benchmark performance in real-world scenarios, with congestion - except network congestion researchers.


(Log in to post comments)

The CHOKe packet scheduler

Posted Jan 14, 2011 6:59 UTC (Fri) by marcH (subscriber, #57642) [Link]

> The crux of the problem is that it is not entirely clera what the correct smallest size is. Indeed that optimal size may vary for different deployments. If you make the buffers too small, your router will under-perform - especially in benchmarks in high-bandwidth settings. Making them too large OTOH is unlikely to cost you sales: few people benchmark performance in real-world scenarios, with congestion - except network congestion researchers.

Agreed that the exact *optimal* size is not clear. However this is not an excuse for unreasonable sizes that harm latency with NO throughput benefit.

This research topic is *not* new! This 2004 paper demontrates that just 1ms (!) is enough: http://portal.acm.org/citation.cfm?id=1015499

The CHOKe packet scheduler

Posted Feb 27, 2011 6:10 UTC (Sun) by gmaxwell (guest, #30048) [Link]

It's absolutely _trivial_ to demonstrate that 1ms is not unconditionally enough.

Take a long pipe with a several ms of delay. Run a single TCP flow across it. Observe that your flow gets nowhere near line rate, but instead it sawtooths against line rate and leaves the link idle for a significant amount of time.

Yes, a single flow is a corner caseĀ— but not not an outrageous one. The behavior also holds true for a small number of flows, especially if they experience identical end to end delays.

So there is the excuse you were missing.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds