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."
Does it have Evil Bit implemented?
The submitter says that TCP is getting old, but does that really tell us anything about how well it does its job?
TCP is old, but that doesn't mean it's bad or replacement is due. Some shortcomings have surfaced and been adressed. For the most part, TCP does a good job at what it was designed to do.
Please correct me if I got my facts wrong.
Because then you're going to have the suits trying to push it down, no matter how great/useful it is in an effort to kill the possibility of coming out with something that could make pirating any easier or more efficient. That's the only way they're going to see it.
It's good to see innovation though, nonetheless.
Here is a summary of their technology copied from their website:
Rateless Internet The Problem
Rateless Internet is an Internet transport protocol implemented over UDP, meant as a better replacement of TCP. TCP's legacy design carries a number of inefficiencies, the most prominent of which is its inability to utilize most modern links' bandwidth. This problem stems from the fact that TCP calculates the congestion of the channel based on its round-trip time. The round-trim 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. This additionally forces TCP to work at safe and relatively low transmission speeds with under 1% loss rates. Nevertheless, our extended real-life measurements show that highest throughput is generally achieved at speeds with anywhere between 3% and 5% loss.
The Solution
By using our core coding technology we were able to design a reliable Internet transmission protocol which can circumvent both of the fore-mentioned deficiencies of TCP, while still remaining TCP-friendly. By using encoded, rather than plain, transmission we are able to send at speeds with any packet loss level. Rateless coding is used in conjunction with our Universal Congestion Control algorithm, which allows Rateless Internet to remain friendly to TCP and other congestion-aware protocols.
Universal Congestion Control is an algorithm for transmission speed control. It is based on a simple and clean idea. Speed is varied in a wave-like fashion. The top of the wave achieves near-optimal throughput, while the bottom is low enough to let coexisting protocols like TCP smoothly receive a fair share of bandwidth. The time lengths of the peaks and troughs can be adjusted parametrically to achieve customized levels of fairness between Rateless Internet and TCP.
The Rateless Internet transport is now available through our Rateless Socket product in the form of a C/C++ socket library. Rateless Internet is ideal for Internet-based applications, running on the network edges, that require high bandwidth in a heterogenous environment. It was specifically built with peer-to-peer and live multimedia content delivery applications in mind.
R-E-S-P-E-C-T
Find out what it means to me
R-E-S-P-E-C-T
Take care, TCP
Oh socket to me, socket to me,
socket to me, socket to me...
It appears that they get better performance than TCP by considering (all - 1) the issues. Basically, their protocol works and performs better than TCP because the pipes have spare capacity. If the pipes were at capacity, their protocol would break down. TCP has been designed to be robust in all conditions. Protocols like this that rely on "in most cases we can get away with allowing more errors than TCP does" are not going to replace TCP.
It was quite a complicated set of protocols and IIRC the final versions were using TCP/IP as their transport layer and below. The versions before that were using OSI.
http://en.wikipedia.org/wiki/DECnet
John.
Tried their "Rateless Copy" utility, transferring a 5.8 mb binary file from my web server in Texas to my local connection in Toronto.
With Rateless Copy: time between 31-41 seconds, average of 200k/s, the resulting file is corrupted. Tried it again to ensure, same result.
Without rateless copy (http file download) 8 seconds, average of 490k/s, the resulting file works fine as expected.
Sorry, but I don't think it's all that great.
You'd be right if they were talking about an error correcting code designed to repair damage to a packet in transit.
They're actually talking about erasure correction, where each symbol is a packet as a whole. In a very simple form, you send a packet sequence like this:
A B (A^B) C D (C^D)
So if you lose packet A, you reconstruct it from (B ^ (A^B)) = A. This simple scheme increases the number of packets sent by 50%, but allows you to tolerate a 33% loss, presuming you don't lose bursts of packets. There are more sophisticated schemes, of course, and there are various tradeoffs of overhead versus robustness.
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"
This work seems to be about two things (which I am not sure I see a strong connection between): lowering transport latency, and using available bandwidth better. The latter has been the subject of many papers in the last few years. There are now several serious proposals of how to fix TCP with respect to long fat pipes. They don't seem to support the idea that retransmissions are harmful. So I'm going to talk about the first issue, transport latency.
The idea of using error-correcting codes (ECC) to eliminate the need for retransmissions is an interesting one. The main benefit is to reduce transport latency (the total time it takes to send data from application A to B). Here is another paper proposes has a similar idea, applied at a different level of the network architecture.
The root problem here is that network loss leads to increases in the transport latency experienced by applications. In TCP, the latency increases because TCP will resend data that is lost. That means at least one extra round-trip-time per retransmission. This "Rateless TCP" approach uses ECC so that the lost data can be recovered from other packets that were not dropped. In this way, the time to retransmit packets may not be needed. I say may, because there will be a loss rate threshold which will exceed the capability of the ECC, and retransmission will become necessary to ensure reliability. But, as long as the loss rate is below the threshold, then retransmissions will not be necessary. Note that the more "resilient" you make the ECC (meaning supporting a higher loss threshold), the more work will be needed at the ends. So you are not eliminating latency due to packet loss, you are simply moving it away from packet retransmission into the process of ECC. However, if you've got good ECC, the total latency will go down.
The ECC approach may be a nice middle ground. But, it the ultimate solution to minimize latency is probably through a combination of active queue management (AQM) and early congestion notification (ECN). Unlike ECC, this approach really would aim to eliminate packet loss in the network due to congestion, and therefore completely eliminate the associated latency. Either ECC or regular TCP would benefit. In a controlled testbed using AQM and ECN, I've completely saturated a network with gigabits of traffic, consisting of thousands of flows, and had virtually no packet loss.
It should also be noted that retransmission is NOT the dominant source of transport latency in of TCP. I am a co-author on a paper that shows another way (other than eliminating retransmission) to greatly reduce the transport latency of TCP. The basic idea is that the send-side socket buffer turns out to be the dominant source of latency (data sits in the kernel socket buffer waiting for transmission). In the above paper, we show how a dynamic socket buffer (one that tracks the congestion window) can dramatically reduce the transport latency of TCP. We allow applications to select this behaviour through a TCP_MINBUF socket option.
-- Buck
How does it work? Well, it's layered over Rateless Internet, in which (as we all know) packets do not have to be resent. So it carefully loses all packets and relies on Rateless Internet to make sure they arrive safely at the other side and do not have to be resent. Because no packets need to make it from A to B, you don't need any network hardware, and data can be sent just as fast as your machine can drop packets.
Guess I'd better apply for a patent...
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