| |||||||||||||
Bufferbloat: Dark Buffers in the Internet (ACM Queue)Bufferbloat: Dark Buffers in the Internet (ACM Queue)Posted Dec 6, 2011 1:42 UTC (Tue) by dlang (✭ supporter ✭, #313)In reply to: Bufferbloat: Dark Buffers in the Internet (ACM Queue) by Lennie Parent article: Bufferbloat: Dark Buffers in the Internet (ACM Queue)
any time you have chokepoints where the bandwidth changes drastically, you are going to have problems
right now, you can have 1Gb wired network going to a <1Mb DSL upload rate. The machine connected to the 1G wired network has no way of knowing that the system that it's talking to is on the other side of such a slow connection, and so it needs to have large enough buffers to talk to another system connected to a 1Gb network. As the data trickles out over the 1Mb network you have horrible performance.
1Gb is only now taking over in home networks from 100Mb, I don't expect to see 10Gb on very slow networks like this for quite a while yet.
10Gb in the datacenter is a good thing for communications within the datacenter. having 1Gb of connectivity from the datacenter to the Internet is far from being unheard of, and 100Mb is touching the range of the high-end home user, even the 100Mb connection is less of a speed ratio than the home user 1Gb to 1Mb transition.
but a fixed transition like this is not _that_ hard for the routers to deal with. what absolutely kills things is where a wireless network may be anywhere from 300Mb/sec to under 1Mb/sec, and may vary within this range within the length of a single session, adapting to that is extremely hard.
(Log in to post comments)
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Dec 6, 2011 15:17 UTC (Tue) by marcH (subscriber, #57642) [Link]
> right now, you can have 1Gb wired network going to a <1Mb DSL upload rate. The machine connected to the 1G wired network has no way of knowing that the system that it's talking to is on the other side of such a slow connection, and so it needs to have large enough buffers to talk to another system connected to a 1Gb network. As the data trickles out over the 1Mb network you have horrible performance.
Not a problem as long as the 1Mb link does not let the queue build up and does drop packets.
Throughput is not the problem, latency is.
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Dec 12, 2011 13:55 UTC (Mon) by ekj (guest, #1524) [Link]
Yes, but the existence of *wildly* varying bandwiths, force queue-management.
A 10Gbit capable device, can have 10MB worth of buffer, and still transmit the entire buffer in 10ms, which is low enough that it could probably behave well with no queue-management.
If such a 10MB buffer ends up holding data that trickles out over a 1mbps link though, it'd take a *minute* for the buffer to empty, i.e. completely unusable.
At the same time, the 5kB buffer that may be reasonable for a 1Mbps link, is clearly much too small for a 10Gbit link.
In short, when link-speed varies a *lot* there is no correct buffer-size, instead you MUST actively manage your buffers, using some sort of AQM, which today most routers and devices do not, infact, do.
"does not let the queue build up" is the key phrase here. More specifically, does not let the queue for any one outgoing link grow beyond what can (probably) be transmitted over the next few milliseconds on that specific link, without dropping a packet or two as a signal that congestion is occuring.
wireless is a special challenge: just because that link is 5mbps this moment, doesn't mean it won't be a lot less 20ms from now, and if a packet is lost, you don't know if it was congestion or noise - and the apropriate response to high-noise-low-traffic is exactly the opposite response to low-noise-high-congestion.
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Dec 12, 2011 15:34 UTC (Mon) by marcH (subscriber, #57642) [Link]
> If such a 10MB buffer ends up holding data that trickles out over a 1mbps link though, it'd take a *minute* for the buffer to empty, i.e. completely unusable.
This keeps coming... why would the 1Gb/s link hold the data on behalf on the 1Mb/s link?
Plug the modem - get the problems... Posted Dec 12, 2011 15:46 UTC (Mon) by khim (subscriber, #9252) [Link] This keeps coming... why would the 1Gb/s link hold the data on behalf on the 1Mb/s link? Buy modem, attach to computer, get the problem. Computer only know about 1GBit link to the modem and so allocates 1MB buffer, router only gets 1Mbit because your line is not ideal... instant 1000x impedance mismatch.
Plug the modem - get the problems... Posted Dec 12, 2011 15:55 UTC (Mon) by marcH (subscriber, #57642) [Link]
> instant 1000x impedance mismatch.
Not the problem.
What's happening here is bufferbloat inside *the modem*; NOT inside the computer. Make the modem adjust its queue size depending on the speed of each outgoing link and your problem is solved.
The problem is the modem having the same buffer size on every link (the buffer is probably even shared across the links). Simple laziness from the designers.
Plug the modem - get the problems... Posted Dec 12, 2011 15:57 UTC (Mon) by marcH (subscriber, #57642) [Link]
> What's happening here is bufferbloat inside *the modem*; NOT inside the computer.
... unless you have Ethernet flow control enabled, in which case you might have bufferbloat in BOTH places because of backpressure! Disable flow control right now since it's not compatible with Van Jacobson congestion control.
Plug the modem - get the problems... Posted Dec 16, 2011 2:47 UTC (Fri) by quanstro (guest, #77996) [Link]
ethernet flow control, at least through switches, makes
tcp-style flow control work better! at least that's been my experience.
ethernet flow control Posted Dec 16, 2011 16:57 UTC (Fri) by marcH (subscriber, #57642) [Link]
Your mileage may vary. The effect of Ethernet flow control depends on a wide range of parameters.
Ethernet flow control is effectively chaining queues across devices. Since the aggregated queue is bigger I can see how it *may in some cases* enhance TCP throughput. But it will obviously make any existing bufferbloat even worse.
Most importantly, Ethernet flow control will create HOL blocking.
Your mileage may vary.
Some old musings with Ethernet flow control: http://marc.herbert.free.fr/noq/
Bufferbloat: Dark Buffers in the Internet (ACM Queue) Posted Dec 12, 2011 15:47 UTC (Mon) by marcH (subscriber, #57642) [Link]
> wireless is a special challenge: just because that link is 5mbps this moment, doesn't mean it won't be a lot less 20ms from now,
Is wireless link speed varying that fast that you cannot adjust your queue size accordingly with (again) results not good enough for scientists but decent enough for engineers and end users? This is a genuine question.
Surely when sitting at your desk your link does not keep jumping from 100Mb/s to just 1Mb/s several times per second, does it?
> and if a packet is lost, you don't know if it was congestion or noise - and the apropriate response to high-noise-low-traffic is exactly the opposite response to low-noise-high-congestion.
Yes, dropping packets is a very poor congestion signal. A LOT has been said about this already. Is it really related to bufferbloat? I do not think so. It was a concern a long time before anyone noticed bufferbloat, and for sure it will still be a concern a long time after bufferbloat is fixed (if ever...) I can imagine that the two can interact badly with each other however, this does not prevent working on and fixing the two problems independently of each other.
|
|||||||||||||