[quote]e.g.:
“As an example, consider a transfer of a 1 GB file with the average Internet packet loss rate (2%) and global average RTT (just over 200 msec). In this specific case, TCP would take more than 7 hours to transfer the file. With Digital Fountain, on a fully utilized T1 link, the transfer of the 1 GB file will take about 1.5 hours, and on a fully utilized T3 link the transfer time will be a little over 3 minutes. That translates to a 3X to over 100X improvement.”
WTF? Only a marketing droid or an idiot would use an example with 200msec delay - I get less than that to almost everywhere in the world except Asia and Australia from my 56k modems. Everyone with the most basic grasp of mathematics knows there is absolutely no point in taking a global average of latency for measuring protocol performance. The modal average would at least make sense and have some value here, although if they wanted to do it properly (convincingly) they’d cite the 1 SD range, and do 3 figures for min/mid/max.
[/quote]
Look at http://www.internettrafficreport.com/main.htm
The delays they quote seem reasonable based on the measured data.
[quote]In addition, TCP is alleged to take “more than 7 hours” to transfer a file at an unknown bandwidth. They quote figures for their tech on T1 and T3, and compare them to this 7 hours to give a “3X to over 100X improvement”. Huh? Perhaps they were measuring from a 56kbps modem? If not, why not quote figures for TCP on T1 and T3 - it’s deeply unconvincing that they only quote one figure, suggesting that they probably did test at a different bandwidth altogether. This is the kind of statement you frequently see from companies claiming to have invented faster-than-light communications and other such dross.
[/quote]
Actually I believe elsewhere they prove that with TCP the RTT delay and % of lost packets imposes a theoretical limit regardless of the bandwidth. I admit I don’t know much about the theory behind that, other than I have heard the same from a couple people.
[quote]Also, speaking as someone who actually has transferred 1GB files via high speed connections over the internet before - it takes a heck of a lot less than 7 hours.
[/quote]
But of course you also stated that you didn’t have a delay of 200ms. That would make a big difference.
[quote]Since Fountain Pool enables clients to receive data from multiple Transporter Fountains, it is, in effect, a type of load sharing."
i.e. multi-stage caching.
[/quote]
That is completely optional. It is one method that they presented to have the receiver control the rate - by listening to many broadcasts or few broadcasts the receiver can adjust dynamically to implement a rate control algorithm.
[quote]If it’s the group-theory encoding described above, then WITHOUT synchronization, X here is signficantly greater than the number of packets that a perfect TCP link would use.
[/quote]
No, X is very close to the amount of data in the original file. I think it depends very slightly on which packets were received - but statistically the average would be very good.
I have seen cases studies done by a third party that was evaluating this technology. In there example they were transferring large files between North America and Europe and the gain over standard FTP was huge.
To quote some of the other papers I have from these guys:
“What is not widely understood is that TCP is slow and erratic for large data transfers when the distance between the sender and receiver is large, even when the amount of available end-to-end bandwidth is high. When using FTP over high-speed networks with even modest delay or loss, absolute throughput is limited to a small fraction of the available bandwidth.”
Having spoken with these guys on the phone and read many of their papers I trust that they have “done the math” and understand the intricacies of TCP much better than me.
