Slashdot Mirror
P2P - From Internet Scourge to Savior
microbrewer writes "The MIT Technology Review has up a feature discussing the future of p2p networks. Specifically, they look at their role in content distribution, in the age of ubiquitous video services. Soon, the article asserts, the very same p2p-style networks that 'threatened' legitimate business may be the basis for most video-on-demand services." From the article: "So how could additional P2P traffic actually be a good thing for the Internet? Carnegie Mellon's Zhang points out that because peer-to-peer networks exploit both the downlink and uplink capacities of users' Internet connections, they distribute content more efficiently than centralized 'unicast' technologies. Zhang also says it should be possible to label P2P traffic so that service providers can track it and decide how much of it to allow through their networks. He and colleagues from the University of California at Berkeley have founded a startup, Rinera, to develop software that will give service providers such control."
It is a good theory that moving distribution to many decentralised locations will improve content distribution. But present-day distribution networks and large-bandwidth sites have already bought and installed the infrastructure to send large volumes of bandwidth to Tier-1 ISP distribution points, and so forth to smaller ISPs etc. This works today.
I am agreed that P2P isn't necessarily bad - in fact if P2P algorithms could favour traffic within the same subnet, or indeed allow an ISP to somehow inform the P2P client which nodes are on the same ISP, then an ISP could actually benefit as traffic fills up the internal pipes and less traffic has to be purchased from other ISPs.
To expand on this point, perhaps a multicast protocol like DHCP on the local subject could be implemented; call it the "ISP IP Directory" protocol, or IID, and basically a P2P client would send a multicast query to the IID address with a query ("is x.x.x.x within your network? Or within your preferred peers?") and the IID server would respond with a yes/no. Then P2Ps could optimally download from preferred addresses..!
A shift in thinking in the design of P2P protocols is required if we really want to optimise bandwidth and content distribution.
Seriously.. everyone i knew from close family to the furthest acquaintance didn't think broadband was necessary or worth it until p2p traffic caught on.
yeah... all those people are using that 4-10 megabits a second so cnn.com will load faster.. riiight.
VLC FOR MAC IS DYING! IF YOU DEVELOP, PLEASE SAVE IT!!
P2P has one major problem - most broadband connections are asymmetric. Very, very asymmetric - ratios of 10:1 download:upload are common. Thus, in order for P2P to be able to saturate downstream bandwidth everyone would need to keep their P2P apps open for 10 times as long as it takes to download what they want. I don't think you're ever going to get a useful proportion of people to do this without a definite incentive. The cost of the bandwidth per movie is pretty small - I'd guess a few tens of cents. So econmically that's the value of the incentive you can offer. Are people really going to leave their PC on or an application open for hours and hours when they're not using it for the few tens of cents worth of incentive it would be economic to provide? I just don't see you average consumer doing this. It's cheaper to buy bandwidth from a major ISP than it is to 'buy' a hundred million tiny chunks of bandwidth from ten million customers. P2P works if people know they're helping the 'community' or getting something for free. Linux ISOs? P2P. Warez? P2P. Official Disney movies? Not so much.
If you want to reduce bandwidth usage then reduce the number of packets you have to send. Multicast is the right answer. MBone and IPV6 have been around for a long time now. They just aren't very profitable for ISPs, so the push will have to come from the content providers.
Chernobyl 'not a wildlife haven' - BBC News
You're right, of course. But that's tangential, it simply provides the mechanism by which monied interests can make sure they get their way.
The issue I see is that the content distributors and the bandwidth providers can work together to get a lock on high profits for both. We're all familiar with the DMCA. But with the right tools (like what the author has created a company to do) the bandwidth providers can lock out the last competing method of distribution.
The best solution I see is to designate bandwidth providers as common carriers, so that it will be illegal for them to discriminate between packets. Then again, that's government interference, so I'm sure a lot of the libertarians and anarchists here will disagree...
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
This is an idea whose implementation I've been waiting on for a long time. I would love to have a closet in my house with a computer 'core'. Something that can be large enough to have enough cpus and hard drives to serve a family with thin clients. I think in the future this will be a standard instillation on new house builds.
Caps are the wrong approach. Dynamic traffic management is the only viable option, with priorities set by the time-critical nature of the data.
If BitTorrent protocols carried a data type specifier, perhaps a simple MIME type identifier, then the traffic management facilities might be enhanced to consider that information. It would also be reasonable to implement local BitTorrent cache servers so that when you do a transfer, you're effectively getting most of your data from within the ISP.
If the data file contents are encrypted with public or private keys, you can effectively get a VPN/mesh network of digitial content. Application installers, directory overlays (ala NIS+), etc. Your subscription to the originator provides you the public keys for decrypting the content, either to do an install, local media burn, or direct content access.
DRM is just hardware acceleration.
I do not fail; I succeed at finding out what does not work.
Thinking about it, the one hole to the approach is that you're relying on content providers/publishers (including individuals) to be honest about the content of crypto containers. But as the key infrastructure provides identification of the signing encryption authority, that can be used to monitor abuses and automatically choke off those who claim they're sending a media stream or application library, but actually distributing illegal or infectious content.
I do not fail; I succeed at finding out what does not work.
The telcos/ISPs write the laws, so "common carrier" means whatever they want it to mean.