| |||||||||||||
Essential, but not the first lineEssential, but not the first linePosted Sep 23, 2011 9:39 UTC (Fri) by cmccabe (guest, #60281)In reply to: Essential, but not the first line by njs Parent article: LPC: An update on bufferbloat
Penalizing high bandwidth users is kind of an interesting heuristic. It's definitely better than penalizing long connections, at least!
However, I think you're assuming that all the clients are the same. This is definitely not be the case in real life. Also, not all applications that need low latency are low bandwidth. For example video chat can suck up quite a bit of bandwith.
Just to take one example. If I'm the cable company, I might have some customers with a 1.5 MBit/s download and others with 6.0 MBit/s. Assuming that they all go into one big router at some point, the 6.0 MBit/s guys will obviously be using more than their "fair share" of the uplink from this box. Maybe I can be super clever and account for this, but what about the next router in the chain? It may not even be owned by my cable company, so it's not going to know the exact reason why some connections are using more bandwidth than others.
Maybe there's something I'm not seeing, but this still seems problematic...
(Log in to post comments)
Essential, but not the first line Posted Sep 24, 2011 1:30 UTC (Sat) by njs (guest, #40338) [Link]
Well, that's why we call it a heuristic :-) It can be helpful even if it's not perfect. A really tough case is flows that can scale their bandwidth requirements but value latency over throughput -- for something like VNC or live video you'd really like to use all the bandwidth you can get, but latency is more important. (I maintain a program like this, bufferbloat kicks its butt :-(.) These should just go ahead and set explicit QoS bits.
Obviously the first goal should be to minimize latency in general, though.
|
|||||||||||||