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

[Mike Perry]

teor:
> Hi,
> 
> On 4 Jun 2019, at 08:11, Mike Perry <mikeperry at torproject.org 
> <mailto: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 <http://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.)

I like these. I would also add:

-1. Declare LTS support to be for clients only, and emphasize that 0.2.9
client anonymity sets will be very small.

That way we avoid the Debian/stable flamewar: "Sure, you can keep our
old software in your distro, and we'll even fix client-side security
vulnerabilities for you, but it won't run as a relay. For that, people
must add deb.torproject.org repos."

I think this will make it politically easier to deploy your #0-3
mechanisms in a slow-but-sooner-than-2020 trajectory.


Relay operators are already making some special effort to run a relay.
Asking them to add a well-run reproducible repo (as a log message
emitted from 0.2.9 when people try to use it as a relay) is not a big
additional ask.

As part of this policy, to avoid protocol ossification from the
client-side, I think we should disregard the implications of a
vanishingly small 0.2.9 client userbase when making protocol deployment
decisions. Ex: if only 4 debian/stable clients are the only 4 tor
clients with an exit-side protocol fingerprint from a Tor version from
2017, oh well. #notabug #UseTorBrowser.


Should we make this into a Tor proposal? We definitely should discuss it
in Stockholm, perhaps as a part of a relay operators meeting there.

-- 
Mike Perry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-scaling/attachments/20190606/25f3f62a/attachment.sig>