projects/en/lowbandwidth.wml (7aa250fa9) - tor-webwml.git

lowbandwidth.wml

## translation metadata
# Revision: $Revision$
# Translation-Priority: 3-low

#include "head.wmi" TITLE="NLnet Project: Tor for Low Bandwidth Clients"

<h2>NLnet Project: Tor for Low Bandwidth Clients</h2>
<hr />

The Tor anonymity system is currently only usable by internet users who
have high-bandwidth connections. Upon the start of the Tor client, a large file
with all Tor server descriptions is being downloaded. This file is the so-called Tor
Directory and enables the client to choose from the available mix-servers in the Tor network. The
download of the full Tor Directory is required by the current Tor protocol. This directory
file is too large for users on modem lines or on mobile data networks like GPRS as the initial
download that is triggered every time an user logs in takes 10 to 30 minutes over a slow
line. As a result, Tor is not usable by modem and mobile users. One of the major goals of
the Tor project is to provide secure anonymous internet access to users in dictatorships
and repressive states. These locations often have very slow internet connections,
either by modem or due to low-bandwidth links to the outside world. By enabling these users to
use the Tor network, significant progress can be made towards free communication and
information in these countries.

To make Tor usable also for users on low-bandwidth connections, an
evolution of the Tor protocol is needed to reduce the initial download size. This new Tor
protocol version should change the way a client receives the information for its Tor
circuit setup in a way, that the initial download can be performed over a 14.4 kbps modem line
in about three minutes. The work to be conducted under the proposal has the ultimate
goal of getting the protocol change production ready and propagated to the Tor users
within a timeframe of less then 12 months. The resulting software will be published under
the 3-Clause BSD license, as all of the Tor code. All deliverables will be fully public.

This project is generously funded by:

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Project</big></th>
<th><big>Due Date</big></th>
</tr>
</thead>

<tr bgcolor="#e5e5e5">
 <td>
 Deliverable A: Design and evaluation of the protocol change 
 This deliverable covers the detailed design and
 simulation-based evaluation of the necessary changes and design
 modifications to the current Tor protocol.
 The changes in protocol will be relatively substantial, so it requires a careful
 evaluation of possible repercussions for the security and anonymity of the Tor network. A
 two-month period is planned for this design and evaluation phase, which concludes with an
 extensive peer review. Part of Deliverable A will be a goal definition for performance
 for the implementation phase. The design goal is to shrink the Tor Directory
 size that needs to be downloaded to about 300 Kilobytes, which would enable an user on a 14.4
 kbps line to download it in roughly three minutes. There may be deviations from this
 design goal if required to maintain anonymity and security, but this is the figure to aim for.
 
 </td>
 <td>
 July 15, 2008
 </td>
</tr>

<tr>
 <td>
 Deliverable B:Implementation of protocol change 
 After design, evaluation and peer review the modifications
 need to be implemented and integrated with the current Tor code base. The actual implementation of
 the necessary changes will take approximately three months.
 
 </td>
 <td>
 October 15, 2008
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 Deliverable C:Testing 
 Since the modification is highly critical to the security
 and anonymity of the Tor network, it requires extensive testing and debugging in laboratory and real life
 conditions. A period of three months is projected for testing and debugging, where the
 responsible developer is committed to the testing effort with 1/3 of its time. Part of the
 testing phase will be a public beta period.
 
 </td>
 <td>
 January 15, 2009
 </td>
</tr>

<tr>
 <td>
 Deliverable D:Rollout 
 The actual rollout to the Tor server network will be
 conducted in sync with the regular Tor
 release schedule. As this schedule is dependent on a number of external
 factors, like the completion of other software projects that should go into the same
 release, the actual release time and the time until this release has been accepted and
 installed by most Tor server operators can vary. From experience a period of three to four
 months can be expected. The rollout will be conducted as part of the regular Tor
 release process that is a persistent activity done by volunteers and by personal paid through
 other grants to the Tor project.
 
 </td>
 <td>
 April 15, 2009
 </td>
</tr>
</table>

<a id="Reports"></a>
<h2><a class="anchor" href="#Reports">Monthly Status Reports</a></h2>

There will be in total eight monthly status reports beginning with the
first deliverable on July 15, 2008 and ending with completion of
implementation and testing work on January 15, 2009.

