[tor-bugs] #33336 [Circumvention/Snowflake]: Trial deployment of Snowflake with Turbo Tunnel (was: Deploy a Turbo Tunnel–aware Snowflake bridge)

[Tor Bug Tracker & Wiki]

#33336: Trial deployment of Snowflake with Turbo Tunnel
-------------------------------------+--------------------------
 Reporter:  dcf                      |          Owner:  dcf
     Type:  task                     |         Status:  accepted
 Priority:  Medium                   |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:  turbotunnel              |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+--------------------------

Comment (by dcf):

 Replying to [comment:11 dcf]:
 >  * It may be my imagination, but I get the impression that everything
 works better while the connection is being used. Initially my impression
 was positive as I was trying to stress the system by having videos playing
 in the background. Then the experience became more frustrating as I tried
 normal text browsing and I encountered the occasional delays mentioned
 above. It made me think that perhaps there is something in the proxy that
 drops idle connections, but I didn't find anything like that. It's
 possible that this is my imagination and that my initial impression was
 just getting good luck with proxies.

 I think I know why idle browsing seemed to disconnect more, at least in
 the quic case. It's because the older version of quic-go we are using
 (2019-04-01) does not send frequent enough keepalives. It sets the
 keepalive interval to half the idle timeout, which for us is
 [https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/snowflake.go?h
 =turbotunnel-quic&id=d5be0906ffe4ef8de8a9345690713bc362d3bcee#n72 10
 minutes]. Keepalives every 5 minutes are not enough to prevent
 [https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/webrtc.go?h
 =turbotunnel-quic&id=d5be0906ffe4ef8de8a9345690713bc362d3bcee#n110
 checkForStaleness] from killing the connection after 30 seconds of
 idleness.

 The keepalive issue is [https://github.com/lucas-clemente/quic-
 go/issues/2200 fixed in a newer version of quic-go] (2019-11-10):
 > Currently, we're sending a keep-alive-PING after half the idle-timeout
 period. This doesn't work well for long idle timeouts, if we need to keep
 a NAT binding alive. We should send a PING after `min(30s, idle timeout /
 2)`.
 The [https://github.com/lucas-clemente/quic-
 go/commit/bd94f21ab091e4e3403869faa43605db457d5e0d actual commit] uses
 20s, not 30s, which is low enough to inhibit checkForStaleness as long as
 the connection is actually working.

 I can try doing another Tor Browser build with a more recent version of
 quic-go, assuming I can find a new enough version of quic-go that is also
 compatible with pion-quic (which
 [https://github.com/pion/quic/blob/v0.1.1/go.mod#L4 currently specifies]
 the old version from 2019-04-01).

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