Feeds

back to article Researchers propose solution to ‘bufferbloat’

Your network is fast, but your download isn’t: it might not be your provider or the server, because in the middle there are too many buffers in the way. The problem is ancient, even though the term that labels it (“bufferbloat”) was only coined in 2010. In a paper posted at the Association for Computing Machinery, two …

COMMENTS

This topic is closed for new posts.
Silver badge
Trollface

hope they know where to go first

CeroWRT should be their first stop for testing any of their ideas in the real world as this is the cutting edge project for battling buffer bloat on the edges. Best of all I can try out the quality of their solution (once stable of course) by knifing nubs in BF3. Long live low latency and 8yo who lack basic strategy.

0
0
Silver badge
Happy

Re: hope they know where to go first

Wow should have looked before posting as Dave is already all over this even though it looks like he does not yet have a test build available. I am sure it is coming very soon.

http://www.bufferbloat.net/projects/codel/wiki/Wiki

0
0

Re: hope they know where to go first

the group of people driving all the work on bufferbloat is a very small one. really, you could boil it down to jim gettys, nick weaver, and...kathy nichols and van jacobson. the authors of this paper. who are both in the cerowrt credits. van jacobson is in them _twice_.

so, yes, it's a fair bet they know where to go. =)

1
0
Silver badge

Re: hope they know where to go first

You forgot to mention Dave Täht who is from what I gather doing a lot of the down and dirty testing and implementation work. Papers are great but seeing the results almost immediately in CeroWRT gets a shout out to Dave, good job buddy on the bloat work.

0
0
Silver badge

Re: hope they know where to go first

Actually as you mention a shout out to everyone on the contributor page.

0
0

It's 1985 again

... and someone needs to invent Zmodem-over-IP. How quickly people forget about things like sliding-window packet handling...

0
0
Stop

Re: It's 1985 again

well, no, they don't. if you actually bother to look at the buffer bloat research, a large chunk of it is an exhaustive analysis of previous attempts to cope with the problem and why they have turned out to be inadequate (and indeed, in some cases, eventually to contribute to it).

it's amazing how many drive-by commenters assume they automatically know more about something than people who've been dedicating all their working time for several years to researching it...

8
0
Anonymous Coward

it's amazing...

... how many drive-by commenters assume they automatically know more about something than people who've been dedicating all their working time for several years to researching it...

and posting on a general forum contributes their thoughts to anything...

1
0
Bronze badge

Re: It's 1985 again

> people who've been dedicating all their working time for several years

If anything, that's an understatement; Van Jacobson's the elder statesman of TCP/IP performance research. His first major work on it came only a couple of years after zmodem was created.

And, of course, TCP does use a sliding-window design.

0
0
Anonymous Coward

measure first, fix later

I would think the best first step would be to allocate a port number and have it agreed that all traffic on that port will bypass the buffers, bar sending after the in-progress packet of course. Then internal and external systems could easily get a true measurement of the situation.

0
0
Boffin

see also

this post from Bram Cohen of bittorrent fame:

http://bramcohen.com/2012/05/07/tcp-sucks

0
0
Bronze badge

Re: see also

Or apenwarr's response to it.

1
0
Silver badge
Thumb Up

Can't wait.

1
0
Bronze badge

Packet Soujorn......

*Bob Clicks link*

*Waits*

*Wanders over to put kettle on*

Jim says "What are you doing, Bob ?"

"Huh, bloody packet's gone on a soujourn to the south of France again....."

0
0
This topic is closed for new posts.