[tor-scaling] Summary of 5/31 meeting; next steps

[teor]

Hi,

> On 4 Jun 2019, at 08:11, Mike Perry <mikeperry at torproject.org> wrote:
> 
> But this is a good point for long term: LTS is really going to make it
> impossible to substantially improve the Tor network with any relay-side
> new development improvements prior to Feb 1, 2022 (when the 0.3.5 LTS
> expires).
> 
> Most funders are unlikely to be impressed with our inability to provide
> big-win results sooner than 3 years from now, especially wrt our
> worst-case performance/variance problem. That's probably longer than it
> would take just to build a new Tor-like network, instead... We need to
> find a better way to support Debian/stable relay operators, other than
> simply letting them hold back the network and increase development time
> and maintenance costs by running ancient software.

Most packagers upgrade to the stable Tor version within a month or two of
a release:
https://trac.torproject.org/projects/tor/wiki/doc/packages

For Debian, we also run our own deb.torproject.org with the latest stable.

I'm not sure if there is much more we can do on the packaging side of things.
We could look at how Rust and Firefox do it: some kind of auto-update
mechanism.

But we still need an incentive for operators to configure updates correctly.

Here's are some potential mechanisms:

0. We encourage relay operators to upgrade by contacting them.

1. Older relays log a message that encourages operators to upgrade.

2. Relays on old Tor versions are given a reduced consensus weight.
    We should set the penalty so most clients use newer relays, but not
    so high that newer relays are overloaded.

3. Very old relays are removed from the consensus.

(I can't imagine a world where we successfully backport performance
improvements to very old tor versions.)

T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-scaling/attachments/20190604/21566f46/attachment.html>