TCP doesn't suck, and all the proposed bufferbloat fixes are identical

http://apenwarr.ca/log/?m=201205#08

by soundsop • 14 years ago

115 20 14 years ago

ibotty• 14 years ago

good article, although i concur with his assertion that the acm interviewees only want to tackle "fix the internet". jim gettys has been pretty active in the cerowrt project, which is a home router firmware, not coincidentally initiated by him.

thespin2• 14 years ago

I'll stick with CurveCP, thanks. It works, it has the added "perk" of encryption, and it's not tied to a single application, like uTP.

Then again, if you tie something into an application that hundreds of thousands of people already use, like uTP is tied into a popular bittorrent client, you can then claim "Hundreds of thousands of people are using it, to carry major traffic."

JoachimSchipper• 14 years ago

(Note: see http://curvecp.org/decongestion.html for details. It looks interesting, but I haven't looked at it closely.)

batterseapower• 14 years ago

You may already know this, but uTP's congestion control algorithm is usable with vanilla TCP, where it is called LEDBAT (http://tools.ietf.org/html/draft-ietf-ledbat-congestion-01).

Of course, from the perspective of a Bittorrent client author it's much easier to implement TCP-over-UDP than to depend upon raw socket support / install a custom congestion control algorithm into the OSes TCP stack.

thespin2• 14 years ago

If there was a generic utpclient/utpserver pair of applications that I could use to proxy non-uTP applications, as there is with CCP, I'd try using uTP/LEDBAT. But to my knowledge, there isn't.

ajb• 14 years ago

"Problem #2 is oversized queues everywhere else on the Internet. The truth is, for almost everyone reading this, you don't care even a little bit about problem #2"

Apenwarr is misreading Van Jacobson here. What VJ says is "data piles up wherever there's a fast-to-slow transition, and nowhere else". That's in your router upstream, but it's also in your ISP's router nearest to you, downstream. You can only fix one of these on your own, which is the reason for the 'alarmist' articles: to get ISPs to pay attention.

obtu5• 14 years ago

Huh, I wasn't aware ECN wasn't enabled everywhere yet.

To enable it on Linux:

    sudo sysctl net.ipv4.tcp_ecn=1

Across reboots:

    echo net.ipv4.tcp_ecn=1 |sudo tee /etc/sysctl.d/10-ecn.conf

Other OSes: https://en.wikipedia.org/wiki/Explicit_Congestion_Notificati...

pepijndevos• 14 years ago

Any ideas about XP? My brother is having trouble playing quake on his XP while I download Ubuntu images on my Mac.

obtu5• 14 years ago

There's nothing the XP computer can do to fix that, as it is the victim of the delays and needs the cooperation of other hosts that are to some degree involved in causing the problem. As I understand it, ECN on the Mac enables the Mac to cooperate with queue management elsewhere (the Mac could be doing its own queue management without ECN, but probably doesn't). The Quake trouble indicates the bottleneck is an overlarge buffer on a router you both share. You need your shared router to do some queue management (CeroWrt is a good platform for this) so that large downloads don't increase delays for all connections. If your ISP modem has bloated buffers and you can't replace it, you may be entirely out of luck.

woodrow• 14 years ago

It's difficult to take advantage of ECN nowadays, too. Some ISPs seem to clobber the ECN field when packets enter their AS. This is measured and discussed here: http://dl.acm.org/citation.cfm?id=2068833. Notably:

"""Via large-scale path measurements, we find the ECN feedback loop failing in the core of the network 40% of the time, typically at AS boundaries."""

So, unfortunately, we've got a ways to go on this.

nzmsv• 14 years ago

Interesting. I just enabled this on my machines. Is there a way to find out whether ECN has been successfully negotiated?

obtu5• 14 years ago

I don't see it in netstat -s.

Possibly you'd have to hack up a netfilter rule.

obtu5• 14 years ago

Continuing this bufferbloat conversation, here is a shameless plug about CoDel: https://news.ycombinator.com/item?id=3948725

It implements the “look at the time you've had a queue above threshold” bit.

JulianMorrison2• 14 years ago

Surely the obvious cure is: start every connection using Vegas, detect unreasonable backoff and switch to Cubic. (In game theory: optimistic tit-for-tat.)

cpeterso• 14 years ago

But if you are connecting across the public internet, surely your connection will cross paths with someone using traditional TCP.

JulianMorrison2• 14 years ago

This strategy would be no worse than the status quo for those connections, you'd still end up using Cubic.

But if by good luck you were only crossing paths with Vegas, you would both get a smoother ride. And as the strategy spread, that would happen more often.

GlennS• 14 years ago

So how well does tit for tat work when you have more than two people sharing?

That turns out to be a much more interesting question than I was thinking of when I wrote it out. Try searching for 'multi agent tit for tat'.

fanf2• 14 years ago

There are two problems with vegas: (1) it starves when competing with traditionally-aggressive TCP; and (2) earlier vegas flows can be outcompeted by later vegas flows, so it isn't fair when competing against itself. The problem is that the earlier flows can cause a queueing delay which is detected by the later flow as a larger base RTT; the earlier flows have self-tuned to back off above a smaller RTT, so they behave less aggressively than the later flows.

SpiderX• 14 years ago

I'm curious if the problems he mentioned are applicable to IPV6 or not.

TCP doesn't suck, and all the proposed bufferbloat fixes are identical

Related Stories