[tor-dev] Why the seeming anticorrelation between obfs3 and vanilla bridges in metrics graphs?

[David Fifield]

In the past few months of bridge user graphs, there is an apparent
negative correlation between obfs3 users and vanilla users: when one
goes up, the other goes down. If you draw a horizontal line at about
5500, they are almost mirror images of each other. I don't see it with
any other transport pairs. Any idea why it might be?

I can see what could cause a simultaneous decrease in vanilla and
increase in obfs3: Tor gets blocked somewhere and users switch to obfs3.
But I wouldn't expect blocking events to look so smooth or happen so
frequently, and it doesn't explain why the reverse change happens later
(obfs3 being blocked while Tor is unblocked is less plausible). I can
also understand the overall long-term trend of obfs3 increasing and
vanilla decreasing. But I don't see why they should mirror each other so
closely over short time periods.

Some hypotheses:
 1. There are lots of users who have a mix of vanilla and obfs3 bridges
    configured. Their tor (randomly?) chooses one of them, which usually
    works. The number of such users is constant over the short term;
    i.e. the sum of obfs3+vanilla is constant, but the proportion of
    obfs3 and vanilla fluctuates randomly.
 2. Maybe vanilla-down/obfs3-up is caused by blocking events, and
    vanilla-up/obfs3-down is caused by natural new-user churn and/or
    coincidence.
 3. There is something about the way BridgeDB hands out bridges, or the
    way in which users use it, that causes it to give out obfs3 bridges
    at the expense of vanilla and vice versa.
 4. Some kind of feedback loop: obfs3 bridges get used and get
    congested, so users switch to vanilla, which then get used and
    congested, etc.

David Fifield
-------------- next part --------------
A non-text attachment was scrubbed...
Name: userstats-bridge-transport-<OR>-obfs3-2014-08-01-2014-10-23.png
Type: image/png
Size: 28913 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141023/f2d78458/attachment-0001.png>