[tor-bugs] #31893 [Applications/Tor Browser]: Measure performance of update pings and update downloads in Tor Browser

[Tor Bug Tracker & Wiki]

#31893: Measure performance of update pings and update downloads in Tor Browser
--------------------------------------+--------------------------
 Reporter:  gk                        |          Owner:  tbb-team
     Type:  task                      |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-performance           |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (by arma):

 Here is a concrete simple option: Tor Browser remembers the rtt from its
 last update ping, and includes it in the http headers of its next update
 ping.

 Then we'd change the apache config to write those headers down somewhere.

 Even this simple plan needs some more design. For example:

 * Do we want to remember this info across restarts of Tor Browser, or only
 do it when the browser has been running the whole time? The simple choice
 is to only remember it in memory.

 * Is there anything about the previous value that could be too sensitive
 to (anonymously) share? My first thought would be "no, it's fine", and my
 backup answer if we don't like the first one would be "we could round to
 the nearest 10ms or something".

 * What exactly do we mean by rtt? Do we mean the time from when the
 browser decides it wants to check an update until the time it knows its
 answer? Because that conflates "time waiting for a circuit to be ready,
 time waiting for the connected cell, time for answering the update ping".
 We could break those into their components and report each one separately.
 Or the simpler approach, if we truly mean rtt, is to only track the
 response time between when Tor sends the http request, and the time it
 gets its answer. Even that is complicated a bit by whether and how we are
 doing the optimistic data trick. But it sounds totally doable.

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