Opened 7 years ago

Closed 7 years ago

#4255 closed task (implemented)

Simulate how BridgeDB can identify stable bridges

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

Description

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.

Setting priority to major, because this is a deliverable for November 1, 2011.

Child Tickets

Change History (4)

comment:1 in reply to:  description Changed 7 years ago by arma

Replying to karsten:

I suggest to make Tonga calculate two metrics for all bridges

Is this calculation something better done by bridgedb? It isn't really necessarily a Tor thing.

I guess it depends what developers we have to work on it. But that's kind of a sad way to make architectural decisions. :)

comment:2 Changed 7 years ago by karsten

Summary: Simulate a new StableBridge flag to assign to stable bridgesSimulate how BridgeDB can identify stable bridges

You're right, this can as well be implemented in BridgeDB. The reason why I thought Tonga should do it is that BridgeDB uses Tonga's Stable flag to identify stable bridges right now. But I think that's broken, both conceptually (a bridge is more like a guard than a node for long-running connections) and in the implementation (almost all Running bridges have the Stable flag).

Changing the ticket summary.

The analysis is unaffected by this change, though. Or rather, results will be even more accurate, because BridgeDB will use the same data that we use for this analysis (minus the inaccuracy from sanitizing IP addresses), whereas Tonga would have had more precise reachability information.

comment:3 Changed 7 years ago by karsten

Finished a first draft of the bridge stability report. Feedback much appreciated, even though requests for substantial changes have a high probability of going into the future work section.

comment:4 Changed 7 years ago by karsten

Resolution: implemented
Status: newclosed

Added some feedback from Roger and Sebastian. Final draft for the November 1 milestone is here.

Closing.

Note: See TracTickets for help on using tickets.