[metrics-bugs] #34257 [Metrics/Onionperf]: Analyze unusual distribution of time to extend to first hop in circuit

[Tor Bug Tracker & Wiki]

#34257: Analyze unusual distribution of time to extend to first hop in circuit
-------------------------------+--------------------------------
 Reporter:  karsten            |          Owner:  metrics-team
     Type:  defect             |         Status:  new
 Priority:  Medium             |      Milestone:
Component:  Metrics/Onionperf  |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:                     |  Actual Points:
Parent ID:                     |         Points:
 Reviewer:                     |        Sponsor:  Sponsor59-must
-------------------------------+--------------------------------

Comment (by dennis.jackson):

 The following is all fairly speculative, as I just went looking for
 patterns. I started out by looking at the histograms for each variable,
 broken down by source. I noticed that `bt1` on hk has discrete bands,
 rather than a continuous distribution:

 [[Image(https://raw.githubusercontent.com/galadran/onionperf-guard-
 analysis/master/images/histograms/bt1_op-hk2.png, 90%,align=center)]]

 Contrastingly, the other distributions for `bt1`,`bt2`, `btn` on hk and
 other services are continuous. E.g:

 [[Image(https://raw.githubusercontent.com/galadran/onionperf-guard-
 analysis/master/images/histograms/btn_op-hk2.png, 90%,align=center)]]

 I then went looking for correlations in a very unscientific manner. I
 filtered the data into different aggregates based on the source server and
 the type of circuit, then looked at the fields: `start2req`, `req2fb` and
 `total_build` where `total_build`is the sum `bt1+bt2+btn`. Looking at
 Spearman's Correlation Coefficient, with results broken down in terms of
 strength of correlation:

 {{{
 ['op-nl2,public,start2req,req2fb', 0.6663782621968707]
 ['op-us2,public,start2req,req2fb', 0.6516485005115249]
 ['op-hk2,public,start2req,req2fb', 0.6262807105324466]
 }}}

 So across all servers, increasing the time until use increased the
 eventual RTT. Makes sense.

 {{{
 ['op-nl2,public,start2req,total_build', 0.6297887235661617]
 ['op-us2,public,start2req,total_build', 0.43186586805012234]
 ['op-hk2,public,start2req,total_build', 0.4421435991718628]
 }}}

 The NL server's time till use has a strong correlation with the total
 build time for normal circuits. But the relationship is much weaker for HK
 and USA.

 {{{
 ['op-nl2,public,req2fb,total_build', 0.5314680670242597]
 ['op-us2,public,req2fb,total_build', 0.4231599798026954]
 ['op-hk2,public,req2fb,total_build', 0.35395772056800157]
 }}}

 The same pattern holds here, which is slightly confusing. Why is more of
 the RTT latency "explained" by the total build time for NL rather than
 other servers?

 There's a similar pattern for onion circuits, but with much weaker
 correlations presumably due to the additional hops :

 {{{
 ['op-nl2,onion,req2fb,total_build', 0.4868140884875895]
 ['op-us2,onion,req2fb,total_build', 0.3423980259990133]
 ['op-hk2,onion,req2fb,total_build', 0.36115525053999625]
 }}}

 {{{
 ['op-nl2,onion,start2req,req2fb', 0.3232570551972543]
 ['op-us2,onion,start2req,req2fb', 0.27044144121735336]
 ['op-hk2,onion,start2req,req2fb', 0.22256596270882092
 }}}

 {{{
 ['op-nl2,onion,start2req,total_build', 0.20790575010475945]
 ['op-us2,onion,start2req,total_build', 0.18638791398671606]
 ['op-hk2,onion,start2req,total_build', 0.13381509033834854]
 }}}

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