Opened 7 days ago

Last modified 6 days ago

#32938 assigned enhancement

Have a way to test throughput of snowflake proxy

Reported by: cohosh Owned by: cohosh
Priority: Medium Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords: snowflake-webextension, ux-team, anti-censorship-roadmap-october
Cc: arlolra, cohosh, phw, dcf Actual Points:
Parent ID: #31109 Points: 3
Reviewer: Sponsor:

Description

A common question from snowflake proxy volunteers is whether or not their proxy is working (see comment 11 on #31109). It would be great to have some kind of bandwidth test for proxy owners to see whether or not their proxy is reachable from a remote probe point. This might also help us find and diagnose problems with existing proxies.

Some notes:

  • we can't ask the broker to assign us a specific proxy at the moment so this test would likely be separate from the broker (unless we add an entirely new feature which I'm hesitant to do)
  • we'll have to protect this service from abuse somehow, probably by rate-limiting. See some discussion on #31874. It would be best to engineer a way so that only a proxy owner can run the test on their proxy.

Child Tickets

Change History (4)

comment:1 Changed 7 days ago by cohosh

The first question to answer is where to do the bandwidth test from. Here are some options:

  • Have the broker do it. This would require adding WebRTC libraries to the broker which would significantly impact the size
  • Have a different endpoint do it and either hardcode this endpoint at the proxies or have the broker facilitate communicating with the probe point. This way, the endpoint could be behind a NAT.
  • Measure throughput of real traffic that passes through the proxy. This has a potential impact on client privacy and we should be careful of how we do this.

comment:2 in reply to:  1 Changed 7 days ago by cohosh

Replying to cohosh:

  • Measure throughput of real traffic that passes through the proxy. This has a potential impact on client privacy and we should be careful of how we do this.

Another thing to consider here is that measuring throughput from real traffic won't give a good idea of the maximum throughput, just the amount of data any particular client is pushing through it.

comment:3 Changed 6 days ago by cohosh

I had a thought about how this might also be used for better overall network health (particularly as a potential solution for #25681). I could envision a browser proxy peforming the following set of steps at startup:

  • Do the various checks we already have for WebRTC permissions and a probe of the Snowflake bridge
  • Request a throughput check from a probe point we run (perhaps we can use the same machine that hosts bridgestrap from #31874, which is conveniently already written in Go)
  • The probe point will craft an offer and exchange SDP information with the proxy and then proceed with a download/upload test. The probe point will gather throughput statistics from this test, sign them, and hand them to the proxy.
  • When the proxy polls the broker, it sends the signed throughput statistics in the poll. The broker can then either priortize proxies based on their throughput or use an implementation of #25598 to inform the proxy how often to poll based on their throughput and the current need

comment:4 Changed 6 days ago by cohosh

Points: 3

Setting the points on this to 3 days

Note: See TracTickets for help on using tickets.