Sunday, February 25, 2007

Technical Overview

There are two basic models for applying BitTorrent capabilities to the iTunes Store. First, iTunes could rely on the most basic extension of BitTorrent – simply distributing movie files through already existing BitTorrent clients. This model would consist of users downloading the files from their peers and then acquiring a license from the iTunes Store in order to play the protected files. Though this would be a relatively simple implementation, the lack of control of this system leaves it lacking in robustness and reliability. In short, for Apple to use BitTorrent in an economically viable way and provide the reliability and quality of service that customers demand from a pay-service, Apple must be able to control the system in order to maintain its quality.

Instead, we believe it is necessary for Apple to take a more centralized approach which will greatly increase the robustness and quality of the BitTorrent service provided. Using a partially centralized model, Apple will incorporate a BitTorrent client into iTunes, which will be activated whenever iTunes is running and will be used solely for trading iTunes-provided content. When a user wishes to download a movie, they will initiate the download at the iTunes Store. The store will activate the equivalent of a BitTorrent ‘tracker’ which will connect the user to other users which have the same content and start the file transfers.

A central iTunes server will manage who has purchased licenses to view the movies, and with this list will be able to set up trackers for the iTunes BitTorrent client (“iTorrent”) to use. The advantage of such a system is that iTunes must already store this information, and the iTorrent client can take advantage of the records held on the central server. Furthermore, the client application can be easily controlled to only share properly licensed files with clients who have purchased licenses for the same files through iTunes already. By using this centralized iTorrent client system, user client nodes within the network can easily perform ‘handshakes’ to determine the legitimacy of file transfer requests. Furthermore, this system will be transparent to the user; that is, the user will initiate the download from the iTunes site and will not know whether their download source is the iTunes central server or peer clients.

One main issue that this system will have to address is that of populating the network with these files in the first place. For any p2p client to function, there is the need for seed nodes, which contain the files to be transferred in their entirety. Furthermore, a certain density of files on the network, which I will refer to as a critical mass, is required to ensure download speed and connection stability. In order for the system to perform at high enough standards of quality to ensure customer satisfaction, the iTorrent system will have to be supplemented through the iTunes central server. Basically, this entails monitoring the network to track the prevalence of files on the network. If the file availability is below a certain threshold, the central server will have to bear the burden until the critical mass is restored. Of course, the central server will have to provide much of the content until a critical mass is reached, and even afterwards may have to contribute on and off, as nodes enter and leave the network, and users potentially delete files.

The iTorrent model will also employ a reporting system. The main tasks of the reporting capability are (a) to update the central server as to file availability and (b) to track upload amounts. By tracking the amount of data uploaded, clients will report how much users “shared,” and allow Apple to provide monetary incentives in proportion to the contribution by individual users to the network functionality. This will be something like $1 toward the iTunes store for every 10,000 megabytes uploaded. Actual reward to be determined. This model will include options to allow users to only upload while downloading or while the computer is idle.

I intend to research
  1. How to determine the "critical mass" required
  2. Verification models
  3. Expected user upload quantities to help gauge reward amounts?
  4. DRM models for the distribution of protected files from a variety of sources
  5. Sharing models to determine what percentage of customers must be sharing to create a robust network.

“And that’s all I have to say about that.”

No comments: