Changes between Version 15 and Version 16 of petconpaper


Ignore:
Timestamp:
Mar 1, 2009 12:53:14 AM (10 years ago)
Author:
anonymous
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • petconpaper

    v15 v16  
    66PET-CON 2009.1
    77<br>
    8 DRAFT 2009-02-26 20:00 UTC
     8DRAFT 2009-03-01 01:00 UTC
    99<br>
    1010zzz@i2pmail.org
     
    3939<p>
    4040I2P itself is a overlay network based on unidirectional tunnels routed between
    41 the I2P nodes. The used garlic routing is similar to the onion routing used by
     41the I2P nodes. The routing method used - "garlic routing" - is similar to the onion routing used by
    4242TOR (ref), transmitting data from peer to peer until the endpoint of tunnel is
    43 reached. In contrast to TOR we use only hidden services in I2P with addition
     43reached. In contrast to Tor, we use only hidden services in I2P with addition
    4444of a few outproxies operated by private individuals.
    4545<p>
    4646The ancestor of the I2P project was IIP (ref) - a specialiced IRC server with clients
    47 transmitting their data via a mix network between themself. I2P was first started
    48 as a specialized low latency transport protocol for The Freenet Project but soon
     47transmitting their data via a mix network. I2P was first started
     48as a specialized, low-latency transport protocol for The Freenet Project but soon
    4949grew into a independent software project, driven by the author jrandom from
    50 2003 on until end of 2007. Other people joined coding and vanished in time between.
    51 After jrandom vanished the project end of 2007, zzz and complication took over
     502003 until end of 2007. Several other people contributed as well.
     51After jrandom left  the project at the end of 2007, zzz and complication took over
    5252active programming. The codebase itself is public domain or licensed under GPL
    5353with exception, MIT or other free licenses (ref). Most code is written in JAVA to
    5454support the three main operating systems, Windows, Linux and MacOS X.
    55 To maintain faster 1024bit pub-key encryption, some external libs as the GMP (GNU MP
     55To maintain faster 1024-bit public-key encryption, some external libraries as the GMP (GNU MP
    5656Bignum Library) are interweaved within the java code.
    5757The codebase is under active development with 7 releases in the year 2008 and
    5858more than 100 development builds between those public releases.
    5959Beside the core router itself some bundled software (e.g. a bittorrent client
    60 based on snark, I2Psnark) is maintained by zzz and complication.
     60based on snark, I2Psnark) is maintained by zzz, complication, and others.
    6161
    6262<p>
    6363In time writing this paper 830 peers are active in the I2P net (pic). This
    6464varies over time, as 50-100 new nodes (pic) joining the network every day and others
    65 vanish. Usual on weekend times the peak of 1000 active nodes are reached and
    66 in weekdays night the lower peak at 700 active routers happens. This shows a
    67 quite stable base net on which the ~550 active destinations (pic) can act on.
     65vanish. Usually on weekend times the peak of 1000 active nodes are reached and
     66in weekdays night the lower peak at 700 active routers generally occurs. This shows a
     67quite stable base network on which the ~550 active destinations (pic) route traffic.
    6868I2P is oriented towards hidden services, all destinations inside the network
    69 are upon those active peers. Only one http outproxy (exit node in TOR terms) is
    70 public known running beside a IRC gateway for I2P development discussion.
    71 In contrast to TOR, I2P is peer to peer traffic friendly while it distributes the
     69are upon those active peers. Only one HTTP outproxy (exit node in Tor terms) is
     70publicly known to be running, in addition to an IRC gateway for I2P development discussion.
     71In contrast to Tor, I2P is peer to peer traffic friendly while it distributes the
    7272encrypted traffic between all participating nodes.
    7373The current bandwith used by all peers is roughly 11 MByte/sec with peaks at 16
    74 MByte/sec (pic) and the peers builds ~40.000 tunnels (pic) producing this load.
     74MByte/sec (pic) and the peers builds ~40,000 tunnels (pic) producing this load.
    7575In the last 6 month the net grew from 400 up to 800 peers (pic), from 5 to 10 MByte/sec
    76 and from ~20.000 to ~40.000 tunnls, which shows the vital stats of the net
    77 doubled in half a year. The forthcoming time shows ongoing stable growth.
     76and from ~20,000 to ~40,000 tunnels, which shows the vital stats of the net
     77doubled in half a year. We predict continued stable growth for the network.
    7878<p>
    7979
     
    8888<li>- exploratory tunnels
    8989<p>
    90 The client tunnels transports all user generated data like IRC, webpages, code,
     90The client tunnels transports all user-generated data using protocols such as HTTP, IRC,
    9191peer to peer data or any other client transmitting data throught I2P. These
    92 tunnels are usual high bandwith and can reach up to 200 kbyte/sec.
     92tunnels can be high bandwidth and can reach up to 200 kbyte/sec.
    9393<p>
    9494Exploratory tunnels are low bandwith tunnels used for managing the network.
     
    101101monotone server, IRC server or audio streaming servers, and the clients have
    102102a destination as a return address, e.g. IRC clients, bittorrent clients, monotone
    103 clients or else. Servers got stable destinations while clients destination are
     103clients or else. Servers have stable destinations while clients destination are
    104104created new on every start.
    105105<p>
     
    112112<p>
    113113To provide anonymity of the destinations, the route from a client to server
    114 is devided into two tunnels: the outgoing tunnel, controlled by the client, and
     114is divided into two tunnels: the outgoing tunnel, controlled by the client, and
    115115the incoming tunnel, controlled by the server.
    116116The connection between these two tunnels is direct, the endpoint of the outgoing
     
    123123In this tunnel building process the strict ordering within a tunnel is obeyed,
    124124two or more I2P peers within the same subnet (/24,/16) cannot be used within the
    125 same tunnel, which prevents the predecessor attack.
     125same tunnel, which restricts the predecessor attack.
    126126<p>
    127127To secure the tunnels  and the route from client to server further more, each
    128128tunnel in I2P has a fixed lifetime of 10 minutes and will be discarded after
    129129this time. A new tunnel will be created before the existing one will timeout.
    130 Until the old tunnel times out, data will be sent on all existant tunnels (
     130Until the old tunnel times out, data will be sent on all existent tunnels (
    131131associated to the specific destination).
    132132<p>
     
    199199
    200200 
    201 <ul>
    202         <li> Use only my own traffic for these measurements, not routed traffic
    203           (we don't know if the peer before or after us in a tunnel is a true participant
    204            or the originator or destination, so that data wouldn't be valid)
    205         <li> The two metrics above are relative, not absolute, as they depend on traffic;
    206         <li> Each tier contains 8 minimum, peers are 'promoted' if the tier is too small
     201     
     202       
     203        <p> The Fast tier contains 8 peers minimum, peers are 'promoted' if the tier is too small. This provides a good collection of peers for tunnels.
    207204          (pic: sample table from profiles.jsp)
    208205
    209 </ul>
     206
    210207<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>
    211208
     
    246243
    247244</tr><tr><td><code>&nbsp;&nbsp;&nbsp;08vuC5</code></td><td>Not Failing<td align="right">0.00</td><td align="right">1.00</td><td align="right">0.00</td><td> Unreachable&nbsp</td><td nowrap><a href="netdb.jsp?r=08vuC5">netDb</a>/<a href="dumpprofile.jsp?peer=08vuC5">profile</a>/<a href="configpeer.jsp?peer=08vuC58rF~fvzujdY9kxmadgQ4EZVphfmhyk-5xaiWI=">+-</a></td>
    248 </tr><tr><td><code><font color="blue">++ 0rmD6z</font></code></td><td>Not Failing (NR 0.6.5)<td align="right">5,057.75</td><td align="right">0.00</td><td align="right">0.00</td><td> 3/6 Test Fails&nbsp</td><td nowrap><a href="netdb.jsp?r=0rmD6z">netDb</a>/<a href="dumpprofile.jsp?peer=0rmD6z">profile</a>/<a href="configpeer.jsp?peer=0rmD6ziyBbdTrMOS75sqLy57GqpYb7CUVcCBZ7tik9Q=">+-</a></td>
    249 
    250 </tr><tr><td><code>&nbsp;&nbsp;&nbsp;0uOOg6</code></td><td>Not Failing (LR 0.6.5)<td align="right">23.98</td><td align="right">5.00</td><td align="right">0.00</td><td>&nbsp</td><td nowrap><a href="netdb.jsp?r=0uOOg6">netDb</a>/<a href="dumpprofile.jsp?peer=0uOOg6">profile</a>/<a href="configpeer.jsp?peer=0uOOg6muG6SQ0tl~WmhTQ1~D~jM7ByDvsnfiTcP-yp8=">+-</a></td>
    251 </tr><tr><td><code>&nbsp;&nbsp;&nbsp;0xl1nh</code></td><td>Not Failing (NR 0.6.5)<td align="right">0.00</td><td align="right">5.00</td><td align="right">0.00</td><td>&nbsp</td><td nowrap><a href="netdb.jsp?r=0xl1nh">netDb</a>/<a href="dumpprofile.jsp?peer=0xl1nh">profile</a>/<a href="configpeer.jsp?peer=0xl1nhi2rOPmYhvxfUTl6lw1xBFSWkEiuc1j2d7Y6w4=">+-</a></td>
    252 
    253 </tr><tr><td><code>&nbsp;&nbsp;&nbsp;12oGTF</code></td><td>Not Failing (LR 0.6.5)<td align="right">0.00</td><td align="right">5.00</td><td align="right">0.00</td><td>&nbsp</td><td nowrap><a href="netdb.jsp?r=12oGTF">netDb</a>/<a href="dumpprofile.jsp?peer=12oGTF">profile</a>/<a href="configpeer.jsp?peer=12oGTFVsnGEqV5SgL4EB0jtVSXhH-YgAgAjHNVgp-2k=">+-</a></td>
    254 </tr><tr><td><code>&nbsp;&nbsp;&nbsp;135LOS</code></td><td>Not Failing (LR 0.6.5)<td align="right">154.58</td><td align="right">5.60</td><td align="right">0.00</td><td>&nbsp</td><td nowrap><a href="netdb.jsp?r=135LOS">netDb</a>/<a href="dumpprofile.jsp?peer=135LOS">profile</a>/<a href="configpeer.jsp?peer=135LOSgnGPmHs08Wun2r~isax8MKGnPLk2MGCsZmXlk=">+-</a></td>
    255245</tr>
    256246</table>
     
    259249<h2>Rating Details            </h2><ul>
    260250
    261         <p> Speed - simple - the average (FIXME OR IS IT PEAK) amount of data per tunnel we have sent through
    262           the peer in the last minute
     251<h3>Speed</h3>       
    263252<p>
    264253The speed calculation (as implemented here) 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 past performance.
    265 
     254 Specifically, it is the average of the bandwidth of the fastest three tunnels, measured over a one-minute period, through that peer.
    266255Previous algorithms used a longer time, weighing more recent data more heavily, and extrapolating it for the future. Another previous calculation used total (rather than per-tunnel) bandwidth, but it was decided that this method overrated slow, high-capacity peers (that is, slow in bandwidth but high-capacity in number of tunnels). Even earlier methods were much more complex.
    267256
    268 The current speed calculation has remained unchanges since early 2006, and it is a topic for further study to verify its effectiveness on today's network.
    269 
    270 <p> This is similar to the 'opportunistic bandwidth measurement' proposed in tune-up for Tor (ref). However, I2P uses a per-tunnel measurement. As we use Peak (FIXME?) and not average, this works for us. Fixme
    271 
     257The current speed calculation has remained unchanged since early 2006, and it is a topic for further study to verify its effectiveness on today's network.
     258
     259  <p> Only a router's locally-generated or -received traffic for these measurements. Router or "participating" traffic is not used. As it is not known if the peer before or after the router in a tunnel is a true participant
     260           or the originator or destination,  that data would not be valid. Also, this could be gamed to get a router to rank some peer of their choosing as quite fast.  Having a remote peer influence the rankings in this way could be dangerous to anonymity.
     261
     262
     263<p> This algorithm is similar to the 'opportunistic bandwidth measurement' proposed in tune-up for Tor (ref). However, I2P uses a modified peak per-tunnel measurement.
     264
     265<h3>Capacity</h3>
    272266        <p>
    273 Crucial to the smooth operation of an I2P router is an estimate of peer tunnel capacity, defined as weighted number of successful tunnel builds through the peer in a time period. As tunnel building is expensive, it is important to rate peers based on their willingness to accept tunnels. Peers may reject or drop tunnel requests for any number of reasons. Generally the rejection or drop is caused by a bandwidth limit (from participating tunnels or locally generated traffic), a processing (CPU) limit which manifests itself as large request processing delay, or an absolute limit on participating tunnel count.
    274 
    275 <p> blahblah
     267An estimate of peer tunnel capacity, defined as the <i>number</i> of successful tunnel builds through the peer in a time period, is crucial to the smooth operation of an I2P router. As tunnel building is expensive, it is important to rate peers based on their willingness to accept tunnels. Peers may reject or drop tunnel requests for any number of reasons. Generally the rejection or drop is caused by a bandwidth limit (from participating tunnels or locally generated traffic), a processing (CPU) limit which manifests itself as large request processing delay, or an absolute limit on participating tunnel count.
     268
     269<p> The actual capacity rating, before adjustments (see below), is as follows:
    276270          Let r(t) be the successful builds per hour, over a certain time period;
    277271          R = 4*r(10m) + 3*r(30m) + 2*r(1h) + r(1d);
    278272<p>
    279 The capacity calculation (as implemented here) simply goes through the profile and estimates how many tunnels we think the peer would agree to participate in over the next hour. For this estimate it looks at how many the peer has agreed to lately, how many the peer rejected, and how many of the agreed to tunnels failed, and extrapolates the data. In addition, it includes a 'growth factor' (when the peer isn't failing or rejecting requests) so that we will keep trying to push their limits.
    280 
    281 The tunnel-failure part of the calculation was disabled for a long period, but it was reinstated for release 0.6.2, as it became apparent that recognizing and avoiding unreliable and unreachable peers is critically important. Unfortunately, as the tunnel tests require the participation of several peers, it is difficult to positively identify the cause of a failure. The recent changes assign a probability of failure to each of the peers, and uses that probability in the capacity calculation. These recent changes may require additional adjustment, and are a topic for further study to verify their effectiveness on today's network.
    282 
    283         <p> Growth factor adds a little bit each time, so that new peers are tried.
    284 
     273The capacity calculation  simply estimates how many tunnels the peer would agree to participate in over the next hour. For this estimate it looks at how many the peer has agreed to lately, how many the peer rejected, and how many of the agreed to tunnels failed, and extrapolates the data.
     274
     275        <p> In addition, it includes a 'growth factor' (when the peer isn't failing or rejecting requests) so that we will keep trying to push their limits. Growth factor adds a little bit each time, so that new peers are tried.
     276
     277<h3>Other Factors</h3>
    285278<p> For both metrics, "Bonuses" can be used to manually adjust preferences for individual peers.
    286279     
     
    288281         Nor does it used several other statistics available in the profile, including latency.
    289282       
    290 
     283 <li> The two metrics above are relative to the router's demand, not absolute, as they depend on traffic.
    291284
    292285<h2>Capacity: Crime, Blame, and Punishment </h2>
     
    298291                <li> A peer that accepts a request but later drops data through the tunnel is the worst
    299292        </ul>
     293
     294<p>
     295The tunnel-failure part of the calculation was disabled for a long period, but it was reinstated for release 0.6.2, as it became apparent that recognizing and avoiding unreliable and unreachable peers is critically important. Unfortunately, as the tunnel tests require the participation of several peers, it is difficult to positively identify the cause of a failure. The recent changes assign a probability of failure to each of the peers, and uses that probability in the capacity calculation. These recent changes may require additional adjustment, and are a topic for further study to verify their effectiveness on today's network.
     296
    300297
    301298
     
    410407<li><i>TOR http://www.torproject.org/</i>
    411408<li><i>IIP http://invisibleip.sourceforge.net/iip/ and http://en.wikipedia.org/wiki/Invisible_IRC_Project</i>
    412 <li><i>Licences http://www.i2p2.de/licenses.html</i>
     409<li><i>Licenses http://www.i2p2.de/licenses.html</i>
    413410<li><i>Pics should be taken from stats.i2p<i>
    414411