ExitCompass: statistics about Fast Exits

For the Exit Reimbursement Program, we need the following:

• collect aggregate bandwidth of exit relays per family and country (parse consensus/descriptors using stem), together with relay contact info

• calculate amount of compensation (in USD) per family

• webinterface to display that, a history of these values and a total aggregate per month

• generate monthly reports and send a summary to moritz (+ tor-reports?), and detailed reports to families

added component::metrics/compass owner::gsathya priority::medium resolution::wontfix severity::normal status::closed type::enhancement labels

Trac:
Cc: N/A to karsten

(cc-ing atagar coz he likes things that use stem and I would love his code review on this tool ^_^)

Trac:
Cc: karsten to karsten, atagar

Trac:
Description: For the Exit Reimbursement Program, we need the following:

• aggregate bandwidth of exit relays per /24 (parse consensus/descriptors starting June 2012 using stem), together with relay contact info
• a webinterface that shows the percentage of when a /24 actually met the 100mbit/200mbit requirement

to

For the Exit Reimbursement Program, we need the following:

• collect aggregate bandwidth of exit relays per family (parse consensus/descriptors using stem), together with relay contact info
• webinterface to display that, a history of these values and a total aggregate per month

Trac:
Description: For the Exit Reimbursement Program, we need the following:

• collect aggregate bandwidth of exit relays per family (parse consensus/descriptors using stem), together with relay contact info
• webinterface to display that, a history of these values and a total aggregate per month

to

For the Exit Reimbursement Program, we need the following:

• collect aggregate bandwidth of exit relays per family and country (parse consensus/descriptors using stem), together with relay contact info

• webinterface to display that, a history of these values and a total aggregate per month

I modified the description because the new objective is to apply a factor based on the country the relays are based in, so we need to aggregate not only by family, but also by country.

We should play with deriving a factor that is inversely proportional to the total exit probability of the country, and combine that with a constant per country which can be tweaked in respect to laws (treaties etc).

quick draft pseudo code

for all relays:
 exitbw[relay.family][relay.country] += relay.exitbw

for family in [0..families]:
 for country in [0..countries]:
  cashout[family] += exitbw[family][country] 
                     * constantfactor[country] 
                     / exitprobability[country]   # take care of 0

Trac:
Description: For the Exit Reimbursement Program, we need the following:

• collect aggregate bandwidth of exit relays per family and country (parse consensus/descriptors using stem), together with relay contact info

• webinterface to display that, a history of these values and a total aggregate per month

to

For the Exit Reimbursement Program, we need the following:

• collect aggregate bandwidth of exit relays per family and country (parse consensus/descriptors using stem), together with relay contact info

• calculate amount of compensation (in USD) per family

• webinterface to display that, a history of these values and a total aggregate per month

• generate monthly reports and send a summary to moritz (+ tor-reports?), and detailed reports to families

Replying to mo:

For the Exit Reimbursement Program, we need the following:

• collect aggregate bandwidth of exit relays per family and country (parse consensus/descriptors using stem), together with relay contact info

Hi. Does anyone know the most optimal method of grouping relays by family?

Hi. Does anyone know the most optimal method of grouping relays by family?

A family relationship only exists if two relays both declare each other to be in their family. That is to say, if relay A declares B to be in its family, but B doesn't declare A then no family exists.

I suppose you could process descriptors into sets of relays that all declare families with each other. Some relays may appear in multiple sets though. I don't know an elegant way of doing this offhand (code I have in mind is a little messy).

Replying to atagar:

I suppose you could process descriptors into sets of relays that all declare families with each other. Some relays may appear in multiple sets though. I don't know an elegant way of doing this offhand (code I have in mind is a little messy).

If I have 3 relays A, B and C which have each other in their family. Ideally we should have one family formed. but if I group them with each other, I'd get 3 families no?

Replying to gsathya:

Hi. Does anyone know the most optimal method of grouping relays by family?

#6662 (moved) might be relevant. A summary might be to group by the largest mutual relationship unit and merge overlapping families, taking into account cached descriptors for relays that are not available at the time of examination.

Trac:
Username: peer

Trac:
Username: rejozenger
Cc: karsten, atagar to karsten, atagar, rejo@zenger.nl

I believe that either the "Exit Reimbursement Program" has ended long ago, or that whoever is in charge for that has found an alternative solution. Closing.

Trac:
Severity: N/A to Normal
Resolution: N/A to wontfix
Reviewer: N/A to N/A
Status: new to closed
Sponsor: N/A to N/A

closed