Add a Comment Now - We Want to Hear From You
Now most enterprise network engineers are the type that want to block BitTorrent on the company networks, because opening lots of connections and maxing out the pipe can slow the network if there aren’t adequate safeguards in place – QoS policies based on protocol or application, for example – to prevent P2P apps from hogging bandwidth. Still, P2P in general, and even BitTorrent specifically, might help with a more efficient distribution of information on an Intranet.
And of course, there’s a large portion of the network engineering population that hates BitTorrent on their company network but loves it on their home machines.
Back in May, Slashdot wrote about the Ono project, which is a software plug-in that:
“allows P2P clients to efficiently identify nearby peers, without requiring any kind of cozy relationship between ISPs and P2P users. Using results collected from over 150,000 users, they have found that their system locates peers along paths that have two orders of magnitude lower latency and 30% lower loss rates than those picked at random by BitTorrent, and that these high-quality paths can lead to significant improvements in transfer rates.”
In short, it’s (theoretically) good for the end-user because it speeds up the download, and it’s good for whatever is serving as the ISP because it reduces connections over longer (and presumably more expensive) connections. Aqualab, the makers of Ono stated that in their testing:
In challenged settings where peers are overloaded in terms of available bandwidth, Ono provides a 31% average download-rate improvement; in environments with large available bandwidth, Ono increases download rates by 207% on average (and improves median rates by 883%).
I passed it up but was recently reminded of the Ono project by a friend of mine. So I thought I would check it out. In order to do so, I did a little informal test here at the office – please excuse my lack of scientific rigor, but Zombie Feynman should agree with me – with the Ono plugin for the Vuze/Azureus BitTorrent client.
Now, there’s really no such thing as a really controlled environment for a BitTorrent test – Ono’s averaging seems to be the best, but what we did was download the i386 version of the latest version of Ubuntu via torrent six times, alternating between using Azureus’s default settings and the Ono plugin.
| Start (Wed., July 16) | Time Elapsed (mm:ss) | Avg. Throughput | |
| Control 1 | 10:35 AM CST | 14:30 | 798 kB/s |
| Experiment 1 | 10:51 AM CST | 22:40 | 511 kB/s |
| Control 2 | 11:15 AM CST | 15:15 | 759 kB/s |
| Experiment 2 | 11:32 AM CST | 13:49 | 838 kB/s |
| Control 3 | 11:49 AM CST | 13:31 | 857 kB/s |
| Experiment 3 | 12:06 PM CST | 14:06 | 821 kB/s |
Inconclusive? You bet!
At any rate, we didn’t see any massive differences in speed between using the Ono plugin than not using it. Considering that the slowest speed in the test was made using the Ono plugin, and the fastest speed was made with Azureus’s default settings, it certainly didn’t make us hopeful that the Ono plugin could deliver what it promised.
Then again, there are some caveats: There might be some overlooked misconfiguration on our end – or maybe we misunderstand the purpose of Ono and tested it under conditions that do not take advantage of the plug-in. As I mentioned earlier, this is not a scientific test. Still, I encourage others to test out the plug-in as well – if nothing else, the concepts behind Ono are sound, and if Ono succeeds and becomes a default part of BitTorrent clients, independent testing can help produce a more efficient network overall.
Comments
As the author of the Ono plugin, I figure you might appreciate some feedback.
Regarding your results, it is difficult to run controlled experiments because even when you download the same torrent, you're doing it at different times with necessarily different swarms. My research group's evaluation is not limited by this, and we showed that performance improves *on average*. It is impossible to guarantee that everyone at all times will see performance gains. However, there is no fundamental reason why Ono would reduce performance: Ono doesn't lock you in to peers that are slower -- if there are faster peers farther away, the BT protocol will find them and use them. If there are faster peers nearby, though, Ono will locate them quickly and ensure that you keep using them. In certain networks, this can dramatically improve performance.
Also note that if Ono doesn't find any nearby peers, it can't help your performance. You can see if Ono found nearby peers (and is using them) in the "Ono" plugin view. Generally, it's a big Internet out there and you are less likely to find nearby peers with a smaller swarm (e.g., a Linux distro) than one with tens of thousands of peers. Also, the plugin's effectiveness is limited by the fact that "only" 180,000 users have installed Ono. The more people use it, the more likely you'll find nearby peers.
One last point -- even when Ono doesn't dramatically improve performance, it encourages better "Internet citizen" behavior. Why transfer data from halfway across the world when you can get the same data and (potentially better) performance from peers nearby? Ono makes it easier to do the latter, which should eventually help everyone using the Internet.
Posted by: David Choffnes | July 19, 2008 11:25 AM