[tor-bugs] #33401 [Circumvention/Snowflake]: turbotunnel-quic snowflake-client occasionally uses lots of CPU

[Tor Bug Tracker & Wiki]

#33401: turbotunnel-quic snowflake-client occasionally uses lots of CPU
-------------------------------------+--------------------------
 Reporter:  dcf                      |          Owner:  dcf
     Type:  defect                   |         Status:  assigned
 Priority:  Medium                   |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:  turbotunnel              |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+--------------------------

Comment (by dcf):

 I tracked this down to a bug in quic-go that has been fixed in a newer
 version.
  * [https://github.com/lucas-clemente/quic-
 go/commit/079279b9cf4cb5dafc8b7f673a2e7e47a4b6a06e fix mismatching
 expectation of the keep alive timer]
    > session.maybeResetTimer() and session.run() were using slightly
 different definitions of when a keep-alive PING should be sent. Under
 certain conditions, this would make us repeatedly set a timer for the
 keep-alive, but on timer expiration no keep-alive would be sent.

 What was going wrong is [https://github.com/lucas-clemente/quic-
 go/blob/907071221cf97f75398d9cf8b1174e94f56e8f96/session.go#L449 here].
 {{{
     deadline = s.idleTimeoutStartTime().Add(s.peerParams.IdleTimeout / 2)
 }}}
 If the current time is more than 50% of `IdleTimeout` past
 `idleTimeoutStartTime`, then this line computes a deadline in the past.
 The deadline in the past makes the `s.timer` always immediately
 selectable, which makes `session.run` always call back right into
 `maybeResetTimer` and set another deadline in the past. It continues until
 some external event such as an arriving packet resets
 `idleTimeoutStartTime`.

 We can resolve the problem by using a more recent commit of quic-go. But
 the commit [https://github.com/lucas-clemente/quic-
 go/commit/079279b9cf4cb5dafc8b7f673a2e7e47a4b6a06e 079279b] we need is not
 in any published release yet (v0.14.4 is the newest as of this writing,
 released just 4 days ago). So we would have to set it to a specific commit
 rather than a tag.

 The instability of quic-go is making me like it less for Turbo Tunnel
 purposes. This isn't the first time I've found a bug in the most recent
 tagged release that had already been fixed in master (i.e., not in any
 version that `go get` would get for you with Go modules activated). The
 other time was [https://github.com/lucas-clemente/quic-go/issues/2172
 GH#2172].

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