Selective Seeding & Discovery

Status: [source:abc/branches/boxun/d080620-selectiveseeding-from-main-r7938/Tribler/Policies/SeedingManager.py initial code]

Research: Resource allocation to peers based on their degree of contribution to the community with the inclusion of a punishment for freeriders.

Selective Seeding

Enable the user to select the seeding policy he/she wants for give-2-get and within the limits allowed by tit-4-tat.

The default policy setting is to seed to tit-4-tat peers until your sharing ratio in that swarm equals 1.0. Note that it is important in this calculation to keep separate sharing ratio's for tit-4-tat and give-2-get peers. Both give-2-get and tit-4-tat peers will be treated equally when the tit-4-tat sharing ratio has not yet reached 1.0. After the tit-4-tat ratio has reached 1.0 only give-2-get peers will receive bandwidth, thereby boosting the peers bandwidth reputation.

After seeding for a hours or a few days to tit-4-tat peers they can remain in a swarm for weeks or months to boost their reputation. This approach means that an efficient mechanism for discovery of give-to-get peers is required which requires little bandwidth.

The selective seeding has the following settings:

  • tit-4-tat: (Forgets about uploads)
    • Seed until UL/DL ratio >= 1.0 (no Bittorrent leeching) default
    • Unlimited seeding
    • Seeding for x day, y minutes
    • No seeding
  • give-2-get: (Remembers every upload)
    • Seed only to peers with UL/DL ratio > 0.8
    • Unlimited seeding (Boost your reputation) default
    • Seeding for x day, y minutes
    • No seeding

Implementation:

A global seeding manager manages all local seeding managers for seeding downloads. When a download status becomes seeding, the global seeding manager will apply a local seeding manager to the Choker of that download, which is based on the seeding settings. Then the local seeding manager decides if a connection is eligible or not to be unchoked by Choker.

  • The [source:/abc/branches/boxun/d080620-selectiveseeding-from-main-r7938/Tribler/Policies/SeedingManager.py SeedingManager.py]
  • The [source:abc/branches/boxun/d080620-selectiveseeding-from-main-r7938/Tribler/Core/BitTornado/BT1/Choker.py Choker.py]

Extension in other GUI screens: Future work

  • Convert bandwidth into reputation
    Link with CooperativeDownload
    • Find swarms with active downloading Tribler peers
    • Use Swarm_FFFF?
    • Do partial download of desired pieces
    • Upload to Tribler peers to boost reputation
  • Link with Meulpolder work on transfer reputation to a friend.
  • Show that you are seen as a leecher and have bad performance
    • Howto inform them of behavior
    • Howto ensure they have poor performance
    • Howto enable new users to bootstrap (Whitewashing proof)
    • Special 1 GByte upload task to enable video-on-demand

Related Work

​PDF link One hop Reputations for Peer to Peer File Sharing Workloads to prevent freeriding in Bittorrent.

Selective Discovery(Soon)

G2G seeders/leechers proactively search for other g2g peers in networks.

A simple heuristic to include is to give preference to peers which use the listen port used by default within Tribler. Whenever such peers are included in tracker or PEX replies they take priority. When contacted with PEX, a Tribler peer lists other G2G supporting peers in the swarm. This can perhaps be done via PEX parameter=value extensions.

  • Selection of g2g peers: What should be the proper portion of g2g peers among those selected peers to be connected in PEX messages? Including as many g2g peers as possible, or reserving some seats for t4t peers? If latter, some poor performed g2g peers will be dropped, then g2g score and bartercast may be proper selection criteria.
  • Remote g2g peers uploading for long time can be saved locally, and used by local peers in future,

The [source:abc/branches/mainbranch/Tribler/Core/DecentralizedTracking/ut_pex.py#L55 added.f field] seems to be the proper mechanism to do this within the EXTEND message. It gives can store a single byte of information about each address you exchange with PEX. Currently only 3 values are specified. See detaild documentation ​on a the Transmission branch.

ToDo: find which Bittorrent client are using which fields and claim our own "bit" (e.g. x16) in this added.f which indicates seeding to Give-to-Get supporting peers only. With this mechanism we can indicate to other peers what the exact state is of the Give-to-Get peers. Obviously, these peers are not PEX-ed or handed out to tit-for-tat peers.

Does Tribler support the extended field in PEX for client IDs: v=string, client name and version. (e.g. "Transmission 0.7" or "Tribler 4.1.7")? Can it be used to recognize fellow Give-to-Get supporters?