Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Replacing TCP?

michael posted about 10 years ago | from the step-by-step-the-largest-network-can-be-replaced dept.

The Internet 444

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

Sorry! There are no comments related to the filter you selected.

fp (-1, Offtopic)

Anonymous Coward | about 10 years ago | (#10587579)

yay

Has anyone considered Decnet? (4, Interesting)

Power Everywhere (778645) | about 10 years ago | (#10587580)

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.

Re:Has anyone considered Decnet? (2, Informative)

DAldredge (2353) | about 10 years ago | (#10587739)

Not all of Digital's network tech was sane...

DEC MMJ

Digital Equipment Co.'s proprietary Modified Modular Jack. It is identical to a standard USOC 6-position jack, except that the locking tab has been offset to the right to prevent an MMP (modified modular plug) from fitting into a USOC jack. AMP5-555237-2 Plug

Re:Has anyone considered Decnet? (5, Informative)

JohnGrahamCumming (684871) | about 10 years ago | (#10587872)

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.

Re:Has anyone considered Decnet? (1)

RAMMS+EIN (578166) | about 10 years ago | (#10587875)

I thought Linux already has Decnet support. How does that work?

nonsense (4, Interesting)

N3wsByt3 (758224) | about 10 years ago | (#10587581)

TCP may be old, but it can go on for another 50 years wothout any problem.

Re:nonsense (3, Interesting)

savagedome (742194) | about 10 years ago | (#10587683)

TCP may be old, but it can go on for another 50 years wothout any problem.

Somehow, the title of your post is appropriate for the subject of your mesaage.
Did you pull that 50 years out of your..... you know.

Change is not going to happen overnight. They are suggesting a better protocol which is still in the labs for the most part.

Remember how long since IPv6 is out? And now check what we are still using. It's all about changing it gradually.

Re:nonsense (1)

Dave9876 (591025) | about 10 years ago | (#10587989)

TCP != IP...They are 2 seperate layers, TCP sits on top of IP.

flamebait? (4, Insightful)

N3wsByt3 (758224) | about 10 years ago | (#10587832)

I fail to see what is flamebaiting it is to say that TCP can go on for another 50 years, without problem.

Exactly the same kind of post a bit below gets 'insightful'.

It is simply true. Yes, there are some little drawbacks with TCP, but in the whole article, they do not give a compelling reason to switch, let alone why one would *have* to. I mean, RTFA: TCP is at 1-3% and the most efficient would be a throughput with 3-5% (loss)...but so what? It's not optimal, but does it anywhere claims TCP is doomed because it's not optimal in certain area's?

There are myriads of things that aren't optimal on the Net, it doesn't mean they have been here for years and will be for years to come, nor that it is a necessity to switch, if the only thing lacking is that it's not optimally suited.

OMG!1 (-1, Offtopic)

Anonymous Coward | about 10 years ago | (#10587586)

Frost pist.

Evil Bit? (5, Funny)

Sexy Commando (612371) | about 10 years ago | (#10587588)

Does it have Evil Bit implemented?

Kudos to submitter (0, Offtopic)

Johnny Doughnuts (767951) | about 10 years ago | (#10587597)

Kudos for using coral.

Re:Kudos to submitter (-1, Flamebait)

Anonymous Coward | about 10 years ago | (#10587827)

Yeah. Really great. Now I have to do the URL's manually because our firewall blocks 8090. Kudos to the submitter for being an egocentric moron. How about putting both links instead?

A working wikipedia link for Kademlia (3, Informative)

jbellis (142590) | about 10 years ago | (#10587600)

Re:A working wikipedia link for Kademlia (2, Informative)

daserver (524964) | about 10 years ago | (#10587725)

The link in the post is coralised [nyu.edu] . Maybe someone is blocking your outgoing port 8090 for you :-)

Re:A working wikipedia link for Kademlia (2, Interesting)

squiggleslash (241428) | about 10 years ago | (#10587879)

Maybe someone is blocking your outgoing port 8090 for you :-)
That would be fairly normal. Most businesses I've seen tend to block all ports except 80, 553, and, occasionally, 8080 because it's a popular "alternative".

I'm kind of baffled to be honest that the Coralisational people chose a port other than 80. Still, if we're in an article discussing running a high level protocol over the top of another high level protocol (these people seem to understand efficient networking about as well as they understand the GPL), it kind of seems appropriate.

Re:A working wikipedia link for Kademlia (0, Insightful)

Anonymous Coward | about 10 years ago | (#10587915)

Well some of use are at work and not sitting in our mother's basement. Most companies don't just leave every outgoing port open and they surely are not going to open a port for us to read an article. Coral is a nice idea with a flawed implementation.

Re:A working wikipedia link for Kademlia (1, Redundant)

daserver (524964) | about 10 years ago | (#10587998)

> Coral is a nice idea with a flawed implementation. Care to explain this flamebait or shall we just leave it at that? :)

awesome (-1)

Anonymous Coward | about 10 years ago | (#10587609)

awesome

almost as fun as replacing the (-1, Troll)

Anonymous Coward | about 10 years ago | (#10587613)

dick in me

FP bitches!!

This has nothing to do with Portugal (0, Funny)

Anonymous Coward | about 10 years ago | (#10587621)

This has nothing to do with Portugal! It's useless!

Re:This has nothing to do with Portugal (0)

Anonymous Coward | about 10 years ago | (#10587800)

Best. Troll. Ever. AZORES #1!

Re:This has nothing to do with Portugal (0)

Anonymous Coward | about 10 years ago | (#10587964)

Impressive. The trollness is strong in this one.

Old!=bad (5, Insightful)

gspr (602968) | about 10 years ago | (#10587627)

The submitter says that TCP is getting old, but does that really tell us anything about how well it does its job?

Re:Old!=bad (0, Troll)

g0at (135364) | about 10 years ago | (#10587698)

Yeah, exactly. Stairs, and the wheel, are pretty old too. Perhaps we should study mandating elevators powered by square motors for all homes!

-b

Re:Old!=bad (5, Interesting)

jfengel (409917) | about 10 years ago | (#10587769)

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.

Re:Old!=bad (2, Informative)

BridgeBum (11413) | about 10 years ago | (#10588019)

TCP is a good protocol, but it is far from perfect. It does have weakness in it's windowing mechanism which can vastly reduce the throughput over long distances/mild latency with long durations. (Think FTP.) This is probably the problem they are refering to with #1.

For #2, this could simply be retransmission problems. TCP has a strict sequential ordering to packets, so a packet lost in the stream could cause other packets to be discarded, forcing more retransmissions than were technically required. This could be considered a 'weakness' of the protocol, since under some circumstances it could be desireable to receive the packets in a random order and allow assembly at the endpoint. (Think BitTorrent) So it's not unreasonably to examine advances in networking protocols. As for wide spread adoption....well, that's another story all together.

Re:Old!=bad (4, Insightful)

RAMMS+EIN (578166) | about 10 years ago | (#10587984)

TCP does have its shortcomings.

As they mention on their site, TCP's bandwidth usage is dependent on the latency of the link. This is due to the fact that sliding windows (the number of packets that are allowed to be out on the network) have a limited size. TCP sends a windowful of packets, then waits until one is acknowledged before sending another one. On high-latency links, this can cause a lot of bandwidth to go unused. There is an extension to TCP that allows for larger windows, addressing this problem.

Another problem with TCP is slow start and rapid back-off. IIRC, a TCP connection linearly increases its bandwidth, but will halve it immediately when a packet is lost. The former makes for a very slow startup, whereas the latter causes a connection to slow down dramatically, even though a lost packet can be due to many factors other than congestion. Slow start has been addressed by allowing connections to speed up quicker, about rapid back-off I'm not sure.

The solution this company provides seems to play nice with TCP by varying the transmission speed in waves. Apparently, this improves speed over TCP's back-off mechanism, but it obviously doesn't provide optimal bandwidth utilization.

Is it an open protocol? (4, Insightful)

FooAtWFU (699187) | about 10 years ago | (#10587628)

If it's not an open protocol (if they charge for use) it may find niche applications. If it is, it may proliferate. I wasn't able to find details about this on the site.

Re:Is it an open protocol? (1)

debianlinux (548082) | about 10 years ago | (#10587711)

http://www.rateless.com.nyud.net:8090/codes.html

at the bottom it reads:
"We are planning to release Rateless Codes for free, non-commercial use, in open source under the GNU Public License."

Re:Is it an open protocol? (1)

squiggleslash (241428) | about 10 years ago | (#10587793)

A pedant comments:

I'm assuming they're specifically saying "for free, non-commercial use" because they plan to charge (or otherwise limit) commercial use of the protocol.

In which case, how will they do that if they're releasing the code in open source under the "GNU Public License" (presumably the GPL)?

I'm guessing they're not aware you can't restrict uses if you're releasing under the GPL.

Re:Is it an open protocol? (1)

volsung (378) | about 10 years ago | (#10587805)

Which is slightly contradictory, since releasing under the GPL would not prevent commercial use.

Re:Is it an open protocol? (4, Informative)

RealAlaskan (576404) | about 10 years ago | (#10587814)

If it's not an open protocol (if they charge for use) ...

It doesn't look good. Their webpage [rateless.com] says:``We are planning to release Rateless Codes for free, non-commercial use, in open source under the GNU Public License.'' They are seriously confused about the terms of their own license. The GPL doesn't lend itself to ``free, non-commercial use'': it lets the licensee use and distribute freely, at any price, for any use.

Either they'll loose that ``non-commercial use'' crap, or this will go nowhere.

They are confused (1)

kzinti (9651) | about 10 years ago | (#10587904)

The GPL doesn't lend itself to ``free, non-commercial use'': it lets the licensee use and distribute freely, at any price, for any use.

Perhaps what they meant was "free, non-proprietary use," which would be GPL-compatible.

Re:Is it an open protocol? (0)

dustman (34626) | about 10 years ago | (#10588021)

The GPL doesn't lend itself to ``free, non-commercial use'': it lets the licensee use and distribute freely, at any price, for any use.

No, it doesn't.

The General Public License gives you a license to use that code under certain terms.

When they say "free, non-commercial use", and they talk about the GPL, they are making sense. The Linux kernel, which is GPL, may use their implementation. Microsoft cannot use their implementation in any of its Windows OSes without releasing the OS kernel under terms which are compatible with the GPL.

"Dual licensing" software under the GPL and some other commercial license is noble, (because you are releasing open source), viable (see Qt and Aladdin Ghostscript for examples of people who have made money doing this), and does not conflict with the goals of the FSF.

The GPL does not lend itself to "commercial use", because the "standard" model of software licensing is paying a price per use/copy of the binary, and the GPL doesn't work this way.

GPL trolls (sorry, not that I'm implying you're one) always pipe up with "but you can sell GPL software as much as you want", while totally ignoring the fact that the whole concept of selling software is based on the idea of copyright-enforced scarcity, which the GPL eliminates.

Re:Is it an open protocol? (2, Informative)

jfengel (409917) | about 10 years ago | (#10587852)

The front page says "not patented". They could claim it as a trade secret, but not if they plan to introduce an RFC. So even if they don't wish to open their sources, there will be open implementations very quickly.

Assuming there aren't any underlying IP issues. I'm not aware of any patents on the forward error correcting codes they're using, but that doesn't mean they don't exist. And assuming some jackass doesn't say, "Here's a thing and it's not patented; I'll patent it and then license it back to the guys who did the work!" The patent office seems to do a lousy job of checking non-patent prior art.

Already Slashdotted! (0)

Anonymous Coward | about 10 years ago | (#10587630)

No comments and already slashdotted.

What exactly about TCP is getting old? (4, Insightful)

Anonymous Coward | about 10 years ago | (#10587636)

Some inefficiencies are one thing, but you're going to need a compelling reason to get everyone to switch.

Link is dead (1, Funny)

millwall (622730) | about 10 years ago | (#10587649)

The link seems to be dead.

I guess the new protocol still has some time left in development.

Not ready for slashdotting yet.

/.ing (0)

Anonymous Coward | about 10 years ago | (#10587728)

you should have posted the non-coralized link so we can slashdot it

here [rateless.com]

Re:Link is dead (2, Insightful)

Nightreaver (695006) | about 10 years ago | (#10587844)

Well, all links have been Coralized by the auther (read more about Coral [nyu.edu] ) in the hope of withstanding a slashdotting, but Coral is still still under development, so I would assume it's here the problem lies.

Interesting but (0)

Anonymous Coward | about 10 years ago | (#10587650)

Even if this attempt to switch to another technology is succesful, it would be painfully slow

TCP is old...so what? (5, Insightful)

RAMMS+EIN (578166) | about 10 years ago | (#10587651)

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.

Re:TCP is old...so what? (0)

Anonymous Coward | about 10 years ago | (#10587731)

In other news... Wheels, the device that most vehicles use to transport themselves, are getting old. These guys have re-invented the wheel...

Re:TCP is old...so what? (0)

Anonymous Coward | about 10 years ago | (#10587920)

Or rather, they invented a new wheel that does the same thing as the old wheel that everyone already has.... Also, because everyone alredy has the old wheel, nobody needs the new one....

This won't happen (-1, Offtopic)

Anonymous Coward | about 10 years ago | (#10587652)

unless it happens.

No way (0)

Anonymous Coward | about 10 years ago | (#10587656)

IP maybe is ready to be replaced.
TCP is not ready to be replaced.
TCP has solved all the major persistance problems.

I wouldn't make any mention of bittorrent, etc.. (5, Insightful)

drunkennewfiemidget (712572) | about 10 years ago | (#10587663)

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.

Re:I wouldn't make any mention of bittorrent, etc. (1)

Ignignot (782335) | about 10 years ago | (#10587963)

That's right brother! Down with the man! Let him make his own TCP replacement!

While we're at it let's not talk about computers because they make pirating easier. At least then slashdot can revert to its natural state: being overrun by trolls.

Yet another "reliable UDP" layer (2, Insightful)

syates21 (78378) | about 10 years ago | (#10587664)

This is hardly an innovative idea, and usually by the time you end up considering all the issues you wind up with something that looks a lot more like TCP than you had originally intended.

Plus there are already protocol stacks that work around most of their gripes about TCP (slow performance over long pipes, etc).

Re:Yet another "reliable UDP" layer (5, Insightful)

jrumney (197329) | about 10 years ago | (#10587794)

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.

Rateless Internet (slashdotted) (5, Informative)

Andreas(R) (448328) | about 10 years ago | (#10587666)

Their website of the so called "experts" is down, it's slashdotted! (ironic?)

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.

Re:Rateless Internet (slashdotted) (3, Informative)

Oscaro (153645) | about 10 years ago | (#10588010)

Also, (from the site [nyud.net] we know that

Rateless Socket will be made available to select companies and institutions on a per-case basis. To find out more, please contact us.

Brilliant! (4, Insightful)

morgdx (688154) | about 10 years ago | (#10587671)

A slightly faster equivelent to TCP that I have to pay for and no-one else uses.

Sign me up for that sucker right now.

Not F/OSS (2, Interesting)

TwistedSquare (650445) | about 10 years ago | (#10587672)

Considering this is slashdot and all, I was surprised that their implementation does not appear to be open source (or indeed, freely available at all), though presumably such an implementation will be possible following the RFCs. It seems to work nicely alongside TCP using UDP, quite a cool idea. The question is whether it can break TCP's de facto stranglehold on reliable Internet communication. I'd love to play with it if I could.

Re:Not F/OSS (0)

Anonymous Coward | about 10 years ago | (#10587806)

"The question is whether it can break TCP's de facto stranglehold on reliable Internet communication."

I'm not sure I would describe an IETF standard as an "OMG! Rage Against the Machine! Evil Empire stranglehold".

Re:Not F/OSS (1)

Andreas(R) (448328) | about 10 years ago | (#10587826)

Actually, it's "free". See the license [nyud.net]

Yes (1)

igzat (817053) | about 10 years ago | (#10587682)

The link is down. The new protocol should help keep the internet running efficiently for the next decade or so.

Whew! (4, Funny)

PhotoGuy (189467) | about 10 years ago | (#10587688)

"TCP, the transfer protocol that most of the Internet is using

Often stories are posted that refer to products or code names, with no description, which is quite annoying.

I'm glad to see this post doesn't run that risk.

Thanks for clearing that up for me.

-d

here is the story, before it gets slashdotted (1, Redundant)

N3wsByt3 (758224) | about 10 years ago | (#10587697)

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.

Is replacing TCP necessary? (4, Insightful)

bigberk (547360) | about 10 years ago | (#10587707)

There's no doubt that an alternative to TCP might have technical merits. But as far as communication protocols go, TCP itself is pretty amazing. Modern TCP implementations have been tweaked over decades and have impressive performance and reliability. And modern TCP/IP stacks have rather unspoofable connection establishment, another excellent feature for security.

If you want to replace TCP, you have to do more than just develop a new protocol that is faster. It would have to outperform TCP in speed, reliability, and substantially so in order to outweigh the costs of ditching a well-established and trusted protocol.

Finally! (1)

germaniumdiode (823214) | about 10 years ago | (#10587716)

Yay! Something to speed up my p2p client! It was almost getting to the point where getting in my car and driving to whoever's computer I happened to be downloading from was faster than downloading it. Of course, with shareaza 2.0 http://www.shareaza.com/ [shareaza.com] out, it did get a lot faster anyway (with the support for SP2 and all).

UDP... is drwining the internet. (0)

leuk_he (194174) | about 10 years ago | (#10587718)

The internet will die in 2006.

That is what will happen if udp will be the basis for it. Since udp has no rate control build in this either has to be build at the application level or servers/routers will drown. Yes, ik know routers can drop udp packets if overloeaded, but this kind of procotol just sends more packets to compensate for the dropped packets.

Re:UDP... is drwining the internet. (2)

imsabbel (611519) | about 10 years ago | (#10587791)

So you say if telcos sell more bandwith than their infrastructure can handle there will be problems...
Uh. Wouldnt have thought THAT could happen....

Coral Cache? (0)

RAMMS+EIN (578166) | about 10 years ago | (#10587719)

If their technology is that good, why do they need Coral Cache to protect them from slashdotting? ;-)

Ugh -- eyes are playing tricks on me. (4, Funny)

IronChefMorimoto (691038) | about 10 years ago | (#10587727)

While this sounds very interesting (have to re-take all those networking certification exams again, I guess), when I read this...

The guy who started it, Petar Maymounkov, is of Kademlia fame." ...my eyes told my brain this...

The guy who started it, Petar Maymounkov, is of Chlamydia fame."

I was about to wonder what sort of "fame" you could get from that. Need coffee. Need sleep.

IronChefMorimoto

Re:Ugh -- eyes are playing tricks on me. (1, Funny)

Rosco P. Coltrane (209368) | about 10 years ago | (#10587961)

Hey you know what? when I read The guy who started it, Petar Maymounkow, is of Kademlia fame, my eyes told my brain Drop your panties Sir Arthur, I cannot wait till lunchtime.

Now that I've use some random phrase in the blurb as an excuse to coin my joke, can I get my mod point please?

Link doesn't use port 80 (1)

chiph (523845) | about 10 years ago | (#10587757)

Can someone post the text of the article? My company's firewall won't allow non-port 80 sites to be opened, even for outgoing traffic.

Slashdot editors: Please look for this in the future before including links. Thanks.

Chip H.

Re:Link doesn't use port 80 (1)

REBloomfield (550182) | about 10 years ago | (#10587943)

Ditto moi. That's why I've resisted jumping on the "won't somebody think of the children and use coral cache" bandwagon.....

Re:Link doesn't use port 80 (1)

karmatic (776420) | about 10 years ago | (#10587956)

Copy URL, remove .nyud.net:8090, and go.

Since most people will be using the cache, the site is less likely to be slashdotted.

Respect! (5, Funny)

WormholeFiend (674934) | about 10 years ago | (#10587759)

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

ANY loss level?? (4, Funny)

D3 (31029) | about 10 years ago | (#10587760)

"By using encoded, rather than plain, transmission we are able to send at speeds with any packet loss level."
I want to know how they get data transmission at 100% loss!

Can Anybody Explain? (2, Insightful)

RAMMS+EIN (578166) | about 10 years ago | (#10587762)

Can anybody explain to me how this technology? It reads like marketing speak to me, despite the fact that it will be/is released as open source. How does the technology actually achieve reliability without retransmits? Does it actually achieve it?

Not gonna work if encumbered (4, Insightful)

JohnGrahamCumming (684871) | about 10 years ago | (#10587766)

1. This is coming from a company who are surely going to want to make money out of it somehow. Part of the reason TCP succeeded is there was no one to pay.

2. They don't seem to understand the GPL:

"We are planning to release Rateless Codes for free, non-commercial use, in open source under the GNU Public License."

The GPL doesn't restrict commercial use, and hence the only way that they can do this is either they try to add some conditions to the GPL, or they use another mechanism to restrict commercial use: e.g. patents.

No matter how good this technology is it's not going to get wide adoption is an alternative to TCP unless it's unencumbered.

John.

Re:Not gonna work if encumbered (1)

Serveert (102805) | about 10 years ago | (#10587881)

So that raises this question. Why spend money researching something for 3 years when you cannot profit from it? Guess they shouldn't have researched it in the first place.

Re:Not gonna work if encumbered (1)

karmatic (776420) | about 10 years ago | (#10587979)

It's not that they can't profit from it - it's just that software is an unusual market, and they will have to act accordingly.

Perhaps they can make money selling implementations of the software. Perhaps they make it by selling closed-source versions to companies who don't want to GPL their products.

Re:Not gonna work if encumbered (1)

JohnGrahamCumming (684871) | about 10 years ago | (#10588029)

> Why spend money researching something for 3 years when you cannot profit from it?

I never said that they shouldn't be allowed to profit from it. Far from it.

What I said was that this wont be a widespread replacement for TCP specifically because of the fact that it looks to me like they'll try to license it for $$$ to commercial entities. There's no good reason why Cisco, 3Com, Nortel, etc. should want to license that particular technology.

Sure it solves a problem and improves TCP throughput on long links. But the major hardware vendors, not to mention OS people, are not going to pay a license fee for that; they'll just get together as a consortium and decide on their own TCP replacement protocol, make it available for free and all their boats will rise.

John.

Re:Not gonna work if encumbered (1)

karmaflux (148909) | about 10 years ago | (#10587960)

MySQL works quite nicely under a dual license. The basic problem is that there's actually not too much call to replace TCP -- it works.

Re:Not gonna work if encumbered (1)

mdfst13 (664665) | about 10 years ago | (#10588004)

"MySQL works quite nicely under a dual license."

Yes, but that is two *separate* licenses. This would be a single, modified version of the GPL that is not compatible with the regular GPL (which allows commercial use). MySQL *adds* options; this reduces them.

As for UDP replacing TCP... (1)

LittLe3Lue (819978) | about 10 years ago | (#10587772)

...as for UDP replacing TCP I dont care. Its cool, and im glad there are changes tryign to be made.

I doubt seriously they will be done soon. Unlike going from 32 bit to 64 bit processors, going from TCP to UDP as the primary or only method seems more useless then effective in a corporate view.

I dont see people wanting to put effort into adapting any time soon. But its still great to hear that we might.

Also, thanks for the info on Kademlia, as a noob developer, I always wondered how they did that ;)

TCP is dying... (0)

Anonymous Coward | about 10 years ago | (#10587782)

even on BSD.

Encoded Packets doesn't Solve Problems (4, Insightful)

kakos (610660) | about 10 years ago | (#10587796)

I did read their website and it looks like their revolutionary new replacement for TCP is UDP with their proprietary ECC built on top of it. However, there is a good reason why TCP never used ECC (they did exist back then).

1) The major problem a TCP packet will face is getting dropped. They mention this problem. They claim their encoding will solve this problem. It won't. No ECC algorithm will allow you to recover a dropped packet.

2) Most packets that are corrupted are corrupted well beyond the repair of most ECCs.

3) ECCs will cause packet size to increase. Not a huge problem, but why do it when ECCs don't help too much to begin with?

Re:Encoded Packets doesn't Solve Problems (5, Informative)

Another MacHack (32639) | about 10 years ago | (#10587926)

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.

Re:Encoded Packets doesn't Solve Problems (1)

kakos (610660) | about 10 years ago | (#10587955)

I did not know this. Thanks! Do you have any good literature on erasure correction?

Re:Encoded Packets doesn't Solve Problems (3, Insightful)

netwiz (33291) | about 10 years ago | (#10587954)

well, assuming that the dropped frames aren't sequential in large number, some kind of ECC (think RAID5 for IP) could alleviate this issue. Granted, you'd be sending three packets for every two packets worth of data, but you could lose any one of them and still be okay.

However, I don't think most people would necessarily enjoy 50% larger payloads required to make this work. It could be tuned back, but for every decrease in overhead, the effect of losing a frame gets worse. In the end (and this is purely speculative, as I've no real data or math to back this up) it may be that TCP remains more effective with better throughput.

I'll be honest, I don't see/experience the kinds of lag and retransmission problems that are described in the article, and any large streaming transfers to my home or desk regulary consume 100% of my available bandwidth. So for me, TCP works just fine.

Re:Encoded Packets doesn't Solve Problems (2, Interesting)

daserver (524964) | about 10 years ago | (#10587957)

Sorry this is not correct. Rateless erasure codes is ECC per complete file not per packet. Please read the paper [nyu.edu] .

Re:Encoded Packets doesn't Solve Problems (2, Informative)

hamanu (23005) | about 10 years ago | (#10588000)

You are a fuckng pompus ass...
no wait, sorry, you hit one of my buttons.

ECC codes CAN and DO cover packet loss if you interleave the ECC information accross packets, instead of just generating it for a single packet. In this scenario lost packets are called "Erasures", and their coding is "rateless erasure coding". It will work just fine.

yet another tcp replacement? (1)

koafc (718334) | about 10 years ago | (#10587813)

In research, the issue of tcp replacement is a common one. THe solutions seem to either recommend making some minor tweaks (a "light" version of TCP!) or to scrap it entirely in favor of protocol X. With that knowledge, I will keep my excitement in check as I get around to reading the article.

For once (2, Funny)

neilb78 (557698) | about 10 years ago | (#10587822)

Can't we just leave it alone.

Oh wait...nervermind, if we did that everything would work and we'd no longer be needed.

sounds good (2, Interesting)

spacerodent (790183) | about 10 years ago | (#10587842)

the real issue with any new technology like this is will it be accepted as a standard? For that to happen it needs to be relyable, easy to get (free), and hard to exploit. This looks to have all the above so in 5 to 10 years maybe we'll see this implmented everywhere.

old - so what then ? (2, Insightful)

l3v1 (787564) | about 10 years ago | (#10587856)

It doesn't seem reason enough to build a new protocol for TCP replacement just because it is "old". Protols ar not living beings you know, aging doesn't show on their cells. Of course troubles always has been popping up over the years, but nothing unsolvable (and nothing in the likings of IP).

All in all, it's good to have new alternative solutions and new technologies at hand, but to state such things as replacing TCP 'cause its age (maturity, that is :D ) is a bit winged to say the least.

Would this "steal bandwith"? (1)

enosys (705759) | about 10 years ago | (#10587858)

They say that this new protocol would tolerate higher rates of packet loss. What happens to TCP connections when a lot of connections use this new protocol? Would it create worse congestion on networks, which this protocol can tolerate, but which would greatly slow down TCP connections?

Good luck, but it will never happen (4, Insightful)

Ars-Fartsica (166957) | about 10 years ago | (#10587859)

Just look at the adoption rates on IPv6. No one is going to touch a new protocol at this stage. Its not even clear that this is needed. Point me at a specific TCP pain point that is specifically and obviously reducing internet adoption...any takers?

Yawn (4, Insightful)

Rosco P. Coltrane (209368) | about 10 years ago | (#10587864)

YAWN Protocol --> Yet Another Wonderful New Protocol

ASCII is still around, despite its numerous shortcomings. There's this small thing called "backward compatibility" that people/consumers seem to love, for some reason. Well, same thing for TCP/IP. Even IPv6 has trouble taking off in the general public, despite being essentially just a small change in the format, so never mind the YAWN Protocol this article is about...

Doesn't work. Sorry, do not collect $200. (5, Informative)

Anonymous Coward | about 10 years ago | (#10587911)

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.

SCTP (5, Interesting)

noselasd (594905) | about 10 years ago | (#10587939)

Why not SCTP ? See RFC 2960. Already in the Linux kernel, Kame, (solaris ?) and probably others.
Intro here [uni-essen.de]

- 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" :-/

Getting Old? (4, Funny)

89cents (589228) | about 10 years ago | (#10587962)

The air that I breathe, the water that I drink, and the land that I walk upon is getting really old. Someone needs to replace it all.

Really, is TCP flawed?

Security Issues (1)

beatnitup (616700) | about 10 years ago | (#10587997)

We are all aware of the nature of tcp/ip an dhow it was originally developed without security in mind...hence it was designed to trust all computers. Will this new protocol follow the same path and will it be able to communicate with computers who are using tcp/ip and will that be source of a possible vulnerability itself?

Better TCP by whose rules? (3, Insightful)

shic (309152) | about 10 years ago | (#10588015)

When considering protocols for information transport, it is very important to be absolutely sure what assumptions you are making. There are a number of non-independent factors which influence the suitability (and hence efficiency) of network protocols to application demands. Bandwidth, for example, is related to but doesn't define the statistical distribution of latencies; maximum packet rate and their relationship to packet size. The channel error rate (and statistical distributions of packet failures) are again linked to fragmentation and concatenation of transmitted datagrams - and this in turn affects latencies when considering "reliable" transport protocols. Routing policy and symmetry of physical links introduces yet more tradeoffs which need to be considered - not to mention the potential problems evaluating if the burden of protocol computations outweighs the advantage of an improved strategy for a given physical link. (And I'm not even going to mention security!) When considering protocols the most important thing to consider is the model they assume of the communications infrastructure on which they are to be deployed. TCP is likely the optimal solution given the assumptions TCP makes... if you change those assumptions to more closely fit a particular network infrastructure you will likely get better performance only on that infrastructure, but far worse performance where your new assumptions do not hold. I used to be interested in the idea of dynamically synthesizing protocols to best suit the actual physical links in a heterogeneous network... however my ideas were met with extreme disinterest; I felt my critics demanded I present a protocol which beats TCP under TCP's assumptions - and no amount of hand-waving and explanation would convince them this was a silly request. I still think the idea has merit - but having wasted 3 years of my life trying to push it uphill, I've found other interesting (and far more productive) avenues to pursue.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?