Changes between Version 21 and Version 22 of petconpaper


Ignore:
Timestamp:
Mar 4, 2009 2:57:46 PM (10 years ago)
Author:
anonymous
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • petconpaper

    v21 v22  
    66PET-CON 2009.1
    77<br>
    8 DRAFT 2009-03-02 17:10 GMT
     8DRAFT 2009-03-04 15:00 GMT
    99<br>
    1010zzz@i2pmail.org
     
    1414<p><b>Abstract</b>
    1515<p>
    16 The I2P anonymous communication network uses a system of peer profiling for selecting a subset of peers for tunnel building. This system maintains anonymity while optimizing bandwidth. The system uses opportunistic measurement of both per-tunnel bandwidth and the number of tunnels accepted. The profiling and selection system has been used in I2P since early 2004, and while it continues to be adjusted, the fundamentals and effectiveness of the system have been demonstrated.
     16The I2P anonymous communication network uses a system of peer profiling for selecting a subset of peers for tunnel building. This system maintains anonymity while optimizing bandwidth. The system uses opportunistic measurement of both per-tunnel bandwidth and the number of tunnels accepted. The profiling and selection system has been used in I2P since early 2004, and while it continues to be adjusted, the fundamentals and effectiveness of the system have been conclusively demonstrated.
    1717<p>
    1818Here we document the algorithms used in I2P's peer profiling and selection, discuss the strengths and weaknesses of the system, and describe opportunities for future work. We write this paper in the hope that it will be useful for guiding improvements in I2P and other anonymous networks with similar features.
     
    2020<p>
    2121
    22 <b>NOTE TO ECHELON: I did some editing/cleanup in your sections too.</b>
    23 
    2422<h2>I2P Overview</h2>
    2523
    2624<p>
    27 I2P itself is a overlay network based on unidirectional tunnels routed between
     25I2P is a overlay network based on unidirectional tunnels routed between
    2826the I2P nodes. The routing method used - "garlic routing" - is similar to the onion routing used by
    29 TOR (ref), transmitting data from peer to peer until the endpoint of tunnel is
    30 reached. In contrast to Tor, we use only hidden services in I2P with addition
     27Tor [Tor], transmitting data from peer to peer until the endpoint of tunnel is
     28reached. In contrast to Tor, I2P provides primarily hidden services, with the addition
    3129of a few outproxies operated by private individuals.
    3230<p>
    33 The ancestor of the I2P project was IIP (ref) - a specialiced IRC server with clients
     31The ancestor of the I2P project was IIP [IIP] - a specialiced IRC server with clients
    3432transmitting their data via a mix network. I2P was first started
    3533as a specialized, low-latency transport protocol for The Freenet Project but soon
     
    3836After jrandom left  the project at the end of 2007, zzz and complication took over
    3937active programming. The codebase itself is public domain or licensed under GPL
    40 with exception, MIT or other free licenses (ref). Most code is written in JAVA to
    41 support the three main operating systems, Windows, Linux and MacOS X.
     38with exception, MIT or other free licenses [I2P]. Most code is written in JAVA and is therefore supported cross-platform.
    4239To maintain faster 1024-bit public-key encryption, some external libraries as the GMP (GNU MP
    4340Bignum Library) are interweaved within the java code.
     
    4542more than 100 development builds between those public releases.
    4643Beside the core router itself some bundled software (e.g. a bittorrent client
    47 based on snark, I2Psnark) is maintained by zzz, complication, and others.
    48 
    49 <p>
    50 In time writing this paper 830 peers are active in the I2P net (pic). This
     44based on snark, "I2Psnark") is maintained by zzz, complication, and others.
     45
     46<p>
     47At the time of writing this paper approximately 830 peers are active in the I2P net (pic). This
    5148varies over time, as 50-100 new nodes (pic) joining the network every day and others
    52 vanish. Usually on weekend times the peak of 1000 active nodes are reached and
     49leaving. Usually on weekend times the peak of 1000 active nodes are reached and
    5350in weekdays night the lower peak at 700 active routers generally occurs. This shows a
    5451quite stable base network on which the ~550 active destinations (pic) route traffic.
    5552I2P is oriented towards hidden services, all destinations inside the network
    56 are upon those active peers. Only one HTTP outproxy (exit node in Tor terms) is
     53are hosted upon those active peers. Only one HTTP outproxy (exit node in Tor terms) is
    5754publicly known to be running, in addition to an IRC gateway for I2P development discussion.
    5855In contrast to Tor, I2P is peer to peer traffic friendly while it distributes the
     
    7572<li>- exploratory tunnels
    7673<p>
    77 The client tunnels transports all user-generated data using protocols such as HTTP, IRC,
     74The client tunnels transport all user-generated data using protocols such as HTTP, IRC,
    7875peer to peer data or any other client transmitting data throught I2P. These
    7976tunnels can be high bandwidth and can reach up to 200 kbyte/sec.
     
    8986a destination as a return address, e.g. IRC clients, bittorrent clients, monotone
    9087clients or else. Servers have stable destinations while clients destination are
    91 created new on every start.
    92 <p>
    93 Each destination have a associated set of tunnels to transport the data. The
    94 application and/or user can control the specs of the tunnels:
     88created anew on every start.
     89<p>
     90Each destination has an associated set of tunnels to transport the data. The
     91application and/or user can control the specifications of the tunnels:
    9592<li>- distance: 0-2 peers in between
    9693<li>- variance: a variance of 0-2 peers added/subtracted on random base
    9794<li>- quantity: up to three tunnels can be setup and data is distributed on them
    98 <li>- backup: built 1-2 backup tunnels in case of original tunnels die unexpected 
     95<li>- backup: built 1-2 backup tunnels in case of original tunnels die unexpectedly
    9996<p>
    10097To provide anonymity of the destinations, the route from a client to server
    10198is divided into two tunnels: the outgoing tunnel, controlled by the client, and
    10299the incoming tunnel, controlled by the server.
    103 The connection between these two tunnels is direct, the endpoint of the outgoing
    104 tunnel connects direct to the inpoint of the incoming tunnel.
     100The connection between these two tunnels is direct, the endpoint (outbound gateway) of the outgoing
     101tunnel connects direct to the inpoint (inbound gateway) of the incoming tunnel.
    105102This setup allows every participant to control its security and anonymity level
    106103for himself by setting the distance and variance for his tunnels.
     
    114111To secure the tunnels  and the route from client to server further more, each
    115112tunnel in I2P has a fixed lifetime of 10 minutes and will be discarded after
    116 this time. A new tunnel will be created before the existing one will timeout.
     113this time. A new tunnel will be created before the existing one will time out.
    117114Data will be sent on one or more of the tunnels
    118115associated with the specific destination.
     
    144141statistical bandwith data are included. All of the these data are not trusted by
    145142the peer except for the K classification of bandwith.
    146 Each peer is set by default to 32kbit input and 32 kbit output bandwith with
     143Each peer is set by default to 48KByte input and 24KByte output bandwith with
    14714490% share percantage (90% of maximum bandwith is allowed to be used up by
    148145participating tunnels). These peers will fit into the L class of bandwith.
     
    156153But if we trust these (user set) classification, serious anonymity issues and
    157154DOS implications (like the "low-ressource attacks") will rise up.
    158 This led to the following implementation of peer profiling.
     155This leads to the following implementation of peer profiling.
    159156 
    160157
     
    165162<p>Peer profiling was proposed for the I2P network in December 2003 by jrandom [Jr03]. It was introduced in the 0.3 release in March 2004 [Jr04].
    166163<p>
    167 Peer 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.
    168 <p>
    169 The profiling system includes mechanisms similar to the "opportunistic bandwidth measurement algorithm" proposed for Tor [SB08], and much more.
    170 <p>
    171 The profile contains several statistics, continuously updated. For each statistic, averages, event counts, and maximums for 1 minute, 10 minute, 1 hour, and 24 hour periods are available. The profiles are also stored locally on disk, so that they are persistent across restarts. Also, the profile stores several timestamps, such as the last time a peer was heard from, the last time it accepted a tunnel request, and many more.
     164Peer 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. The profiling system includes mechanisms similar to the "opportunistic bandwidth measurement algorithm" proposed for Tor [SB08], and much more.
     165<p>
     166The profile contains several statistics, continuously updated. For each statistic, averages, event counts, and maximums for several periods (for example 1 minute, 10 minute, 1 hour, and 24 hour). Example statistics are: 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. The profiles are also stored locally on disk, so that they are persistent across restarts and router need not start over collecting data. Also, the profile stores several timestamps, such as the last time a peer was heard from, the last time it accepted a tunnel request, when the last communication error occurred, and others.
    172167<p>
    173 
    174 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.
    175 
    176 <p>
    177 Much, 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.
    178 
    179 <p> The profile data is periodically coalesced and sorted into tiers of peers that are used for various functions, as described further below. Profile data are stored on disk at shutdown and reloaded into the router upon restart so that a router need not start over collecting data. The picture below shows a page from the I2P router console, with a portion of the profiles sorted into tiers.
     168Much of the profile data is 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.
     169
     170<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.
    180171
    181172 
     
    236227<h3>Speed</h3>       
    237228<p>
    238 The 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.
     229The speed calculation (as implemented here) simply goes through the profile and estimates how much data can be sent or received on a single tunnel through the peer in a minute. For this estimate it just looks at past performance.
    239230 Specifically, it is the average of the bandwidth of the fastest three tunnels, measured over a one-minute period, through that peer.
    240231Previous 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.
     
    242233The 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.
    243234
    244   <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
    245            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.
     235  <p> Only a router's locally-generated or -received traffic is used for these measurements - transit 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 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.
    246236
    247237
     
    256246          R = 4*r(10m) + 3*r(30m) + 2*r(1h) + r(1d);
    257247<p>
    258 The 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.
     248The 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.
    259249
    260250        <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.
     
    269259
    270260<h2>Capacity: Crime, Blame, and Punishment </h2>
    271 <p> Raw build capacity isn't sufficient - we have to decrement for bad behavior, because
    272           tunnel build attempts are expensive. A tunnel build request is about 4KB, and the reply is identically-sized. Generation of the build request also consumes significant CPU and entropy to create the cryptographic keys. As an example of the factors that we must consider:
     261<p> Raw tunnel build capacity isn't sufficient - it is essential to decrement for bad behavior, because tunnel build attempts are expensive. A tunnel build request is about 4KB, and the reply is identically-sized. Generation of the build request also consumes significant CPU and entropy to create the cryptographic keys. As an example of the factors that we must consider:
    273262        <ul>
    274263                <li> A peer that accepts 10/10 tunnels is better than one that accepts 10/100.
     
    283272
    284273        <p> Therefore, the capacity is adjusted as a form of "punishment": Capacity is decremented for build request rejections, build request timeouts,
    285           and tunnel test failures.
    286 
    287         <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?
     274          and tunnel test failures. Unfortunately, a router does not 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?
    288275        <ul>
    289276                <li> Naive solution: Don't bother blaming anybody. This doesn't work well at all!
    290277                <li> Much better solution: Blame everybody, with a weighted value. The bad peers will be discovered over time because they will be consistently bad. The metric for good peers will still be pretty good.
    291278        </ul>
    292         <p> Example 1: Tunnel build request expired (4 outbound hops A-B-C-D), reply was due back through
    293           our inbound exploratory tunnel (2 hops E-F).
    294           Blame A, B, C, and D with weight 1/8, blame E-F with weight 1/4.
    295           Alternately: It was probably E's fault, because that's the usual failure point in I2P
    296           (the gateway of the inbound tunnel can't be reached), so blame E with weight 3/8 and
    297           E with weight 1/8. (no change to the outbound blame).
    298           (pic needed here)
    299 
    300 <h2>Tiers and sorting </h2>
    301 
    302        <p> Every 30 seconds, all the profiles are sorted into three tiers:
    303         <ul>
    304                 <li> Not Failing Tier: peers is pretty much everybody that is responsive; typ 300-500 peers
    305                 <li> High Capacity Tier: peers are Not Failing and have above-average tunnels-built-per-hour; typ 10-30 peers
    306                 <li> Fast Tier: peers are High Capacity and have above-average bandwidth-per-tunnel; typ 8-15 peers
    307         </ul>
    308 
    309 Both 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
     279
     280        <p> As an example, assume a tunnel build request (4 outbound hops through peers A-B-C-D) has expired. The reply was due back through the  inbound exploratory tunnel (2 hops E-F). One option is to blame A, B, C, and D with weight 1/8, blame E-F with weight 1/4. Alternately: It was probably E's fault, because that's the usual failure point in I2P (the gateway of the inbound tunnel can't be reached), so blame E with weight 3/8 and E with weight 1/8. (no change to the outbound blame).  (pic needed here)
     281
     282<h2>Tiers and Sorting </h2>
     283
     284 To review, exploratory tunnels are generally low-bandwidth, and are used for router operation, including building and testing other tunnels. 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.
     285
     286
     287      <p> Every 30 seconds, all the profiles are sorted into three tiers:
     288   
     289<ul>
     290<li> The Not Failing tier is everybody, including the following two tiers. Typical size is 300-500 peers.
     291
     292
     293<li>The High-Capacity tier includes peers with above-average rating for accepting tunnel build requests, and the following tier. Typical size is 10-30 peers.
     294
     295<li>The Fast tier includes peers from the High-Capacity tier whose speed rating (i.e.  peak bandwidth per tunnel) is above-average for all peers in the Not Failing tier. Typical size is 8-15 peers.
     296
     297</ul>
     298
     299<p>
     300Both 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.
    310301
    311302
    312303
    313304<h2>Peer Selection                 </h2>
    314 <p>
    315 
    316 To review, exploratory tunnels are generally low-bandwidth, and are used for router operation, including building and testing other tunnels.
    317 
    318 <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.
    319 <ul>
    320 <li> The Not Failing tier is everybody, including the following two tiers.
    321 
    322 <li>The High-Capacity tier includes peers with above-average rating for accepting tunnel build requests, and the following tier.
    323 
    324 <li>The Fast tier includes peers from the High-Capacity tier whose speed rating (i.e.  peak bandwidth per tunnel) is above-average for all peers in the Not Failing tier.
    325 </ul>
    326305
    327306<p>Candidate peers for tunnel builds are selected as follows. Client tunnels are built from peers in the Fast tier. Exploratory tunnels are built from peers either in the Not Failing tier or the High Capacity tier. The tier selected is chosen on a per-build basis, using a weighted random function. This function uses data on the exploratory tunnel build success vs. the client tunnel build success to adjust the weighting.
     
    329308Therefore the selection maintains the balance between tunnel build requests and the need to explore peers.
    330309
    331 It may seem curious to use the Not Failing tier (generally the lowest-bandwidth, lowest-capacity peers) for exploratory tunnels, since these tunnels are required to function for a router to build client tunnels. However failing exploratory tunnels are recognized quickly and so in practice this well.
    332  And the benefit, of course, is opportunistic bandwidth and capacity measurement.
     310<p>
     311It may seem curious to use the Not Failing tier (generally the lowest-bandwidth, lowest-capacity peers) for exploratory tunnels, since these tunnels are required to function for a router to build client tunnels. However failing exploratory tunnels are recognized quickly and so in practice this well. And the benefit, of course, is opportunistic bandwidth and capacity measurement.
    333312
    334313        <p> Peers are selected with Equal weight within each tier. If sufficient peers for a tunnel are not found within a given tier, the peer selection moves on to the next-lower tier.
     
    337316<h2>How It Works, Lessons for Other Implementations   </h2>
    338317
    339         <p> Great! Core system has been in place since the beginning of I2P.
    340              Pretty much includes everything proposed in "Tuneup for Tor" and much more.
    341 First and foremost, it doesn't use claimed bandwidth, which prevents low-resource attacks. It also works well enough that peer selection is not a big obstacle to I2P network performance. There are a lot of other issues that we are working on. The basic method has been in place for five years, and has been tuned only modestly in the last two years. Other characteristics:
    342 
    343         <p> Stability - The Fast and High Capacity tier members don't change rapidly. This is because when a router uses  a peer for tunnels, it tends to increase that peer's speed and capacity metrics. This keeps it in the pool.
    344           This is a desirable quality for anonymity, as using a large pool for tunnel building tends to assist predecessor attacks (ref).
     318        <p> The profiling and peer selection system works quite well in I2P. The core system has been in place since the beginning of I2P. The system includes almost everything proposed in [SB08] except for "tunability".
     319Most importantly, I2P does not use claimed bandwidth, which prevents low-resource attacks. It also works well enough that peer selection is not a big obstacle to I2P network performance. There are a lot of other issues that we are working on. The basic method has been in place for five years, and has been tuned only modestly in the last two years.
     320
     321        <p> The algorithm is stable, i.e., the Fast and High Capacity tier members don't change rapidly. This is because when a router uses  a peer for tunnels, it tends to increase that peer's speed and capacity metrics. This keeps it in the pool. This is a desirable quality for anonymity, as using a large pool for tunnel building tends to assist predecessor attacks (ref).
    345322
    346323        <p> The tier system is fast-reacting to individual peer failure or overload, and to increased local demand for bandwidth. The speed and capacity metrics are highly weighted for recent performance. When a peer starts to drop test messages, or fails to respond to tunnel build requests, it will quickly be demoted out of the high-capacity pool. As bandwidth demand increases, the speed metric for individual peers will rapidly increase, and the fast tier will quickly become reorganized to include the newly-recognized fast peers.
     
    351328<p> The tier system tends to use the highest-bandwidth peers when the network is not congested. As congestion increases, the total network  traffic "spreads out" to lower-capacity peers. From an overall network perspective, this is optimal as it maintains a similar level of service for all routers.
    352329
    353 <p> The profiling system does not over-optimize. The router uses its own, normally-generated traffic for peer profiling. No high-bandwidth test messages are required or used. When a router does not require high bandwidth or a high number of tunnels, the metrics for each peer are correspondingly lower. Therefore, even a low-bandwidth peer may be classified as "fast" and used for tunnels. This tends to, at least partially, spread low-bandwidth tunnels broadly across the network, and leaves the high-capacity peers for high-speed traffic. However, even very-low-bandwidth routers tend to accurately find a few fast peers and thus are  well-prepared when higher bw is demanded. Also, there is no need for a complete global optimum. I2P routers generally know only a subset of the active peers in the network, usually 20% to 80%. Through exploratory tunnel building and other peer discovery mechanisms, routers have no difficulty finding a sufficient portion of peers, and preventing network partitioning. As the I2P network grows the percentage of peers known to each router will decline as we implement additional mechanisms to limit memory usage, TCP and UDP connections, and other resources in the router. This poses no threat to the profiling system.
     330<p> The profiling system does not over-optimize. The router uses its own, normally-generated traffic for peer profiling. No high-bandwidth test messages are required or used. When a router does not require high bandwidth or a high number of tunnels, the metrics for each peer are correspondingly lower. Therefore, even a low-bandwidth peer may be classified as "fast" and used for tunnels. This tends to, at least partially, spread low-bandwidth tunnels broadly across the network, and leaves the high-capacity peers for high-speed traffic. However, even very-low-bandwidth routers tend to accurately find a few fast peers and thus are  well-prepared when higher bw is demanded.
     331
     332<p>
     333Also, there is no need for a complete global optimum. I2P routers generally know only a subset of the active peers in the network, usually 20% to 80%. Through exploratory tunnel building and other peer discovery mechanisms, routers have no difficulty finding a sufficient portion of peers, and preventing network partitioning. As the I2P network grows the percentage of peers known to each router will decline as we implement additional mechanisms to limit memory usage, TCP and UDP connections, and other resources in the router. This poses no threat to the profiling system.
    354334
    355335
    356336<p> The profiling system is persistent across restarts, and maintains measurements for the last 24 hours. This allows a recently-started router to quickly re-integrate to the network, whether the router was just restarted or has been down for some time.
    357337
    358         <p> The parameters, weighting, and calculations are VERY powerful "knobs" to turn.
    359           difficult to test and debug in a distributed network;
    360           impossible to fully optimize;
    361           can take months or years to
    362           get right. The I2P router contains a framework for local network simulation and testing; however, we have not used this framework for profiling and selection testing. As described above, the routers include bandwidth and tunnel build success statistics in the network database entry they publish to the floodfill routers. While this information is not trusted or used in the router, it is gathered by the stats.i2p website (ref). On that website, several network performance graphs are presented, and the I2P developers make heavy use of this facility to monitor the network and judge the effectiveness of software changes in each release.
     338        <p> The parameters, weighting, and calculations are quite powerful "knobs" to turn. It is difficult to test and debug in a distributed network, impossible to fully optimize, and can take months or years to get right. The I2P router contains a framework for local network simulation and testing; however, we have not used this framework for profiling and selection testing. As described above, the routers include bandwidth and tunnel build success statistics in the network database entry they publish to the floodfill routers. While this information is not trusted or used in the router, it is gathered by the stats.i2p website (ref). On that website, several network performance graphs are presented, and the I2P developers make heavy use of this facility to monitor the network and judge the effectiveness of software changes in each release.
    363339
    364340
    365341<p> Here are some other lessons for those wishing to "tune up" their own network.
    366342
    367         <p> The basic measurements are much simpler than they used to be. The speed calculation, for example, was at one time over 400 lines of code, and it is now essentially a one-liner. The punishment for bad behavior is what keeps the network running well, and also is an area for further research. How heavily you punish
    368           determines how fast the load spreads out across the network as the it gets busy,
    369           and how quickly an overloaded peer gets avoided. Too The implementation contains an implicit estimate of the cost of a tunnel build request, as it rates the relative performance of a rejected requests and a dropped request. Or, alternatively, an accepted request vs. a request not made at all. Another way of looking at it is to establish a baseline of a peer that we have not made any requests of. Call that a capacity rating of zero. What percentage (or absolute number) of request rejections, dropped requests, and test failures is required to drop the capacity rating below zero?
     343        <p> The basic measurements are much simpler than they used to be. The speed calculation, for example, was at one time over 400 lines of code, and it is now essentially a one-liner. The punishment for bad behavior is what keeps the network running well, and also is an area for further research. How heavily a router punishes determines how fast the load spreads out across the network as the it gets busy, sand how quickly an overloaded peer gets avoided. Too The implementation contains an implicit estimate of the cost of a tunnel build request, as it rates the relative performance of a rejected requests and a dropped request. Or, alternatively, an accepted request vs. a request not made at all. Another way of looking at it is to establish a baseline of a peer that we have not made any requests of. Call that a capacity rating of zero. What percentage (or absolute number) of request rejections, dropped requests, and test failures is required to drop the capacity rating below zero?
    370344
    371345If peers are punished too heavily, the network will tend to congestion collapse as most peers are driven to negative capacity ratings and tunnel load spreads out quickly throughout the network, as routers attempt to route tunnels through very-low-capacity peers.
     
    379353<h2>Summary</h2>
    380354<p>
    381           I2P's exploratory tunnels average only 100KB in 10m (~150Bps).
    382           Idle  client tunnels average only 10KB in 10m from tunnel tests (~15Bps).
    383            Surprisingly, this is sufficient to find sufficiently fast, high-capacity peers.
    384           When a router requires little bandwidth, it doesn't care how accurately its peers are sorted into tiers.
    385           When the router does require more bandwidth, the tiering will be correspondingly better.
    386           Even very-low-bandwidth routers tend to accurately find fast peers and thus are
    387           well-prepared when higher bw is demanded.
     355          I2P's exploratory tunnels average only 100KB in 10m (~150Bps). Idle  client tunnels average only 10KB in 10m from tunnel tests (~15Bps). Surprisingly, this is sufficient to find sufficiently fast, high-capacity peers. When a router requires little bandwidth, it doesn't care how accurately its peers are sorted into tiers. When the router does require more bandwidth, the tiering will be correspondingly better. Even very-low-bandwidth routers tend to accurately find fast peers and thus are well-prepared when higher bw is demanded.
    388356
    389357
     
    394362
    395363<h2>References                   </h2><ul>
    396 <li>This paper includes material adapted from http://www.i2p2.de/ written by jrandom and others.
    397 <li><i>Tor http://www.torproject.org/</i>
    398 <li><i>IIP http://invisibleip.sourceforge.net/iip/ and http://en.wikipedia.org/wiki/Invisible_IRC_Project</i>
    399 <li><i>Licenses http://www.i2p2.de/licenses.html</i>
    400 <li><i>Pics should be taken from stats.i2p<i>
    401 
    402 <li><i>[SB08] A Tune-up for Tor: Improving Security and Performance in the Tor Network</i>
     364<li>[I2P]This paper includes material adapted from http://www.i2p2.de/ written by jrandom and others.
     365<li>[Tor] http://www.torproject.org/
     366<li>[IIP] http://invisibleip.sourceforge.net/iip/ and http://en.wikipedia.org/wiki/Invisible_IRC_Project
     367<li><i>Licenses http://www.i2p2.de/licenses.html
     368<li>[Stats]Pics should be taken from stats.i2p
     369
     370<li>[SB08] A Tune-up for Tor: Improving Security and Performance in the Tor Network
    403371Robin Snader and Nikita Borisov @ UIUC
    404 <li>[Jr03] I2P Development Meeting 68, December 9, 2003 http://www.i2p2.de/meeting68 (profiling described)
    405 <li>[Jr04] I2P Development Meeting 82, March 23, 2004 http://www.i2p2.de/meeting82 (profiling released in 0.3)
     372<li>[Jr03] I2P Development Meeting 68, December 9, 2003 http://www.i2p2.de/meeting68
     373<li>[Jr04] I2P Development Meeting 82, March 23, 2004 http://www.i2p2.de/meeting82
    406374
    407375<li>Predecessor attack papers
    408 <li>http://www.i2p2.de/
     376<li>[I2P]http://www.i2p2.de/
    409377</ul>
    410378