Slashdot Mirror

I worked on implementing Error correction codes over IP some time back http://www.ecip.com/

This is what we would call part of a family of Rude protocols that would do reverse Throttling.

All of these ISP are counting on TCP being polite, but it's also counting on the network being passive or at least polite as well.

In our case we originally implemented ECIP and SPAK when we had a 100KBPS video stream and 99KBPS gave us nothing but garbage. Since video is all or nothing. http://www.videotechnology.com/jessem/all_or_nothing.html

But with ISP taking a hostile approach, application writers could also start talking a more aggressive approach in a sort of arms race.

I know everyone has been afraid of this, but I feel that this is indeed a necessary step if some sort if truce is to be reached between USERS and their ISP's. Right now we are really fighting over our rights on how we can use the "last mile" since it's all now been consolidated into the hands of only a few companies. We have already lost our ability to choose and market freedom.

Is there any reason the virus's and worms can get through the P2P can't?

  Bit Torrent is already showing it's age.

  I would like to get some team together to create on based on erasure codes, ECIP http://www.ecip.com/
  or LT Code, the Luby Transform (Michael Luby), Fountain Codes (from Digital Fountain), network codes, Tornado codes, Online Codes, and Raptor codes.

  In addition the P2P engine should morph and change it's communications similar to stealth viruses do.
  So no static filtering scheme could work.

  And it should also detect networks that attempt to block them and immediately launch a DOS attack against the router and infrastructure that attempts to block them. Let's not call is DOS attack, but basically by attempting to slow or stop P2P transfers to conserver bandwidth the system just starts to pour on the traffic even higher.

  back in 1996 to 1999 Aryeh Friedman and myself worked on what we called Rude protocols, SPAC.
  the basic idea was to provide a guaranteed data throughput on the receiver side without any regard to how much it had to send on the sending side.

This is critical for fix rate video transmission if you are to get good quality and is a very different approach to the QOS RSVP where your begging ISP's to allow your traffic to have a higher priority. We just Take it very rudely.

  In 1997 we did a broadcast with Sir Arthur C. Clarke (who died yesterday) from Sri Lanka to the US.
  It was over the Island of Sri lanka's only internet connection and 64K line that had 90% packet loss.
  By pushing out almost 1 Mbps at the 64K like we were able to get a clean 60Kbps at the receive side for a live streaming video event! We had permission from the country's ISP at that time since the event lasted only for 1 hour.
http://www.livecamserver.com/ and http://www.dnull.com/~sokol/clarke.html

  But during ours test in So Cal, we were on a Dual T3 Circuit that went into Mae West, Large data interchange, pushing 10Mbps video and the network had some small outage and we pummeled the entire California internet down to an almost complete outage, 1997. this only lasted for maybe 10 minutes or so as almost every network Backbone admin was scrambled to try to stem the 100Mbps flood of UDP packets that our protocol started to push down the line.
  We took a lot of flack for that out, lost our Co-Lo at that location.

    Anyhow since that time we just added some cap's on the maximum.

  Point being, that any deliberate attempts to stem the flow would in a sense create back pressure, that would only force an increase of the data being sent, and so creating network blockages would have the opposite of the desired effect by costing them even more bandwidth instead of saving it.

  Wouldn't that be a fun thing ;)

Once you have a bi-directional UDP packet exchange going, (it's not a connection like TCP) but it is in some sense an unreliable connection.

You can then route TCP over it (grab packets from /dev/tap or /dev/tun) , or use a user space TCP stack connection or use something like my ECIP (http://www.ecip.com/) over it.

http://www.ecip.com/fwdoc.htm

We had it in our one of our livecam video streaming product in 1997

If someone out there that is willing to put the time in to implementing a reliable UDP I'd be willing to share my notes and research on how to implement my ECIP error correction over IP as well as my SPAC Protocols. (Selective Packet Acknoledgement) algorythems. They can work together for a really cool solution.

The original code was lost when my former company went bust, it's was mess anyhow.

But the algorythems can be reimplemented.

ECIP

John L. Sokol

PS: Method of passing bi-directional data between two firewalls.

I wonder if anyone that's doing this read my paper on this?

If someone out there that is willing to put the time in to implementing a reliable UDP I'd be willing to share my notes and research on how to implement my ECIP error correction over IP as well as my SPAC Protocols. (Selective Packet Acknoledgement) algorythems. They can work together for a really cool solution.

The original code was lost when my former company went bust, it's was mess anyhow.

But the algorythems can be reimplemented.

ECIP

John L. Sokol

PS: Method of passing bi-directional data between two firewalls.

I wonder if anyone that's doing this read my paper on this?

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