
TCP doesn't suck, and all the proposed bufferbloat fixes are identical - soundsop
http://apenwarr.ca/log/?m=201205#08
======
ajb
"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.

------
obtu
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...](https://en.wikipedia.org/wiki/Explicit_Congestion_Notification#ECN_support_in_TCP_by_hosts)

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

~~~
obtu
I don't see it in netstat -s.

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

~~~
obtu
Or you can test negotiation towards a particular host using this patched
scamper, a traceroute-like tool: <http://test-ecn.csail.mit.edu/>

------
obtu
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.

------
JulianMorrison
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
But if you are connecting across the public internet, surely your connection
will cross paths with _someone_ using traditional TCP.

~~~
JulianMorrison
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.

------
ibotty
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.

------
thespin
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."

~~~
batterseapower
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.

~~~
thespin
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.

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

