[or-cvs] r18017: {website} Actually publish the status updates for NLnet Project: Tor f (website/trunk/projects/en)

[phobos@xxxxxxxx]

Author: phobos
Date: 2009-01-08 01:00:42 -0500 (Thu, 08 Jan 2009)
New Revision: 18017

Modified:
   website/trunk/projects/en/lowbandwidth.wml
Log:
Actually publish the status updates for NLnet Project: Tor for Low
Bandwidth Clients.


Modified: website/trunk/projects/en/lowbandwidth.wml
===================================================================
--- website/trunk/projects/en/lowbandwidth.wml	2009-01-08 00:53:01 UTC (rev 18016)
+++ website/trunk/projects/en/lowbandwidth.wml	2009-01-08 06:00:42 UTC (rev 18017)
@@ -230,25 +230,80 @@
 
 <tr>
   <td>
-    Sep 08
+    <a id="Sep08"></a>
+    <a class="anchor" href="#Sep08">Sep 08</a>
   </td>
   <td>
+<small><em>No updates for September.</em></small>
   </td>
 </tr>
 
 <tr bgcolor="#e5e5e5">
   <td>
-    Oct 08
+    <a id="Oct08"></a>
+    <a class="anchor" href="#Oct08">Oct 08</a>
   </td>
   <td>
+<small><em><p>We didn't hit our "finish
+the implementation" milestone for this month since the developer leading
+the project has too much on his plate. The good news there is that we've
+gotten quite a bit of the implementation work done, and it's been in for
+several months now (since the August milestone) so it's seen a lot of
+testing already. The remaining implementation steps are to teach relays
+how to receive requests for fetching a relay descriptor from inside a
+circuit (we probably want to use a new cell type specifically for this,
+so we cut out a round-trip), and then teach clients to do that when the
+relay they're using is running a recent enough version. These two steps
+are written in more detail in 
+<a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt";>Section 3.2 of proposal 141</a></p>
+
+<p>Our new timing plan is to have both of these pieces in place by mid Nov,
+and if that starts looking less likely then we're going to do a more
+radical overhaul of our timing plan and maybe also the design.</p>
+
+ <p>There are several other components we'd like to get
+to after this piece of it -- one we've been thinking about a lot lately
+is downloading "diffs" of the latest consensus:
+<a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt";>140-consensus-diffs.txt</a>.
+First this could save bandwidth, which is always nice when multiplied
+by the total number of clients, but it also means that we can use this
+saved bandwidth to fetch the diffs more often than the current "every
+3 to 4 hours". If clients learn more up-to-date directory information,
+then they can build faster paths because they have better information for
+each relay's bandwidth (which ties into the first NLnet project above),
+but the key new idea is that it also means that we're better at taking
+advantage of transient relays: right now a relay needs to be up for 3 or
+4 hours before it sees any users, and that rules out a lot of volunteers
+who want to run a relay but only want to be up a few hours at a time.</p>
+<p>The next step is to get the
+implementation for proposal 141 finished so we can start putting it in
+front of users for testing. Soon, we hope!</p></em></small>
   </td>
 </tr>
 
 <tr>
   <td>
-    Nov 08
+    <a id="Nov08"></a>
+    <a class="anchor" href="#Nov08">Nov 08</a>
   </td>
   <td>
+<small><em><p>It looks like the
+original plan we had for the last development piece was both a) way
+harder than we hoped, and b) hopefully overkill compared to what we need.</p>
+
+<p> Roger restarted the design discussion on or-dev:
+<a href="http://archives.seul.org/or/dev/Nov-2008/threads.html";>http://archives.seul.org/or/dev/Nov-2008/threads.html</a>.</p>
+
+<p>I think we now have a better handle on the options and tradeoffs:
+<a href="http://archives.seul.org/or/dev/Nov-2008/msg00007.html";>http://archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.</p>
+
+<p>Nick has been buried in other development projects (hopefully starting to
+wrap up this month-ish), and I want to get his opinion on how to proceed;
+I am hoping we'll pick one of the more simple approaches.</p>
+
+<p>Alas, the really simple approaches provide less scalability. But I think
+they will be good stopgaps until later -- and when 'later' arrives, who
+knows what else will have changed.</p></em></small>
   </td>
 </tr>