What is buffer bloat

[Mr fncypants]

How does it affect you?

[kevo]

bufferbloat occurs when a network link becomes congested, causing packets to become queued in buffers for too long. In a first-in first-out queuing system, overly large buffers result in longer queues and higher latency, but do not improve network throughput and may even reduce goodput to zero in extreme cases.

[r8rs4lf]

Can we get that in English? Haha

[Zestroy]

Hi,

 

Let Google be your friend...

 

After realizing the speed/bufferbloat test on dslreports, I took my bufferbloat grade from F to an A.

I'm using Motorola SB6141 > Nighthawk R7000 > Netduma R1.  I downloaded a custom Asuswrt-Merlin & Xwrt-Vortex firmware to the Nighthawk. It allows me to control bandwidth in order to significantly reduce bufferbloat. 

I set upload and download to slightly less than my actual speeds. The small bandwidth sacrifice is absolutely worth having a lower ping at load.

 

 

 

 

I expect a similar result might be realized using just the Congestion Control settings integrated in the Netduma R1.

I run 2.4 and 5GHz wireless networks from the Nighthawk thus the additional device.  

[procreate]

bufferbloat is similar to cars on road systems when work lets out, or in the morning on the way in... simplified.

[Zennon]

When users are using the network to max capacity your pings will find it hard to make it way through as their is a flood of packets in the way (bloating)

 

Using the Netduma's congestion control sliders leaves a percentage of spare bandwidth for the pings to pass all the other network traffic with no interruptions.

[Mr fncypants]

A couple of tests I ran had poor buffer bloat that's why I asked. Don't know why that happened. I have a dedicated modem to my Duma.

[Akic]

The real issue with buffer bloat is network devices with buffers that are too large.  TCP was designed to drop packets when congestion is high unfortunately network device manufacturers thought it would be a good idea to make larger buffers to store queued packets rather than drop them which results in latency as packets wait to get out of the buffer.

 

It's actually better to drop and retransmit a packet rather than queue it which is how it's suppose to work.

[FQs19]

The real issue with buffer bloat is network devices with buffers that are too large.  TCP was designed to drop packets when congestion is high unfortunately network device manufacturers thought it would be a good idea to make larger buffers to store queued packets rather than drop them which results in latency as packets wait to get out of the buffer.

 

It's actually better to drop and retransmit a packet rather than queue it which is how it's suppose to work.

100% This ^

[procreate]

http://www.bufferbloat.net/projects/bloat/wiki/introduction

 

this explains it fairly simply and easily for most people to understand. you can see this IRL if you have ever been to LA and driving on their highways, they have put stoplights on the access ramps to control congestion on the highway.

 

and no, you dont want to JUST drop packets if you have congestion. that will only increase your time as it has to retransmit and gets put to the back of the line again if no acknowledgement is received [also resulting in even more latency]. the issue with bufferbloat and large queues is that important time sensitive packets are treated the same as unimportant ones, which is where QoS comes into play. basically the FIFO is bypassed with more important sources so that large buffer can hold stuff like web page access or email checks while stuff like VOIP, streaming, gaming etc that have more real time implications can bypass the large queue. the car analogy of that would be the HOV lanes or local lanes that allow more important cars to maintain their higher speeds and reach destination more quickly. this works for home networks due to the ability to decide what is important and what isnt... bloat past your IP is something else entirely.

[Akic]

Have to disagree, dropping packets is by far the superior choice, the latency these gigantic buffers cause far outweighs any retransmission time.

 

TCP wasn't designed to have these large buffers, the packets should be dropped, it's in the spec. Bear in mind there will be no long buffer queue for retransmission because there shouldn't be a big buffer in the first place

[procreate]

If there wasn't buffers and some form of abstinence of packets loss the internet would simply collapse under its own retransmission weight. It does take longer to retransmit than to sit in queue for less time, the problem with it is ordering and priority.

 

I have actually spoken with Bob Metcalf about this, he is the one who came up with it despite being told tcp was an impossible method at the time... He is friends with my father. Originally memory was hugely expensive so yes, packet loss was most certainly built into tcp, it's also failed in his first version. Now that memory is cheap, yes manufacturers have become a little too dependant on memory buffers increasing their size past optimal amounts but to exclude it completely would result in complete network collision... Like a huge multicar pileup on a roadway.

[Omega]

The real issue with buffer bloat is network devices with buffers that are too large.  TCP was designed to drop packets when congestion is high unfortunately network device manufacturers thought it would be a good idea to make larger buffers to store queued packets rather than drop them which results in latency as packets wait to get out of the buffer.

 

It's actually better to drop and retransmit a packet rather than queue it which is how it's suppose to work.

Akic got it. However, I don't know if I buy into the whole bufferbloat issue being the root of all problems when it comes to lag. I've used fq_codel and codel on the ddwrt firmware and to be honest it makes no difference. YMMV, but thats just my experience.

[procreate]

Bufferbloat only would come into play if you have multiple uploads happening and maybe a couple Skype calls clogging the tx. At least in the US our service is very asymmetrical so it's easier to back that direction up, but even with loads of rx, it still has to send an acknowledgement... Small but throw in a bunch of data coming in at the same time?

