projects/en/lowbandwidth.wml (51bc2b4a1) - 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 />

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

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

<p>
This project is generously funded by:
</p>

<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>
    <b>Deliverable A:</b> Design and evaluation of the protocol change<br />
    <small><em>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.
    </em></small>
  </td>
  <td>
    July 15, 2008
  </td>
</tr>

<tr>
  <td>
    <b>Deliverable B:</b>Implementation of protocol change<br />
    <small><em>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.
    </em></small>
  </td>
  <td>
    October 15, 2008
  </td>
</tr>

<tr bgcolor="#e5e5e5">
  <td>
    <b>Deliverable C:</b>Testing<br />
    <small><em>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.
    </em></small>
  </td>
  <td>
    November 15, 2008
  </td>
</tr>

<tr>
  <td>
    <b>Deliverable D:</b>Rollout<br />
    <small><em>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.
    </em></small>
  </td>
  <td>
    February 15, 2009
  </td>
</tr>
</table>

<br />

<a id="Reports"></a>
<h2><a class="anchor" href="#Reports">Monthly Status Reports</a></h2>
<p>
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 February 15, 2009.
</p>

<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>
    <small><em>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).</em></small>
    <br />
    <small><em><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.</em></small>
    <br />
    <small><em><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.</em></small>
    <br />
    <small><em>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.</em></small>
  </td>
</tr>

<tr>
  <td>
    <a id="Jul08"></a>
    <a class="anchor" href="#Jul08">Jul 08</a>
    <small><em>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
    141</a> since it avoids a having number of highly fluctuating
    numbers in the consensus.</em></small>
    <br />
    <small><em>For handling exit policies <a
    href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">a
    post on the or-dev mailinglist</a> sugests 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.</em></small>
  </td>
  <td>
  </td>
</tr>

<br />

</div>

#include <foot.wmi>

tor-webwml.git

july progress: p#141 questions mainly under discussion: load balancing and exit policy handing