tor-webwml.git

@@ -230,25 +230,80 @@ implementation and testing work on January 15, 2009.

 <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>