The debloat-testing kernel tree

Posted Feb 26, 2011 23:15 UTC (Sat) by dlang (guest, #313)
In reply to: The debloat-testing kernel tree by k3ninho
Parent article: The debloat-testing kernel tree

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.