<table width="100%" border="0" cellspacing="0" cellpadding="3">
<thead>
<tr>
<th><big>Month,</big></th>
<th><big>Status Report</big></th>
</tr>
</thead>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Jun08"></a>
 <a class="anchor" href="#Jun08">Jun 08</a>
 </td>
 <td>
 We did some initial measuring of Tor clients
 bootstrapping. The results are not very surprising: a client
 fetches about 10KB of certs, one consensus for 140KB (now 90KB, see
 next paragraph), and about 1.5 megs of Server Descriptors (after
 half of which it starts building circuits).
 
 <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">Proposal
 138</a> shrinks consensus documents by 30% to
 40% and has already been implemented and merged into the spec.
 Implementation is part of the 0.2.1.x-alpha tree and the code will
 take effect once over two-thirds of the directory authorities
 (i.e. 5 out of 6) have upgraded.
 
 <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Proposal
 140</a> does not directly relate to reducing initial download size,
 but instead tries to make subsequent downloads of new consensus
 documents use fewer bytes has also been written up and <a
 href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">sent to
 or-dev</a>. There are some questions to be answered from other Tor
 developers first, but other than that I think it's fine and could
 be implemented.
 
 The Big Thing is making clients not download all 1.5 megs
 of server descriptors. <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Proposal
 141</a> has been <a
 href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">sent
 to or-dev</a>. There are basically 3 things to it, as
 far as I can see at the moment: move load balancing info into the
 consensus (should not be hard), implement something so that Tor
 clients can fetch SDs on demand from routers along their circuit
 while they are building it (described in the draft), and deal with
 exit selection. We're still developing ideas for the last part;
 some possibilities are mentioned in the draft.
 </td>
</tr>

<tr>
 <td>
 <a id="Jul08"></a>
 <a class="anchor" href="#Jul08">Jul 08</a>
 </td>
 <td>
 Work on <a
 href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Proposal
 141</a> is continuing: There are two basic ideas for how to move
 load balancing information into the consensus: One is the
 authorities generate the weights that clients should use and put
 that in the consensus, the other approach is to just put bandwidth
 information from the server descriptor there. The latter option
 is probably friendlier when one also considers <a
 href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Proposal
 140</a> since it avoids a having number of highly fluctuating
 numbers in the consensus.
 
 For handling exit policies <a
 href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">a
 post on the or-dev mailinglist</a> suggests that a hash identifying a
 node's exit policy be added to the consensus document. The addition
 of another 160 high-entropy bits per node to the consensus might
 be a cause for concern but we think that since a lot of the exit
 policies are the same the consensus document will compress nicely.
 Measurements pending.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Aug08"></a>
 <a class="anchor" href="#Aug08">Aug 08</a>
 </td>
 <td>
 Directory authority voting documents, and their consensus
 forming algorithm have been changed to include bandwidth information
 and policy summaries as documented in Proposal 141. Once five of
 the six running authorities have upgraded to trunk at at least
 revision 16554 the consensus will start to include that
 information.
 </td>
</tr>

<tr>
 <td>
 <a id="Sep08"></a>
 <a class="anchor" href="#Sep08">Sep 08</a>
 </td>
 <td>
No updates for September.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Oct08"></a>
 <a class="anchor" href="#Oct08">Oct 08</a>
 </td>
 <td>
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>

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.

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.
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!
 </td>
</tr>

<tr>
 <td>
 <a id="Nov08"></a>
 <a class="anchor" href="#Nov08">Nov 08</a>
 </td>
 <td>
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.

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

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

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.

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.
 </td>
</tr>

<tr bgcolor="#e5e5e5">
 <td>
 <a id="Jan09"></a>
 <a class="anchor" href="#Jan09">Jan 09</a>
 </td>
 <td>

I wrote up the more detailed version of our new design idea,
as an official Tor proposal #158:
<a href="http://archives.seul.org/or/dev/Jan-2009/msg00010.html">http://archives.seul.org/or/dev/Jan-2009/msg00010.html</a>.

I think this is finally the one! (Well, once I finish folding in all
the comments.)

One of the big reasons why the project isn't on its original schedule is
that a main conclusion from <a href="<page projects/hidserv>">Karsten's
NLnet project on hidden service performance</a> was that it's the circuit
extension that's the main killer. Yet this project had proposed to add
more round-trips and complexity into exactly that step. So we needed
to build a better plan to achieve the original goal without screwing up
performance even more.

We've been revising the design proposal over the past weeks, and
I think we'll be ready soon to start implementing. Note that since
we have a bunch of development items we're hoping to land in mid Feb
already, it's likely that this implementation won't land until late Feb
or March. This time for sure!
 </td>
</tr>
</table>

</div>

#include <foot.wmi>

tor-webwml.git

update the status of the low-bandwidth project