Game lag? I am fairly convinced it's more to do with WiFi and it's packet loss and too many people using it for online gaming. I would be curious if someone did a study to find amount of players who are not hardwired.

 

honestly you can think what you want, and i agree that bufferbloat is rarely the issue, but i think the problems lie elsewhere and sometime its simply between point A and B out of your control. however, its also not as easy as just re transmitting packets either. sadly, i went down this rabbit hole once... funny its popping up again but i dont intend to be bothered with it again.

[Zennon]

All we need to worry about is that congestion control on the duma stops us from having local congestion If no one else is using the network while you game then do not worry about bloat.

 

If they are set the sliders to 70% or what ever works best and forget about it.

[procreate]

exactly what i am saying...

 

with BIG PIPES, buffers are mandatory and are sized according to throughput... but that's well out of the consumers hands.

[Sgt-Greco]

So you are telling me guys that as far as competitive gaming is concerned, sucrifising speeds for a perfect Buffer Bloat grade is the way to go?

 

[Zennon]

Speed is subjective.

 

The width at which the packets travel is larger so you can download faster but the real speed is your ping not the width of the band the ping is travelling in so to speak.

 

Controlling congestion will stop local congestion on your network it will not slow your ping speed (increase the numerical number) this will make gaming better if other users are on the network.

 

If you are the sole user then there is no way gaming packets will create bufferbloat unless your line is 228k down and up.

[secretface]

All we need to worry about is that congestion control on the duma stops us from having local congestion If no one else is using the network while you game then do not worry about bloat.

 

If they are set the sliders to 70% or what ever works best and forget about it.

Just saying my lag stopped when I set my up and download to get an A+ for bufferbloat and I tested when I was home alone. I don't know why it made a difference but it did and it works even if something else made it happen at the same time, I don't care its working so I'm happy. It may work for someone else though.

[procreate]

The faster your connection the less likely you will back up your network. It's like a funnel. The wider the mouth the less it will fill the cup if at all.

[r8rs4lf]

Like others here, getting my BB to an A as well as quality has made a big difference for me. I don't know if it works for others, but it did wonders for me. The game has been great ever since.

[Alex49H]

I had mine at an A for awhile but now it goes from nothing there to a D and then to a C. Not sure why all of sudden it changed.

[richb-hanover]

If there wasn't buffers and some form of abstinence of packets loss the internet would simply collapse under its own retransmission weight. It does take longer to retransmit than to sit in queue for less time, the problem with it is ordering and priority.

 

I have actually spoken with Bob Metcalf about this, he is the one who came up with it despite being told tcp was an impossible method at the time... He is friends with my father. Originally memory was hugely expensive so yes, packet loss was most certainly built into tcp, it's also failed in his first version. Now that memory is cheap, yes manufacturers have become a little too dependant on memory buffers increasing their size past optimal amounts but to exclude it completely would result in complete network collision... Like a huge multicar pileup on a roadway.

Of course, routers need buffers to hold a small number of packets to keep the bottleneck link busy. But only a couple packets worth of data needs to be queued. The problem with today's routers is a. they often have a FIFO queue, and b. they often allow an uncontrolled number of packets to be queued. 

 

The anti-bufferbloat algorithms (fq_codel in Linux, PIE in cable modems with DOCSIS 3.1) separate traffic into different queues - one for each flow/connection - and permit only a small amount of data to be held in each queue. The algorithms drop packets for flows that queue too much data (since they're hogging the bandwidth) while allowing small flows (gaming, VoIP, DNS lookups, SYN packets to go right through.) You can get lots more information about the subject at http://www.bufferbloat.net/projects/cerowrt/wiki/What_to_do_about_Bufferbloat

 

Since we're dropping names here, ask Bob Metcalf if he thinks Van Jacobson's and Kathie Nichols' fq_codel would be a valuable addition to every router. 

[Taff]

Of course, routers need buffers to hold a small number of packets to keep the bottleneck link busy. But only a couple packets worth of data needs to be queued. The problem with today's routers is a. they often have a FIFO queue, and b. they often allow an uncontrolled number of packets to be queued. 

 

The anti-bufferbloat algorithms (fq_codel in Linux, PIE in cable modems with DOCSIS 3.1) separate traffic into different queues - one for each flow/connection - and permit only a small amount of data to be held in each queue. The algorithms drop packets for flows that queue too much data (since they're hogging the bandwidth) while allowing small flows (gaming, VoIP, DNS lookups, SYN packets to go right through.) You can get lots more information about the subject at http://www.bufferbloat.net/projects/cerowrt/wiki/What_to_do_about_Bufferbloat

 

Since we're dropping names here, ask Bob Metcalf if he thinks Van Jacobson's and Kathie Nichols' fq_codel would be a valuable addition to every router. 

love to get my hands on a docis 3.1 modem ,there not for sale to consumers right now,except for cable companies.

[richb-hanover]

More's the pity. Version 1 of the spec has been finalized since October 2013 - what's taking them so long? ( see http://www.cablelabs.com/specification/physical-layer-specification/ )