[tor-bugs] #33336 [Circumvention/Snowflake]: Deploy a Turbo Tunnel–aware Snowflake bridge

[Tor Bug Tracker & Wiki]

#33336: Deploy a Turbo Tunnel–aware Snowflake bridge
-----------------------------------------+-------------------------
     Reporter:  dcf                      |      Owner:  dcf
         Type:  task                     |     Status:  assigned
     Priority:  Medium                   |  Milestone:
    Component:  Circumvention/Snowflake  |    Version:
     Severity:  Normal                   |   Keywords:  turbotunnel
Actual Points:                           |  Parent ID:
       Points:                           |   Reviewer:
      Sponsor:                           |
-----------------------------------------+-------------------------
 We now have a
 [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel
 turbotunnel branch] of Snowflake that uses an inner transport protocol to
 migrate session across multiple proxies.
  * https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/000059.html
 And some first-draft Tor Browser builds that can use it:
  * https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/000069.html

 I want to deploy a bridge that supports Turbo Tunnel, then make Tor
 Browser builds and invite testers to test them.

 There's the question of whether to run the Turbo Tunnel code on the
 existing public bridge, or to set up a second bridge reserved for the
 Turbo Tunnel experiment. I propose to run the Turbo Tunnel code on the
 existing public bridge (i.e., snowflake.torproject.net). This is because
 (1) the Turbo Tunnel server is [https://lists.torproject.org/pipermail
 /anti-censorship-team/2020-February/000062.html backward-compatible] with
 non–Turbo Tunnel clients, and (2) we would need to somehow provide proxy
 capacity for the second bridge, which our current proxy code cannot easily
 handle. Running a separate bridge would have the advantage, though, that
 because we would have to run our own special proxy-go instances to support
 it, we could closely control the proxy environment; but part of my goal in
 an experimental deployment is to see how the Turbo Tunnel code fares with
 the organic proxies we have now.

 I've have versions of the code using two different session/reliability
 protocol libraries: kcp-go and quic-go. Other than to note that two two
 libraries are [https://github.com/net4people/bbs/issues/14 basically
 equivalent in features], I haven't done much to compare them as to
 performance. kcp-go is more mature and stable, while quic-go
 [https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/000069.html add fewer dependencies to the Tor Browser
 build].

 We could make use of this opportunity to compare the two options. We set
 up a triple-mode bridge: supporting legacy, KCP, and QUIC clients. We make
 two Tor Browser builds, one with KCP and one with QUIC, and invite testing
 of both. Based on the results of user testing, we decide which we like
 better, and finally deploy only that option (and the backward-compatible
 mode). The only thing is, giving people two options to test is more
 confusing than giving them one.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33336>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online