Pluggable Transports Metrics

Abstract: Why does metrics.tpo show so little PT action? How can we fix this?

Minutes

To look at metrics for Pluggable transports, we look at how many consensus docs are downloaded from bridges. 10 downloads per day are required to keep a client running

Same measurement for directly connecting and connecting by bridges.

We know how many unique IPs are connecting. Do not know how many the same IP connects, not necessary. Measure by method of connection obfsBridge is 1500 users per day. Don’t know how long they have been connected. Nor do they know how many directory connections are made. Could users spoof IP addresses to game the stats? Nick Hopper noted it would be difficult as it would be necessary to control the router infrastructure.

It seems most users are downloading the default bridges, rather than requesting new bridges. If you configure all 10 bridges, then the consensus is downloaded only from one of them. Want unique number of clients in the network. Nick Hopper has identified a research project under nsf grant to measure this more precisely.

Bridge descriptor archive. Are all bridges in the bundle public bridges? What fraction of reports are we getting? We currently measure 24 hour periods. Not all bridges run for 24 hours. Also some bridges may be offline when a report is done.

Matt checked his bridge and download. He had 1096 users for latest measurement period.

Linus checked his 2 bridges, which have been obfs3 since a few weeks ago. He has only 8 users.

Look at how many other bridges have a large number of direct connection lines.

Only interested in pluggable transport bridges. Parsing to bridges that have obfs2.

looking for descriptors with a certain date

grep for published and bridge IP transport line, dates and obfs2
grep -c 50 -r * bridgestatsend 2014 -howto -15 | grep bridge.* obfs2