tweaks

www.i2p2/pages/common_structures_spec.html

@@ -4,7 +4,11 @@
 Updated August 2010, current as of router version 0.8
 <h1>Data types Specification</h1>
 <p>
-  This document describes some data types common to all I2P protocols, like I2NP, I2CP, NTCP, etc.
+  This document describes some data types common to all I2P protocols, like
+  <a href="i2np.html">I2NP</a>,
+  <a href="i2cp.html">I2CP</a>,
+  <a href="udp.html">SSU</a>,
+  etc.
 </p>
 
 <h2 id="type_Integer">Integer</h2>
@@ -380,7 +384,7 @@ Total length: 387+ bytes
 | end_date                              |
 +----+----+----+----+----+----+----+----+
 
-tunnel_gw :: RouterIdentity
+tunnel_gw :: RouterIdentity of the tunnel gateway
              length -> >= 387 bytes
 
 tunnel_id :: TunnelId
@@ -391,6 +395,13 @@ end_date :: Date
 {% endfilter %}
 </pre>
 
+<h4>Notes</h4>
+<ul>
+<li>
+Could this be optimized to include the Hash of the Router Identity instead of the full Router Identtity?
+</li></ul>
+
+
 <h4><a href="http://docs.i2p2.de/core/net/i2p/data/Lease.html">Javadoc</a></h4>
 
 <h2 id="struct_LeaseSet">LeaseSet</h2>
@@ -543,6 +554,15 @@ options :: Mapping
 {% endfilter %}
 </pre>
 
+<h4>Notes</h4>
+<ul>
+<li>
+Cost is typically 5 or 6 for SSU, and 10 or 11 for NTCP.
+</li><li>
+Expiration is currently unused, always null (all zeroes))
+</li></ul>
+
+
 <h4><a href="http://docs.i2p2.de/core/net/i2p/data/RouterAddress.html">Javadoc</a></h4>
 
 <h2 id="struct_RouterInfo">RouterInfo</h2>
@@ -640,4 +660,8 @@ The signature may be verified using the signing public key of the router_ident.
 
 <h4><a href="http://docs.i2p2.de/core/net/i2p/data/RouterInfo.html">Javadoc</a></h4>
 
+
+<h2 id="struct_DeliveryInstructions">Delivery Instructions</h2>
+Defined in the <a href="tunnel_message_spec.html#delivery">Tunnel Message Specification</a>.
+
 {% endblock %}

www.i2p2/pages/how_cryptography.html

@@ -277,6 +277,9 @@ Both transports use 256 byte (2048 bit) Diffie-Hellman key exchange
 using
 <a href="#elgamal">the same shared prime and generator as specified above for ElGamal</a>,
 followed by symmetric AES encryption as described above.
+This provides
+<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">perfect forward secrecy</a>
+on the transport links.
 </p>
 
 <H3><a name="tcp">NTCP connections</a></H3>

www.i2p2/pages/how_garlicrouting.html

@@ -107,8 +107,8 @@ exploiting transport latency/throughput tradeoffs, and branching data through re
 
 <h3>Tunnel Building and Routing</h3>
 <p>
-In I2P, tunnels are unidirectional, and we require two tunnels
+In I2P, tunnels are unidirectional. Each party builds two tunnels,
-(one outbound and one inbound) for end-to-end communication in each direction.
+one for outbound and one for inbound traffic.
 Therefore, four tunnels are required for a single round-trip message and reply.
 </p><p>
 Tunnels are built, and then used, with layered encryption.

www.i2p2/pages/i2np_spec.html

@@ -298,6 +298,10 @@ Certificate :: Always NULL in the current implementation (3 bytes total, all zer
 </ul>
 
 
+<h3 id="struct_DeliveryInstructions">Delivery Instructions</h3>
+Defined in the <a href="tunnel_message_spec.html#delivery">Tunnel Message Specification</a>.
+
+
 <h2 id="messages">Messages</h2>
 <table border=1>
   <tr>

www.i2p2/pages/ntcp.html

@@ -424,6 +424,9 @@ to create a limited number of message sizes.
 </li><li>
 Memory utilization (including that of the kernel) for NTCP should be compared to that for SSU.
 </li><li>
+Can the establishment messages be randomly padded somehow, to frustrate
+identification of I2P traffic based on initial packet sizes?
+</li><li>
 Review and possibly disable 'check connection'
 </li></ul>
 </p>

www.i2p2/pages/performance.html

@@ -101,17 +101,11 @@ bandwidth, latency, and CPU usage.</p>
 
 <h2>Full streaming protocol improvements</h2>
 <ul>
-<li>Some algorithms to share congestion and RTT information across streams 
+<li>Perhaps re-enable the interactive stream profile (the 
-    (per target destination? per source destination? for all of the local destinations?).</li>
+    current implementation only uses the bulk stream profile).</li>
-<li>Further optimizations for interactive streams (most of the focus in the 
-    current implementation is on bulk streams).</li>
-<li>More explicit use of the new streaming lib's features in I2PTunnel and 
-    the SAM bridge, reducing the per-tunnel overhead.</li>
 <li>Client level bandwidth limiting (in either or both directions on a stream, 
     or possibly shared across multiple streams). This would be in addition to 
     the router's overall bandwidth limiting, of course.</li>
-<li>Various controls for destinations to throttle how many streams they accept 
-    or create (we have some basic code, but largely disabled)<./li>
 <li>Access control lists (only allowing streams to or from certain other known 
     destinations).</li>
 <li>Web controls and monitoring the health of the various streams, as well