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

51–60 of 60 posts

Re: TCP Sucks

#51

Post by viraptor »

bramcohen wrote: post #32
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 quote…

Ok, I don't understand this part then: "With RED the router will instead have some probability of dropping the packet based on the size of the queue, going up to 100% if the queue is full." - that seems to be universally true for any queue with limited capacity. If it's full, it's going to start dropping packets - whether it's those on the queue, or the new ones doesn't matter. Any queue which is full will require dropping as many packets as the number coming in.

Is there some reason this was described as a specific behaviour here?

Re: TCP Sucks

#52

Post by caf »

bramcohen wrote: post #26
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…

They can have their throughput without running a denial of service on their net connection. If you assume that they'll DOS themselves for the fun of it anyway, then I can't help you.

For a user that cares only about throughput and not about latency, it's not a DOS.

Re: TCP Sucks

#54

Post by stock_toaster »

viraptor wrote: post #51
bramcohen wrote: post #32

Earlier quoted context omitted.

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 quote…

Ok, I don't understand this part then: "With RED the router will instead have some probability of dropping the packet based on the size of the queue, going up to 100% if the queue is full." - that seems to be universally true for any queue with limited capacity. If it's full, it's going to start dropping packets - whether it's those on the queue, or the new ones doesn't matter. Any queue which is full will require dr…

I believe the focus is more on the first part of that statement. A "standard" queue would only drop packets when it is in actuality full. RED drops packets when the queue is non-full based on some calculated probability. The likelihood of drop simply goes up until the queue is full (and 100% of new packets drop).

Apparently.

Re: TCP Sucks

#55

Post by paulsutter »

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…

Hold on a minute

> possibly (my chronology is fuzzy) was approximately as good as the mathematics would have reasonably allowed

Just because Van Jacobsen's papers spew forth great volumes of mathematics, doesn't mean there is any robust mathematics behind TCP. Read to the end of his paper "Congestion Avoidance and Control". Read past all of the impressive plots graphs and equations. Read to the conclusions.

"The 1-packet increase has less justification than the 0.5 decrease. In fact, it’s almost certainly too large."

This statement shows how little formal consideration went into the entire algorithm. The 1-packet increase is not simply too big or too small, it just doesn't make any sense. For starters, how big is the packet? Oh, it isn't defined anywhere. Even if we just go with the de facto internet packet size of 1542 bytes (you know, the old limit for 10Mbit Ethernet)...

Could that one packet increase per roundtrip make equal sense for a 10Gbit path to India with a 400ms round trip time, as it does for a 56Kb link between Berkeley and MIT (his test case)? Of course it doesn't make sense. And it gives lie to any notion that there is a formal underpinning for TCP. They tweaked it until it worked, and then put on a nice mathematical show to feel better about it.

Quoth Van Jacobsen: "We have simulated the above algorithm and it appears to perform well". Oh now I feel better.

Second point, which Braham is covering: TCP makes the assumption that router queue lengths are reasonable. TCP says, fill up the router queues until they drop packets. But router queues have been getting longer and longer as memory gets cheaper. These queues can create additional seconds of delay to layer on top of the 10ms-400ms speed of light delays we see on the internet itself.

EDIT: In that 10Gb to India example, it takes TCP literally DAYS to fill up the pipe because of that "1 packet per roundtrip" window increase. Days, by the way, of no incidental packet loss, because it all gets reset on a loss.

EDIT: I spent 5 years of my life working on the fact that latency was never really factored into the design of most network protocols.

Re: TCP Sucks

#56

Post by paulsutter »

bramcohen wrote: post #40
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?

One thing you have to realize about Hacker News is that people can accumulate pretty good karma points for postings that have a definitive/authoritative tone blended with some truisms. Not to bludgeon the equine or anything, but I think people find them comforting.

Re: TCP Sucks

#57

Post by krtcut »

This discussion just shows how change (even just profiling something) gets stalled. Lots of speculation, and then arguments about speculation. Meanwhile...

Bram Cohen is lucky because he has a platform, his own platform, that he can use uTP on and he doesn't need anyone's approval. It's working so far ("mature") and that's that. I just wish he'd have given some other protocols a try, a little benchmarking exercise that we could in turn replicate ourselves, so we could see how they compare. That said, I admire the irreverence. We need more of that.

As for these arguments, it's like when VJ "saved the internet", if it works, then we're done. Miller Time.

Instead here we have a looped version of "Less Filling, Tastes Great."

You want dropped packets? Use UDP.

Is that acceptable? Acceptable to who? All depends on what you're trying to do. What you're trying to do, not what someone else is trying to do.

Don't wait for approval. It may never come. You just get endless debate. If you got something that works, use it.

Re: TCP Sucks

#58

Post by paulsutter »

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…

While it's true that network protocols are neat challenging puzzles with nontrivial solutions, the hardest parts end up being the mundane: how does any given protocol change interoperate with all the existing implementations out there, especially changes to congestion control, and across the range of optional protocol features.

Uncertainties introduced by packet loss are actually pretty easy to work past.

Re: TCP Sucks

#59

Post by paulsutter »

caf wrote: post #52
bramcohen wrote: post #26

Earlier quoted context omitted.

They can have their throughput without running a denial of service on their net connection. If you assume that they'll DOS themselves for the fun of it anyway, then I can't help you.

For a user that cares only about throughput and not about latency, it's not a DOS.

Backing a queue up to seconds of depth doesn't increase throughput.

Most of the bandwidth contention is at the edge, right at your DSL connection, so any battle among network connections is a battle among your own usage at any given moment.

Separately, bittorrent is not a latency-sensitive app, it's throughput sensitive, and uTP was designed for bittorent.

Re: TCP Sucks

#60

Post by paulsutter »

hristov wrote: post #16

Shameless plug: Extremetcp.com is the solution to the congestion problems of TCP. The best part of ExtremeTCP is that it is not a new protocol. It is TCP. It just uses clever algorithms at the sender side to send data while avoiding congestion. (Since TCP does not actually specify which algorithms one should use as long as one avoids congestion, ExtremeTCP is a perfectly legal version of TCP). Yes, I am involved with…

There are many implementations of improved congestion control for TCP, several of which are implemented in the Linux kernel.

It's trivially easy to modify congestion control to get arbitrarily fast performance in high bandwidth-delay environments. I can tell you from experience that implementing fast performance in extremely lossy environments is harder.

And hardest of all is to come up with a solution that works on a network that is shared with the common congestion control implementations, and that works with billions of end nodes.

I spent years working on this. Feel free to reach out to me on my email address, I'd love to share with you my experience of commercializing such a product.

Post reply on HN