[tor-bugs] #2866 [Analysis]: Analyze bridges in the "reserved" bucket

[Tor Bug Tracker & Wiki]

#2866: Analyze bridges in the "reserved" bucket
----------------------+-----------------------------------------------------
 Reporter:  karsten   |          Owner:                
     Type:  task      |         Status:  needs_revision
 Priority:  normal    |      Milestone:                
Component:  Analysis  |        Version:                
 Keywords:            |         Parent:                
   Points:            |   Actualpoints:                
----------------------+-----------------------------------------------------
Changes (by karsten):

  * status:  needs_review => needs_revision


Comment:

 Replying to [comment:7 peer]:
 > Based on the bridge pool assignments for December 2012, there does not
 appear to be large differences in approximate uptimes based on category
 (email/https/unallocated).
 >
 > December 2012 has 1477 (expected: 1488)

 Sounds like we missed a few bridge pool assignment files when collecting
 them using metrics-db.  If this turns out to be problematic for your
 analysis, I can have a look why that happened.

 > assignment files, with timestamps roughly 30 minutes apart. There were
 no empty assignment files.
 >
 > Uptime was approximated by the continuous presence of the bridge's
 hashed fingerprint. Each time unit (in the summary below) would be about
 30 minutes. If a bridge identifier disappeared and reappeared, two uptime
 entries would be generated.

 I'm unclear why you count uptime sessions of the same bridge as distinct
 entries.  I'd think that bridges in the email or https buckets have higher
 overall uptime in the considered months than unallocated buckets.

 > If multiple category assignments for an identifier exist, only the first
 entry would be taken into account.

 In theory, bridges are not re-assigned to other buckets.

 > Based on uptime entry counts, bridges did not appear to change
 categories between consecutive assignment files. However, there does
 appear to be slightly fewer uptime entries for the unallocated pool
 relative to its fraction (0.13 versus > 0.15).

 The fact that there are fewer entries for the unallocated pool may
 indicate that these bridges don't come back as often as bridges in the
 other pools.  See my comment above about counting uptime sessions of the
 same bridge more than once.

 > If this analysis is on the right track, the code can be added to the
 repository.

 Sure, please post a metrics-tasks branch here, and I'll merge it.  Thanks!

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