The problem with most P2P optimizations, such as ALTO is that they must be supported by many applications that are developed as a community effort or are strongly user-demand driven in other ways. This means any adoption of optimization depends on the user-perceived value of such optimization.
This means that any optimization must perform as least as good or preferably better than an unoptimized variant would on an open, neutral network. Comparing against traffic shaped network is not a realistic option as traffic shaping drives the demand for obfuscation, leads to an arms race rather than asking the ISP's servers to support the very file sharing applications it's sabotaging at the same time (i'm talking about aggressive traffic shaping here). I.e. the stick does not work very well.
So... how can the carrot look like? Preferring locality does not really work if a swarm is seeded by a handful of very fast seeds in (standard example:) sweden or japan, most peer selection operation in general can only be strongly biased if the swarm is already saturated with bandwidth since the peers are already optimizing for maximum throughput, any deviation from that scheme could mean less-than-optimal performance, from the user perspective.
The general point is that there is only a limited amount of upload bandwidth within the global pool of peers. All ALTO&Co can do is redistributing from the pool, which means it would be a disadvantage to some users and thus a disincentive.
To provide a real incentive to end users there are 2 ways, either it could be monetary or improved download performance. The basic idea of the monetary incentive is to charge extra for non-optimized traffic, e.g. some austrialian ISPs charge extra for "international" traffic in general. But since users like flat pricing that's probably not such a good option.
Providing "real" bandwidth improvements for peers can be done either through caches or something i call "shadow bandwidth", i.e. bandwidth that's physically available on the connection to the user but not part of his broadband plan. E.g. if he is paying for a 20/5 plan but the line is physically capable of 50/20 then we'd have a shadow bandwidth of 30/15. Such bandwidth is already used in some scenarios do deliver VoIP or VoD w/o interference from the internet traffic. If this shadow bandwidth would be made available to local (or otherwise optimized) connections then this would provide a significant incentive to adopt such optimization schemes.
Caches can also provide an incentive since many swarms are not capable of saturating the users' downlink, but as users can be members of private, ratio-tracking sites or caches themselves only participate in uploading to external peers to a very limited extent they can only reduce the upload of a user indirectly by providing bandwidth that has not to be provided by someone in the global pool of peers.
Other options are: multicast and symmetric connection. Multicast dramatically reduces the number of nodes that have to upload and symmetric connections make your local peer as good as any as most peers will be able to reciprocate at your own upload rate on average, which would mean locality-optimizations wouldn't be a dis-incentive at least.
Long story short:
- incentives for and against adoption from the enduser perspective should be consided in the design of such optimizations
- the stick probably won't work. you do not feed the jaw that bites you
- going easy on the ISP infrastructure is not a carrot from the user perspective if it has noticeable, negative impact on the throughput, not just on average but also for individual users
- cost savings or improved download speeds are real incentives for endusers
- any centralized solution will be watched with a wary eye as they'll be run by cooperations that might be considered as hostile by users in the light of stories like this one: http://torrentfreak.com/uncovering-the-dark-side-of-p4p-080824/ thus privacy and lawyer-resistance should be design-goals of any P2P-infrastructure as this would otherwise prove to be a disincentive for adoption
--
The 8472
independent developer for the Azureus Vuze Bittorrent client
