Abstract:
Transfer policy management methods in a peer-to-peer networking environment such as BitTorrent are provided. A download TPM maximizes the usage of available bandwidth, while focusing on as few torrents as possible. For a given list of torrents, a peer in accordance with the present invention determines how many download connections to maintain at a given time in order to maximize usage of bandwidth. If the variance of per-connection bandwidths exceeds a threshold, more connections are added until either variance does not exceed the threshold or a maximum number of connections are established. A seeding peer determines when to reduce the number of files being seeded by monitoring its average upload rate per torrent. If its average rate falls below a threshold, then the peer stops seeding a file. The file that the peer stops seeding is one to which the peer is making the smallest overall contribution.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of provisional application 60/745,736, filed on Apr. 26, 2006, and which is incorporated by reference herein in its entirety. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention is related generally to peer-to-peer file transfers. In particular, the present invention is directed toward download policy and seed policy management in a peer-to-peer environment. 
     2. Description of Background Art 
     A peer-to-peer (P2P) network is one in which client computers exchange information with other client computers (also known as nodes) without the need for a server acting as an intermediary. P2P networks are frequently used to allow nodes to exchange files. A node that provides a file for downloading by other nodes is known as a seed for that file, and other nodes establish a connection to the seed to obtain the file. In some P2P environments, a file is obtained by a node from a plurality of other nodes, rather than from a single seed. 
     Each node in the P2P network is typically responsible for determining how much of its available bandwidth to allocate for downloading. Conventional approaches include downloading all desired files simultaneously, or downloading a predetermined maximum number of files simultaneously. However, these approaches do not use bandwidth in an efficient manner. 
     A node acting as a seed for one or more files must also determine when it should stop acting as a seed for each file, in order to maximize efficient use of bandwidth. 
     Conventional approaches include seeding all files simultaneously; simultaneously seeding a fixed number of available files; seeding only those files which were received after a certain fixed time horizon, e.g., within the last 24 hours; or simultaneously seeding only those files for which the seed has sent a total amount of data less than some fixed percentage of the file, e.g., upload up to 200% of the size of the file, and then stop. Again, these approaches have not led to an efficient use of bandwidth. 
     SUMMARY OF THE INVENTION 
     The present invention enables transfer policy management (TPM) methods in a peer-to-peer networking environment such as BitTorrent. 
     A described download TPM maximizes the usage of available bandwidth, while focusing on as few torrents as possible. For a given list of torrents, a peer in accordance with the present invention determines how many download connections to maintain at a given time in order to maximize usage of bandwidth. If the variance of per-connection bandwidths exceeds a threshold, more connections are added until either variance does not exceed the threshold or a maximum number of connections are established. 
     A seeding peer determines when to reduce the number of files being seeded by monitoring its average upload rate per torrent. If its average rate falls below a threshold, then the peer stops seeding a file. The file that the peer stops seeding is one to which the peer is making the smallest overall contribution. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a swarm in accordance with an embodiment of the present invention. 
         FIG. 2  illustrates a system for transfer policy management in accordance with an embodiment of the present invention. 
         FIG. 3  illustrates a method for download transfer policy management in accordance with an embodiment of the present invention. 
         FIG. 4  illustrates an alternative method for download transfer policy management in accordance with an embodiment of the present invention. 
         FIG. 5  illustrates a method for seeding transfer policy management in accordance with an embodiment of the present invention. 
     
    
    
     The figures depict preferred embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein. 
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     One peer-to-peer protocol is the BitTorrent protocol. In the BitTorrent protocol, a peer shares a file by creating a torrent. A torrent is itself a file that comprises data about the file to be shared as well as the location of a tracker. The torrent file is typically distributed, e.g., by being posted on a web site, and is obtained by peers seeking to obtain the original file. When a peer obtains the torrent file, the peer examines the torrent to identify the location of the tracker. The peer then contacts the tracker, which tells the peer where to find the seed for the file. A group of peers connected to each other to share a torrent is known as a swarm. 
       FIG. 1  illustrates a swarm in accordance with an embodiment of the present invention. Peer  102  is downloading files from peers  104   a ,  104   b , . . . ,  104   n  via a network  106 . 
     Download Transfer Policy Management 
       FIG. 2  illustrates a system  200  for transfer policy management in accordance with an embodiment of the present invention. System  200  in one embodiment is a software application that is executed as part of or in conjunction with the P2P protocol on peer  102 . System  200  includes a bandwidth monitoring engine  202 , a download connections manager  204 , and a seed manager  206 . The operation of each component is explained further below. 
     A method for download transfer policy management in accordance with an embodiment of the present invention is described with reference to  FIG. 3 . Each torrent download has a variable number of connections to peers. Initially, peer  102  starts  302  some number, N, of initial download connections, which in one embodiment is small enough to not consume all available download bandwidth, but large enough to collect network statistics that are diversified across the individual characteristics of particular transfers. In one embodiment, N is chosen based on the typical ratio of download to upload bandwidth offered by consumer ISPs. Alternatively, N can be less precisely specified, by instead choosing a number of torrents to start, M, so that N is roughly M times the average number of connections per torrent; or N can be specified by a user. 
     Once the N connections are active, their bandwidth usage is observed  304  by bandwidth monitoring engine  202 . If  306  the variance of observed per-connection bandwidths exceeds some threshold, X, for some span of time, T, downloads connections manager  204  attempts to establish  310  more connections, potentially by starting more torrents. This is based on the observation that fully-saturated channels typically balance bandwidth more evenly across connections than channels with bandwidth to spare. X and T may be chosen based on experimental data, and in one embodiment T is 60 seconds and X is 0.75. In one embodiment, as illustrated in  FIG. 3 , a check is made  308  to determine whether a maximum number of active connections has already been reached, prior to establishing additional connections. 
     As an alternative to maximizing the usage of available downstream bandwidth as described above, and referring to  FIG. 4 , an optimization can instead be performed on allocation of available upstream bandwidth. In one embodiment, a peer  102  accepts as much data for download as is offered to it, but limits the number of connections on which it uploads data. In protocols such as the BitTorrent protocol that limit a download rate based on the client&#39;s upload rate, this method indirectly limits the download rate. 
     In such an embodiment, peer  102  begins by uploading  402  data on zero connections, and periodically increments  404  the number of connections to which it uploads. This continues for as long as the client&#39;s reciprocation increases  406 . Reciprocation is the number of bytes downloaded granted for each bite uploaded. If reciprocation decreases, peer  102  reduces  408  the number of connections to which it uploads. 
     Seeding Transfer Policy Management 
     When seeding multiple files, a peer  102  must decide which and how many files to seed at any given time, assuming that the peer  102  has more than one file it can seed. Ideally, the selection of files to seed should result in the greatest amount of available bandwidth being used, and the greatest overall file availability being achieved. 
     Referring to  FIG. 5 , a peer  102  in one embodiment begins by seeding  502  all of the torrents it has available to seed, and subsequently determines when to stop seeding one of them, and which one to stop seeding. In one embodiment, the criteria for whether to stop seeding a torrent is based on the average upload rate for all connections on all seeded torrents. Seed manager  206  monitors  504  the average upload rate. If  506  the average upload rate drops below a minimum threshold, T, seed manager  206  stops  508  seeding a torrent, as selected by one of the criteria below. It is advantageous from an efficiency perspective to choose to stop seeding the torrent to which the client is making the least valuable contribution. 
     There are at least three criteria that can be used to determine which seed to stop seeding once the average upload rate falls below the specified threshold. 
     In the BitTorrent protocol, each peer  104   a ,  104   b , . . . ,  104   n  reports its total download rate—that is, the sum of all download rates on all connections for the torrent in question—to all other peers on the torrent, including the seeding peer  102 . In one embodiment, the torrent that peer  102  selects to stop seeding is the torrent for which the peer&#39;s upload rate accounts for the smallest percentage of the total download rate reported by peers to which it is uploading. 
     In an alternative embodiment, the torrent to stop seeding is the one for which the most complete copies exist in the network, relative to the number of peers downloading the file. Each peer has knowledge of only a limited portion of the peers involved in any particular torrent, so this calculation is based on the limited knowledge of the peers. 
     In another alternative embodiment, peers attempt to maintain an even distribution of pieces in the network. For example, in the BitTorrent protocol, peers typically download pieces in random order, or will download rarer pieces sooner, in order to keep any one piece from becoming more common than another. As a result, where multiple complete copies of a file exist on the network, the distribution of pieces held by a given peer will be close to random, and the correlation of one peer&#39;s pieces with another client&#39;s will be low. If, however, the correlation is high, this indicates that some pieces are hard to find. Accordingly, the file that seeding peer  102  stops seeding is the one for which the correlation between the piece inventories of peers to whom the seeding peer  102  is uploading is lowest. 
     Note that the methods described above for determining when to stop seeding a file apply equally to a peer  102  that is uploading only a portion of a file—that is, peer  102  may not have all pieces of a file, and therefore is not classified as a seed, but may nonetheless upload to other peers th pieces it does have. The methods described above for efficient use of bandwidth in the seeding context apply as well to the general case of uploading only portions of a file. 
     The present invention has been described in particular detail with respect to a limited number of embodiments. Those of skill in the art will appreciate that the invention may additionally be practiced in other embodiments. First, the particular naming of the components, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, as described, or entirely in hardware elements. Also, the particular division of functionality between the various system components described herein is merely exemplary, and not mandatory; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead performed by a single component. 
     Some portions of the above description present the feature of the present invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are the means used by those skilled in the networking and data transfer arts to most effectively convey the substance of their work to others skilled in the art. These operations, while described functionally or logically, are understood to be implemented by computer programs. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules or code devices, without loss of generality. It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. 
     Certain aspects of the present invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present invention could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by real time network operating systems. 
     The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability. 
     The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description above. In addition, the present invention is not described with reference to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any references to specific languages are provided for disclosure of enablement and best mode of the present invention. 
     Finally, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention.