Opened 5 years ago

Last modified 3 years ago

#17366 new enhancement

Track consensus fetch times per country?

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay privcount-maybe statistics
Cc: mrphs Actual Points:
Parent ID: Points:
Reviewer: Sponsor: SponsorQ-can


Right now Tor directories track consensus download times, and put that in their extrainfo descriptors.

It would be useful to have this info broken down per country, so we can e.g. learn when vanilla Tor starts getting throttled in a particular country (like it did a few years ago). And hey, for obfs4 bridges, it would be neat to compare if they are able to deliver the consensus quickly when vanilla Tor isn't.

I don't think we should put per-country performance stats into extra-info descs here, mostly since they'd get too big. I also briefly considered saying "well I only care about these two countries, so let's put only those in the extrainfo descs", but I think that's not a great strategy either.

So I think the current goal for this ticket is to produce an easy patch for relay operators to use if they want to measure this data, and also to either make this patch sufficiently safe that we're ok if relay operators want to apply it -- or convince ourselves that it is too unsafe and it should not be used.

Child Tickets

Change History (9)

comment:1 Changed 5 years ago by teor

Can we:

  • add noise, and
  • not report the statistic if there are only a few users?

comment:2 Changed 5 years ago by arma

Those sound like fine steps. But notice that I am talking about download times -- number of seconds it takes for the consensus to finish being sent to an unspecified somebody. So the notion of 'users' is not really a well defined one.

comment:3 Changed 5 years ago by karsten

Sounds potentially useful.

But I think I'd prefer an approach where we put these numbers into extra-info descriptors, after solving the problem with stats getting too big and after putting in safeguards like the ones mentioned by teor. Letting relay operators collect data locally and only publishing those if they seem interesting seems like bad practice. Let's only use data that are public, and if something's not safe to be published, let's not use it.

Also note that learning these numbers for obfs4 bridges by country has the same issues as other statistics combining country and transport: potentially tiny user groups. If we can solve that we can also add those other statistics that we need for user numbers.

comment:4 Changed 5 years ago by mrphs

Cc: mrphs added

comment:5 Changed 4 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:6 Changed 4 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:7 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:8 Changed 3 years ago by nickm

Keywords: privcount-maybe statistics added

comment:9 Changed 3 years ago by nickm

Sponsor: SponsorM, SponsorQ, SponsorR, SponsorS, SponsorU, SponsorVSponsorQ-can
Note: See TracTickets for help on using tickets.