Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TCP Sucks

bramcohen.com

Post reply on HN
Print view View original

31–40 of 60 posts

Re: TCP Sucks

#31

Post by nkohari »

scott_s wrote: post #28
caf wrote: post #2

The solution is for the end user to intervene, and tell all their applications to not be such pigs, and use uTP instead of TCP. Then they’ll have the same transfer rates they started out with, plus have low latency when browsing the web and teleconferencing, and not screw up their ISP when they’re doing bulk data transfers. That still doesn't address the problem when you have many users behind the same queue, some of…

My thought was more fundamental than that: any solution which involves asking users to request different transport protocols is not going to solve the problem. There are far more users who have no idea what a "transport protocol" is than those who do. With that said, I enjoyed the post. It's an interesting problem, and I do find the base idea attractive: allowing applications to opt to be background traffic.

It wouldn't (at least in my understanding) be the user that would choose, it would be the application. WoW for example would optimize for latency, whereas BitTorrent would optimize for throughput.

Re: TCP Sucks

#32

Post by bramcohen »

viraptor wrote: post #19

Ok, maybe I'm missing something, but reading the article I see some weird ideas: RED is hard to deploy, so let's change the base protocol instead. - how does that make sense? Everyone would have to start using new libraries and for backward compatibility we'd have to preserve the tcp layer too. That means standards like http would have to get extensions to use SRV records or suffer delays while utp availability is pr…

BitTorrent is using uTP just fine, which is only, you know, most of the upload from consumer internet connections, and we're working on getting the same things crammed into TCP with LEDBAT, but that's a slow process.

I wasn't complaining about RED dropping packets, just describing how it works.

As for the tension, my point is that my solution works and the other one doesn't. If you want to know why the person I quoted was being such a dismissive jerk, you'll have to ask him.

Re: TCP Sucks

#33

Post by josefonseca »

I think the catchy title was meant to grab attention to an important present day issue.

But TCP actually does not suck, it's been there for longer than I have and served us pretty darned well up until now.

Never forget that when the TCP protocol was designed, the biggest concern we had was that a nuke would land on top of our heads at any minute and the network should keep working. Also, the "Internet" was thought to be a small niche network of networks among the military and academics.

I guess this is all well known, it's just my reaction to the editorialized title.

Re: TCP Sucks

#34

Post by bramcohen »

moultano wrote: post #30
viraptor wrote: post #19

Ok, maybe I'm missing something, but reading the article I see some weird ideas: RED is hard to deploy, so let's change the base protocol instead. - how does that make sense? Everyone would have to start using new libraries and for backward compatibility we'd have to preserve the tcp layer too. That means standards like http would have to get extensions to use SRV records or suffer delays while utp availability is pr…

> When did that turn into some bizarre conflict and why? Man you weren't kidding. I tried looking up uTP on wikipedia hoping to come away with some technical understanding. It's full of passive aggressive statements that cite forum posts as their support, with no information on how it actually works. Maybe some of the folks in this thread could go fix that.

There's some detailed writeups of the algorithms in the LEDBAT documentation. As for commentary, that's distinctly lacking, and my post is filling in some of the gap.

Re: TCP Sucks

#35

Post by scott_s »

nkohari wrote: post #31
scott_s wrote: post #28

Earlier quoted context omitted.

My thought was more fundamental than that: any solution which involves asking users to request different transport protocols is not going to solve the problem. There are far more users who have no idea what a "transport protocol" is than those who do. With that said, I enjoyed the post. It's an interesting problem, and I do find the base idea attractive: allowing applications to opt to be background traffic.

It wouldn't (at least in my understanding) be the user that would choose, it would be the application. WoW for example would optimize for latency, whereas BitTorrent would optimize for throughput.

Correct, but Bram's argument (as I understand it) was that the users would put pressure on the application developers to opt to be background traffic.

Re: TCP Sucks

#36

Post by bramcohen »

volatile wrote: post #20

The author seems to claim that is is implausible for a router vendor to sell a router that drops more packets. The marketing plan is that the because router vendors are unwilling to say ‘has less memory!’ as a marketing tactic, maybe they’d be willing to say ‘drops more packets!’ instead. That seems implausible. Yet he concludes by suggesting the router should drop all the packets. The best way to solve that is for a…

That's what you would do IF you were going to be serious about making the router drop packets in a way which actually helps. I don't expect it to happen any time soon.

Re: TCP Sucks

#37

Post by nkohari »

scott_s wrote: post #35
nkohari wrote: post #31

Earlier quoted context omitted.

It wouldn't (at least in my understanding) be the user that would choose, it would be the application. WoW for example would optimize for latency, whereas BitTorrent would optimize for throughput.

Correct, but Bram's argument (as I understand it) was that the users would put pressure on the application developers to opt to be background traffic.

Two nearly-universal truths about users that suggest solutions: they're both rare, and usually wrong. :)

It's more likely that users will state the problem -- such as, "I want to be able to run WoW and BitTorrent at the same time." From there, the software developers would determine the solution (optimization for latency vs. throughput).

Re: TCP Sucks

#38

Post by msbhvn »

Just to be clear, "TCP Sucks", despite successfully running the majority of the global Internet traffic. "TCP Sucks" so bad we're basically going to copy a lot of it: window based congestion control, SACK, timestamps, ability to add new options, etc. "TCP Sucks" because it is not perfect and has an issue, an issue that requires router / switch upgrades. We're going to fix that by breaking backward compatibility with _tons_ of applications and requiring an OS update on _every_ client and/or application. All this assuming our relatively new and unproven thing is as good as TCP in all other ways and fixes this issue of TCP perfectly.

Hmmm. Me thinks that TCP does not suck so much.

Re: TCP Sucks

#39

Post by romaniv »

its_so_on wrote: post #25
jandrewrogers wrote: post #8

Designing networking protocols that are robust in mathematical sense is unbelievably difficult. In fact, we humans have only found optimal solutions in a few cases if you dig through the mathematics literature. Many real-world networking protocol design scenarios do not have a known non-pathological implementation. Furthermore, there is a large number of decentralized protocol designs that we can prove to have many p…

To people who don't know what the parent is talking about. Take a simple example. http://en.wikipedia.org/wiki/Two_Generals_Problem My summary: The two generals problem proves that, if there exists any nonzero probability of packet loss, two people cannot even coordinate to both have a state 1 at sunrise tomorrow (attack!!!) or both have the state 0 if it is not 100% mathematically guaranteed that they both believe t…

Shouldn't there be mathematically solid probabilistic solution? Start at 50% certainty, increase it with every positive message, decrease it with every unit of time. Stop when you're close to 100% or 0%.

Re: TCP Sucks

#40

Post by bramcohen »

jandrewrogers wrote: post #8

Designing networking protocols that are robust in mathematical sense is unbelievably difficult. In fact, we humans have only found optimal solutions in a few cases if you dig through the mathematics literature. Many real-world networking protocol design scenarios do not have a known non-pathological implementation. Furthermore, there is a large number of decentralized protocol designs that we can prove to have many p…

Did you even read the article?
Post reply on HN