{% trans netdb=site_url('docs/how/network-database') -%} Peer profiling is the process of collecting data based on the observed performance of other routers or peers, and classifying those peers into groups. Profiling does not use any claimed performance data published by the peer itself in the network database. {%- endtrans %}
{% trans %}Profiles are used for two purposes:{% endtrans %}
{% trans -%} Peer selection is the process of choosing which routers on the network we want to relay our messages to go through (which peers will we ask to join our tunnels). To accomplish this, we keep track of how each peer performs (the peer's "profile") and use that data to estimate how fast they are, how often they will be able to accept our requests, and whether they seem to be overloaded or otherwise unable to perform what they agree to reliably. {%- endtrans %}
{% trans threatmodel=site_url('docs/how/threat-model') -%} Unlike some other anonymous networks, in I2P, claimed bandwidth is untrusted and is only used to avoid those peers advertising very low bandwidth insufficient for routing tunnels. All peer selection is done through profiling. This prevents simple attacks based on peers claiming high bandwidth in order to capture large numbers of tunnels. It also makes timing attacks more difficult. {%- endtrans %}
{% trans -%} Peer selection is done quite frequently, as a router may maintain a large number of client and exploratory tunnels, and a tunnel lifetime is only 10 minutes. {%- endtrans %}
{% trans pdf=url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf'), url='http://web.archive.org/web/20100413184504/http://www.pet-con.org/index.php/PET_Convention_2009.1' -%} For more information see the paper Peer Profiling and Selection in the I2P Anonymous Network presented at PET-CON 2009.1. See below for notes on minor changes since the paper was published. {%- endtrans %}
{% trans url='http://'+i2pconv('idk.i2p/javadoc-i2p')+'/net/i2p/router/peermanager/PeerProfile.html' -%} Each peer has a set of data points collected about them, including statistics about how long it takes for them to reply to a network database query, how often their tunnels fail, and how many new peers they are able to introduce us to, as well as simple data points such as when we last heard from them or when the last communication error occurred. The specific data points gathered can be found in the code. {%- endtrans %}
{% trans -%} Profiles are fairly small, a few KB. To control memory usage, the profile expiration time lessens as the number of profiles grows. Profiles are kept in memory until router shutdown, when they are written to disk. At startup, the profiles are read so the router need not reinitialize all profiles, thus allowing a router to quickly re-integrate into the network after startup. {%- endtrans %}
{% trans -%} While the profiles themselves can be considered a summary of a peer's performance, to allow for effective peer selection we break each summary down into four simple values, representing the peer's speed, its capacity, how well integrated into the network it is, and whether it is failing. {%- endtrans %}
{% trans -%} The speed calculation simply goes through the profile and estimates how much data we can send or receive on a single tunnel through the peer in a minute. For this estimate it just looks at performance in the previous minute. {%- endtrans %}
{% trans -%} The capacity calculation simply goes through the profile and estimates how many tunnels the peer would agree to participate in over a given time period. For this estimate it looks at how many tunnel build requests the peer has accepted, rejected, and dropped, and how many of the agreed-to tunnels later failed. While the calculation is time-weighted so that recent activity counts more than later activity, statistics up to 48 hours old may be included. {%- endtrans %}
{% trans -%} Recognizing and avoiding unreliable and unreachable peers is critically important. Unfortunately, as the tunnel building and testing require the participation of several peers, it is difficult to positively identify the cause of a dropped build request or test failure. The router assigns a probability of failure to each of the peers, and uses that probability in the capacity calculation. Drops and test failures are weighted much higher than rejections. {%- endtrans %}
{% trans -%} As mentioned above, we drill through each peer's profile to come up with a few key calculations, and based upon those, we organize each peer into three groups - fast, high capacity, and standard. {%- endtrans %}
{% trans -%} The groupings are not mutually exclusive, nor are they unrelated: {%- endtrans %}
{% trans url='http://'+i2pconv('idk.i2p/javadoc-i2p')+'/net/i2p/router/peermanager/ProfileOrganizer.html' -%} These groupings are implemented in the router's ProfileOrganizer. {%- endtrans %}
{% trans -%} The size of the groups may be limited. {%- endtrans %}
{% trans -%} Summaries are recalculated, and peers are resorted into groups, every 45 seconds. {%- endtrans %}
{% trans -%} The groups tend to be fairly stable, that is, there is not much "churn" in the rankings at each recalculation. Peers in the fast and high capacity groups get more tunnels build through them, which increases their speed and capacity ratings, which reinforces their presence in the group. {%- endtrans %}
{% trans -%} The router selects peers from the above groups to build tunnels through. {%- endtrans %}
{% trans -%} Client tunnels are used for application traffic, such as for HTTP proxies and web servers. {%- endtrans %}
{% trans -%} To reduce the susceptibility to some attacks, and increase performance, peers for building client tunnels are chosen randomly from the smallest group, which is the "fast" group. There is no bias toward selecting peers that were previously participants in a tunnel for the same client. {%- endtrans %}
{% trans -%} Exploratory tunnels are used for router administrative purposes, such as network database traffic and testing client tunnels. Exploratory tunnels are also used to contact previously unconnected routers, which is why they are called "exploratory". These tunnels are usually low-bandwidth. {%- endtrans %}
{% trans -%} Peers for building exploratory tunnels are generally chosen randomly from the standard group. If the success rate of these build attempts is low compared to the client tunnel build success rate, the router will select a weighted average of peers randomly from the high capacity group instead. This helps maintain a satisfactory build success rate even when network performance is poor. There is no bias toward selecting peers that were previously participants in an exploratory tunnel. {%- endtrans %}
{% trans -%} As the standard group includes a very large subset of all peers the router knows about, exploratory tunnels are essentially built through a random selection of all peers, until the build success rate becomes too low. {%- endtrans %}
{% trans -%} To prevent some simple attacks, and for performance, there are the following restrictions: {%- endtrans %}
{% trans pdf='http://forensics.umass.edu/pubs/wright-tissec.pdf', pdf2008='http://forensics.umass.edu/pubs/wright.tissec.2008.pdf', tunnelimpl=site_url('docs/tunnels/implementation') -%} Peers are ordered within tunnels to to deal with the predecessor attack (2008 update). More information is on the tunnel page. {%- endtrans %}
{% trans pdf=url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') -%} For those reading the paper Peer Profiling and Selection in the I2P Anonymous Network, please keep in mind the following minor changes in I2P since the paper's publication: {%- endtrans %}