Slashdot Mirror
Replacing TCP?
olau writes "TCP, the transfer protocol that most of the Internet is using, is getting old. These guys have invented an alternative that combines UDP with rateless erasure codes, which means that packets do not have to be resent. Cool stuff! It also has applications for peer-to-peer networks (e.g. for something like BitTorrent). They are even preparing RFCs! The guy who started it, Petar Maymounkov, is of Kademlia fame."
Now that Digital is little more than IP spread across a few different companies, maybe the holder of Decnet's patents could release the protocol under an Open Source license. If I recall correctly it was quite the networking layer.
BLING BLING. Meet the architecture that's changing everything.
TCP may be old, but it can go on for another 50 years wothout any problem.
--- "To pee or not to pee, that is the question." ---
From the first paragraph of TFA:
This problem stems from the fact that TCP calculates the congestion of the channel based on its round-trip time. The round-trip time, however, reflects not only the congestion level, but also the physical length of the connection. This is precisely why TCP is inherently unable to reach optimal speeds on long high-bandwidth connections.
A secondary, but just as impairing, property of TCP is its inability to tolerate even small amounts (1% - 3%) of packet loss.
I find it kind of interesting that these are two competing problems: one having to do with high bandwidth (and presumably high-reliability) connections, the other with low-reliability connections. My home DSL, however, often fits into the latter category: 3% packet loss is not uncommon on bad days. So maybe the two aren't so incompatible after all.
Why not SCTP ? See RFC 2960. Already in the Linux kernel, Kame, (solaris ?) and probably others.
:-/
Intro here
- SCTP can be used in many "modes"
* Provides reliable messaging (like UDP,but reliable)
* Can be used as a stream protocol (like TCP).
* One connection/association can hold multiple streams.
* One-to-many relation for messaging.
* Better at dealing with syn flooding than TCP.
Then again, I guess inveting the wheel is more "fun"
ecip.com I call it Error Correcting IP, and used it to stream live video from Sri Lanka in 1997 with Arthur C. Clarke Hal's Birthday
it was a 64K shared line with 90% packet loss, I received 60Kbps for the video stream. ( I have the video to prove it )
We even filled preliminary patents on this back in 1996 but they were never followed through with.
Luigi Rizzo (now head of the FreeBSD project)also did some excellent work on this also. http://info.iet.unipi.it/~luigi/fec.html
He calls it Erasure codes.
Which is more accurate since UDP doesn't have errors, it either come across 99.999% perfect or not at all.
So there is more information then in an error situation where ever bit is questionable.
What this means almost 1/2 the hamming distance in the codes in needed to correct an errasure verses and error.
Turns out the Error/Erasure correcting scheme it critical and not obvious. I spent almost 5 years working on this part time before it started making some real breakthroughs.
My original system was designed for 25% packet loss (not uncommon in 1996).
In the inital idea we added 1 exored packet for every three data packets, but at 25% packet loss, it turns out that it didn't increase reliablity at all! Working this out with probablities was a major eye opener!
Even when you work the problem out you realize you will still need some retransmissions to make up for lost packets, there is no possible solutions without this.
I have been trying to find people to help opensource this since I have working far too hard just to survive since 2000 to even consider taking on another task.
Anyone interested in my research and carring this forward please see my site and contact me.
John L. Sokol
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
They tell you how they solved the solution, but fail to tell you how much impact this solution has overall.
They're basically stating that now they can flood the connection with packets.
But they've also told you that the packets contain your data in an error correcting encoding. What they don't mention is this:
How much overhead is required by the error correcting encoding?
How many errors can the error correcting encoding handle? (drops 1 packet = ok, drops 400 packets = bad)
How much cpu computation is required to encode and decode the payload?
How is the cpu overhead managed? (how much performance will be lost by context switching, etc.)
So they're just playing the game of distracting people with the best part of thier performance measurement without bothering to mention the performance impact of all of the other trade-offs they admitted to making.
This may be just a wee bit offtopic, but it may be my only chance to ask...
Who remembers HSLink?? If I recall correctly it was an add-on transfer method for Procomm Plus. It allowed two people connected over a modem to simultaneously send files to each other at basically double the normal speed. I remember thinking it had to be a scam, but me and my friends tested it and were able to send double the usual info in whatever time we were used to. (I forget, 10 minutes a meg I think)
How did this work? Were we fooled or was it for reals? Could something like that be applied to dial-up internet connections?
-Don.
Cwm, fjord-bank glyphs vext quiz
Avoiding congestion while maintaining performance is a hard problem. Fortunately, you degrade your own performance if you create congestion and congestion often occurs on the edge. We would really like to avoid the tragedy of the commons with congestion and the Internet. If we cannot, the Internet may truly collapse by 2006.
I'd still like to see a good protocol that doesn't require in-order packet receipt in addition to the changes that they mentioned; when transfering large volumes of data, why not?
This is exactly why FTP uses UDP for its data transfer. So use FTP. In the last decade, though, improvements to TCP stacks have mostly mooted this difference. Once upon a time, when one end of a TCP transfer NACK'd a packet, it meant that packet and every packet after it would need to be re-sent (even those which had been sent already). So if you send packets 100, 101, 102 and then get a NACK for 100, you'd have to send 100, 101, 102, 103, etc. But with modern implementations, the receiver would keep packets 101 and 102, so the sender only needs to re-send packet 100, and then proceed to packet 103. This has made TCP much more efficient over lossy networks. Deferred NACKs also deal well with the problem of out-of-order packet arrival, when tardy packets show up before the deferred NACK is transmitted.
I'm very dubious that these folks' protocol can realistically replace TCP; it simply doesn't add any must-have qualities. The only place where I see an advantage is transmitting audio and video, where you don't necessarily want to retransmit lost data, and are willing to put up with minute gaps in the data stream.
A transport protocol that really deserves more attention is TTCP (TCP for Transactions). It abbreviates the TCP connection handshake, which makes it much more efficient / better-performing for very short transactions (like typical HTTP usage).
-- TTK
Don't get me wrong, I think they mean well, but they are trying to prohibit commercial use of GPL-linked works. Nobody said the GPL was always friendly to your business plan, but you can either take it or leave it, not have it both ways. I know one of the founders of this company, Chris Coyne - he used to regularly come to my parties in college. Nice guys, and I am sure they mean well. They could use some serious guidance though on licensing and IP issues, not to mention trying to make a viable business out of network software, which is a tough proposition in itself.
Feel free to contact me if you need help guys.
"TCP assumes all packet losses are due to congestion."
It may be a quibble, but isn't it more accurate to say that TCP reacts to packet losses the same no matter what the cause? The packet, or group of packets, is just lost. I haven't looked into the status of RFC 3168 (ECN, router congestion flag) lately, so maybe I'm wrong.
Since you mention it, the tragedy of the commons would be accentuated by pushing the network past saturation by design. By grabbing bandwidth, the 'haves' can effectively lock out the 'have nots' and their slower hardware, which would eventually result in no one having a usable network.
sigs, as if you care.
No, the problem is with the way TCP's congestion window works. When there is no loss, the congestion window is increased linearly, typically at 1 packet a roundtrip. On the other hand, whenever a packet is lost the window is cut in half. On a high latency, high bandwidth link (i.e. one with a large delay-bandwidth product) the window required to keep the link saturated could be tens of thousands of packets. You could tweak the parameters, but ultimately you still have additive-increase multiplicative decrease (AIMD).
The key problem with TCP is that it assumes that most losses happen because of packets being dropped due to congestion, not because of data corruption. Treating every loss as a congestion event worked well in the early days of the Internet, but is counterproductive today where the core of the Internet has plenty of spare capacity and congestion usually happens at the edges.
If ECN were universal, one could ignore losses (for the purpose of congestion control). There are lots and lots of protocols that have been designed by the computer science research community... like look through the proceedings of, say, ACM SIGCOMM. You'll find no shortage of new protocols.
Designing one that has big enough advantages to justify the cost of switching is another matter. TCP works find to today's cablemodems and such. Its when you start talking about trans-continental multi-gigabit networks that its limitations become a problem.