I heard that with Snowflake, only one bridge gets picked at random, so if this is true, then there is no benefit.
If you want to try inverse multiplexing, there is the max parameter, which tells the client how many proxies to connect to.However, IIRC it has shown to not increase performance.
Edit: I was wrong, max currently doesn’t implement inverse multiplexing. The MR has not been merged.
If that random picked bridge’s snowflake proxy(peer) stop work, can tor faster automatic switch to another working bridge with a working snowflake proxy(peer) than single same bridge’s rendezvous retry?
I heard that the max parameter at current implementation do nothing than collect peer , i.e. just receive peers but don’t use them.
Can multiplexing in general help lessen the load to make bridge appear less used to the censors? I read some research papers that censors do traffic analysis now and when they see big chunks of bandwidth going into single direction, they block that address with safe assumption of it being used as tunnel.
If it’s only a proxy that goes away, Snowflake will automatically try to get another proxy, using the same bridge line. The bridge connection does not go down when a proxy goes down: the session is persisted between proxies.
In case rendezvous itself is impossible for a bridge line, I believe Tor will try to switch to another bridge, but I did not test it.
Hmmm. Looks like you’re right. I tested it with --max=2 and it seems to not use the other proxy. The client simply times out and closes the proxy connection:
WebRTC: No messages received for 20s -- closing stale connection.
WebRTC: closing DataChannel
WebRTC: closing PeerConnection
WebRTC: DataChannel.OnClose
WebRTC: Closing
Yes, multiplexing would lessen the load, but I personally am not sure whether it would help to avoid connection interruption in practice as of now.
Edit: the Snowflake paper touches on this:
And of course, even if there are performance and usability benefits, analysis would be required to determine whether simultaneous WebRTC connections form a distinctive network fingerprint.