The debloat-testing kernel tree

Posted Feb 26, 2011 5:08 UTC (Sat) by walken (subscriber, #7089)
In reply to: The debloat-testing kernel tree by zlynx
Parent article: The debloat-testing kernel tree

> After reading about buffer bloat again I'm not sure the problem is in the buffers. It sure sounds like the problem is in TCP/IP.

In a sense you are right. The TCP/IP congestion control algorithms used on the internet today ("reno", "newreno", "bic", "cubic") are all based on detecting dropped packets. Alternatives have been proposed, such as "vegas", that are based on detecting increasing latency when buffers fill up.

The problem is that nobody has figured out yet how to mix drop based algorithms with delay based ones: if vegas and cubic streams share the same connection, vegas backs off as soon as the buffers fill up but cubic keeps going until packets start dropping. This leaves the vegas streams starved - no good. So delay based algorithms have never been able to take off, given the lack of a clean transition mechanism.

Technically it seems easier to fix the drop based algorithms by making sure you don't let buffer grow too much before dropping the first packets; but this is a fix that needs to be deployed in all routers rather than just in the endpoints.

The debloat-testing kernel tree

Posted Feb 26, 2011 22:53 UTC (Sat) by k3ninho (subscriber, #50375) [Link] (7 responses)

>The problem is that nobody has figured out yet how to mix drop based algorithms with delay based ones

It may be the wrong question. Sure, I get that noting dropped packets gives you an idea what's going on, but for the network links connected to your hardware -- the ones you can affect -- the rate at which your buffer changes tells you how congested you are.

I know it's Saturday night (in my timezone) and I'm speculating on a web forum, but why not inform the feedback control loop with the rate (or lowest recent rate) of outflow from your buffers, and throttle to match that outflow for a given delta-t time period after sampling?

You have the buffers, you don't need to lose packets enqueue'd and you use the most meaningful local measure of congestion without having to do a lot of calculations.

K3n.

The debloat-testing kernel tree

Posted Feb 26, 2011 23:15 UTC (Sat) by dlang (guest, #313) [Link] (6 responses)

the problem is that the buffers that are the biggest part of the problem are not on the equipment that you control.

The debloat-testing kernel tree

Posted Feb 27, 2011 3:46 UTC (Sun) by jg (guest, #17537) [Link]

Actually, much of the problem *is* on hardware you control.

Your host.
Your home router.
Your broadband gear (which may be your home router).

The problem is, you don't (with the possible exception of your host if you are a Linux geek) typically have ability to get this gear fixed.

Note that since many home routers run Linux, fixing it in Linux also means that (if you run an open source home router, such as OpenWRT), we might get much of the problem fixed quite quickly.

So please come help out at bufferbloat.net.

The debloat-testing kernel tree

Posted Feb 27, 2011 3:49 UTC (Sun) by jg (guest, #17537) [Link]

Much of it is on equipment you control.

On your host
On your home router
On your broadband gear

So if you come help fix it in Linux, and run an open source router such as OpenWRT, you can get help much of this fixed quickly...

The debloat-testing kernel tree

Posted Feb 28, 2011 9:24 UTC (Mon) by k3ninho (subscriber, #50375) [Link] (1 responses)

Then, my suggestion could still be implemented on the internet's routers on links I don't personally control, couldn't it?

(I note no technical objection. I also think you may have missed the context of my phrase "the network links connected to your hardware -- the ones you can affect": it is actually talking as if you are the piece of hardware, sending TCP/IP at any point within the internetwork. Not just your laptop sharing wifi at a conference or up and down an asynchronous subscriber line.)

K3n.

The debloat-testing kernel tree

Posted Mar 1, 2011 3:54 UTC (Tue) by kevinm (guest, #69913) [Link]

The technical objection is that those routers out on the Internet aren't in control of the feedback control loop. The control is entirely in the sending endpoint - the routers are just a dumb source of feedback (by dropping or delaying packets).

The debloat-testing kernel tree

Posted Feb 28, 2011 10:36 UTC (Mon) by etienne (guest, #25256) [Link] (1 responses)

Ask available bandwidth by standard SNMP calls?

The debloat-testing kernel tree

Posted Feb 28, 2011 16:28 UTC (Mon) by jzbiciak (guest, #5246) [Link]

That seems rather unlikely to work in an end-to-end scenario. It also wouldn't respond to transient conditions unless you kept asking over and over. And what about trust issues? Do you trust the information you're getting?

The only thing you can truly rely on is the observed behavior of your own TCP streams--ie. how quickly you get your ACKs back, whether or not you experience traffic loss, and so on.

If you're willing to give up on end-to-end architecture, then yeah, you could coordinate bandwidth-controlled "virtual circuits", but I thought the whole point of IP was to keep as much of the network as state-less as possible with respect to individual connections, letting the endpoints do most of the throttling and letting the network just focus on routing and providing feedback on the current conditions.