Opened 8 years ago

Closed 8 years ago

#2794 closed task (implemented)

Find a good metric for bridge churn

Reported by: karsten Owned by: karsten
Priority: Medium Milestone:
Component: Metrics/Analysis Version:
Severity: Keywords:
Cc: arma, Sebastian Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We are still lacking a good metric for bridge churn, that is, the rate of joining and leaving bridges over time. If this rate is too high, we should give out more bridges to bridge users, because otherwise they'll soon end up with bridges that left the network. If the rate is lower than expected, we might even give out fewer bridges, and bridge users will still be able to use Tor.

Here's a possible metric for bridge churn: Of the bridges that are running at the beginning of a month, what fraction keeps running throughout the month? And what fraction of bridges keeps running on the same IP address that they had at the beginning of the month?

In the attachment you'll find a graph for January 2011. The graph shows when bridges that were running on January 2 are listed in the bridge network status throughout the month with a) any IP address or b) the same IP address. I'm going to commit the code to metrics-tasks and add a link here later today.

Thoughts?

Child Tickets

Attachments (1)

still-running-bridges.png (169.5 KB) - added by karsten 8 years ago.
Uptimes of bridges that were running Jan 2, 2011, 00:00:00 UTC

Download all attachments as: .zip

Change History (7)

Changed 8 years ago by karsten

Attachment: still-running-bridges.png added

Uptimes of bridges that were running Jan 2, 2011, 00:00:00 UTC

comment:1 Changed 8 years ago by karsten

Status: newassigned

The code to generate the attached graph is here.

comment:2 Changed 8 years ago by arma

Component: MetricsAnalysis

comment:3 Changed 8 years ago by karsten

Cc: arma Sebastian added

Screw the metric from 7 months ago. Here's the new plan:

While working on the Guard/Stable flag analysis (#2911), I came up with a new notion of bridge stability: "A stable bridge relay should be running on the same IP address a few days after a client learns about the bridge and should be available most of the time in the upcoming weeks."

The idea is that there are two cases when a bridge that BridgeDB told us becomes useless: a) when the bridge isn't around much or b) when the bridge changes its IP address or port.

I suggest to make Tonga calculate two metrics for all bridges, similar to how the directory authorities calculate them for relays: a) Weighted Fractional Uptime (WFU) and b) Mean Time Between Address Change (MTBAC). Tonga then assigns a StableBridge flag to bridges with a WFU at least as high as the median WFU and a MTBAC at least as high as the median MTBAC. BridgeDB would give out at least one bridge with the StableBridge flag (instead of doing so for the Stable flag).

I'm going to evaluate this new flag by looking at the sanitized bridge descriptor archive of, say, the first half of 2011. I should be able to reconstruct when a bridge failed (dropped out of the bridge network status) and when it changed its address or port. The latter part may be difficult, because we're changing the key of the keyed hash function once per month. The result is going to be sets of bridges that would have gotten the StableBridge flag at any given time in the analysis interval. Then I'm going to look up the future WFU and the time until next address change (TUNAC). Ideally, most of the bridges with the StableBridge would have a WFU of 90% or more and a TUNAC of a few days or more.

Does that approach make sense? I'm asking now, because this analysis is going to keep me and Mr. CPU busy for a few days. If there's something else I should consider in the analysis, please let me know before I start.

comment:4 Changed 8 years ago by Sebastian

Seems to make sense, unless you also figure blocking into the equation. But we can't evaluate that yet anyway, so, erm, go for it?

comment:5 in reply to:  4 Changed 8 years ago by karsten

Replying to Sebastian:

Seems to make sense, unless you also figure blocking into the equation. But we can't evaluate that yet anyway, so, erm, go for it?

No, we don't have good data about blockings. Going for it.

comment:6 Changed 8 years ago by karsten

Resolution: implemented
Status: assignedclosed

Actually, I just created #4255 for the StableBridge analysis. It's a different analysis from what this ticket description says. Closing this ticket, because the analysis for this ticket is done.

Note: See TracTickets for help on using tickets.