Changes between Version 6 and Version 7 of petconpaper


Ignore:
Timestamp:
Feb 26, 2009 7:59:52 PM (11 years ago)
Author:
anonymous
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • petconpaper

    v6 v7  
    66PET-CON 2009.1
    77<br>
    8 DRAFT 2009-02-26 19:00 UTC
     8DRAFT 2009-02-26 20:00 UTC
    99<br>
    1010zzz@i2pmail.org
     
    6464        <li> Stats are persistent across restarts
    6565</ul>
    66 
     66<p>Peer profiling was proposed for the I2P network in December 2003 (ref) by jrandom. It was introduced in the 0.3 release in March 2004 (ref).
    6767<p>
    6868Peer selection within I2P is simply the process of choosing which routers on the network to route locally-generated messages (and replies to those messages) to go through. In other words, which peers are used for tunnels. To accomplish this, the router maintains a database of each peer's performance, called the "profile". The router uses that data to estimate the bandwidth of a peer, how often a peer will to accept tunnel build requests, and whether a peer seems to be overloaded or otherwise unable to reliably perform.
     
    7878Much, if not most, of the profile data are unused in the current software. It remains a "reserve" defense that can be easily used to enhance the router's resistance to theoretical or actual attacks, such as denial-of-service attempts, selective packet drops, network database (floodfill) disruption, and others.
    7979
     80<p> The profile data is periodically coalesced and sorted into tiers of peers that are used for various functions, as described further below. The picture below shows a page from the I2P router console, with a portion of the profiles sorted into tiers.
     81
     82 
    8083<ul>
    81         <li> 3 Tiers:
    82         <ul>
    83                 <li> Not Failing Tier: peers is pretty much everybody that is responsive; typ 300-500 peers
    84                 <li> High Capacity Tier: peers are Not Failing and have above-average tunnels-built-per-hour; typ 10-30 peers
    85                 <li> Fast Tier: peers are High Capacity and have above-average bandwidth-per-tunnel; typ 8-15 peers
    86         </ul>
    8784        <li> Use only my own traffic for these measurements, not routed traffic
    8885          (we don't know if the peer before or after us in a tunnel is a true participant
     
    9289          (pic: sample table from profiles.jsp)
    9390
    94 
     91</ul>
    9592<table border="1"><tr><td><b>Peer</b> (385, hiding 51)</td><td><b>Groups (Caps)</b></td><td><b>Speed</b></td><td><b>Capacity</b></td><td><b>Integration</b></td><td><b>Failing?</b></td><td>&nbsp;</td></tr><tr><td><code><font color="blue">++ 16BDe7</font></code></td><td>Fast, High Capacity (OR 0.6.5)<td align="right">16,582.88</td><td align="right">37.47</td><td align="right">0.00</td><td>&nbsp</td><td nowrap><a href="netdb.jsp?r=16BDe7">netDb</a>/<a href="dumpprofile.jsp?peer=16BDe7">profile</a>/<a href="configpeer.jsp?peer=16BDe7f5rVXqyaQjx0q0Yx4NpQMvtzyZbhIJ4ZlGjSM=">+-</a></td>
    9693
     
    188185          and tunnel test failures.
    189186
    190         <p> Problem: We don't know which of the tunnel peers to blame when a request or tunnel test message is dropped. What should the router do with this incomplete information?
     187        <p> Problem: We don't know which of the tunnel peers to blame when a request or tunnel test message is dropped. This is because tunnel builds requests are handed off from peer to peer along the path, and because tunnels are unidirectional. What should the router do with this incomplete information?
    191188        <ul>
    192189                <li> Naive solution: Don't bother blaming anybody. This doesn't work well at all!
     
    201198          (pic needed here)
    202199
     200<h2>Tiers and sorting </h2>
     201
     202       <p> Every 30 seconds, all the profiles are sorted into three tiers:
     203        <ul>
     204                <li> Not Failing Tier: peers is pretty much everybody that is responsive; typ 300-500 peers
     205                <li> High Capacity Tier: peers are Not Failing and have above-average tunnels-built-per-hour; typ 10-30 peers
     206                <li> Fast Tier: peers are High Capacity and have above-average bandwidth-per-tunnel; typ 8-15 peers
     207        </ul>
     208
     209Both the speed and capacity metrics are skewed, with a small number of high ratings and a "long tail". By using the average and not the median, we select a small number of peers for the top two tiers. FIXME move this down
     210
    203211
    204212
     
    210218<p>Client tunnels are used for all user client and server traffic, including accessing internal I2P network destinations or "hidden services" such as "eepsites", connection to external gateways ("inproxies" and "outproxies") and other uses.
    211219
    212 <p> The Not Failing tier is everybody.
    213 
    214 <p>The High-Capacity tier includes peers with above-average rating for accepting tunnel build requests.
     220<p> The Not Failing tier is everybody, including the following two tiers.
     221
     222<p>The High-Capacity tier includes peers with above-average rating for accepting tunnel build requests, and the following tier.
    215223
    216224<p>The Fast tier includes peers from the High-Capacity tier with above-average rating for bandwidth-per-tunnel.
    217225
    218 <p>So here's how it works. Client tunnels are build from peers in the Fast tier.
     226<p>So here's how it works. Client tunnels are build from peers in the Fast tier. the end.
    219227
    220228
     
    284292<li><i>A Tune-up for Tor: Improving Security and Performance in the Tor Network</i>
    285293Robin Snader and Nikita Borisov @ UIUC
     294<li>I2P Development Meeting 68, December 9, 2003 http://www.i2p2.de/meeting68 (profiling described)
     295<li>I2P Development Meeting 82, March 23, 2004 http://www.i2p2.de/meeting82 (profiling released in 0.3)
     296
    286297<li>Predecessor attack papers
    287298<li>http://www.i2p2.de/