Internet Messaging versus Congested Network
A snow storm in the Sierras knocked out power, cell towers, internet connectivity, and emergency communication systems. There is a DSL line where we were staying to which wifi is connected--only available in the lobby. Imagine closed roads, other campsites closed and those campers redirected to our hotel, and 100+ people on the wifi. The only road through southern Yosemite was closed for hours and eventually opened to 4WD vehicles with chains. The storm raged on. It made for some great hiking when it cleared for a few hours.
In past visits, I know the DSL is an old PacBell copper line strung through the forest. Hotel guests are given 2.5 Mbps(megabits per second) symmetric, where I assume the management get more, or at least priority. Yes, that's 2.5 Mbps for all the hotel guests. The point of the hotel is to get away from it all, so the system works well to encourage everyone to get outside. There is a Verizon tower somewhere nearby which generally has 16 Mbps down and 6 Mbps up bandwidth. It gets worse as more devices are connected to the tower. Apparently this Verizon tower doesn't carry other traffic, as non-Verizon phones don't connect for voice or data. In reality, it's a tower leased exclusively to Verizon Wireless. In prior years, it was AT&T-only. The current MCC is 310 and MNC is 480, which is Verizon Wireless.
And now you have the background for the congested network. I fired up wireshark and saw just endless tcp and udp retransmissions. This is about what I expected. Browsing the web was impossible, even checking email timed out. So, let's chat. Ha ha! Just kidding! Most apps timed out starting up and never connected to their server.
A few apps are Electron JS interfaces to their website or API. As these work over HTTP/HTTPS, it was pretty poor performance and therefore unusable. They generally use websockets or webrtc for communications. Briar is a stand-alone app that relies on tor for its Internet-based communications. Since tor doesn't handle heavily congested networks very well, it failed miserably. What did work is when I let two phones with Briar talk over local wifi, instead of the internet. However, if you're on the same wifi, maybe a face to face is better. Depending on your threat model, maybe not. Discord, Briar, and Wire failed.
Let's move onto apps that use protocols designed for decentralized messaging. Next up, Matrix. Matrix is the new hotness, but it's pretty early in development. It struggled to send and receive messages. When joining a room, it has to sync everything since the last time the client connected, or in some cases, a ton of history, like megabytes of it. This doesn't work too well in this heavily congested scenario. Once the sync is done, it still took 20-30 seconds for my messages to be sent and another 20 seconds for further responses. I'm not sure why this was the case, but overall, it did work, albeit slowly. Not real time, but not a fail.
And our final app of the impromptu torture test is XMPP. Sparing you a long read, this one fared the best. It worked in real-time, full encryption, with nearly zero lag.
In summary:
failed: wire, briar, discord. worked slowly: matrix. worked normally: xmpp.
Next time you need a protocol that works in a heavily congested network, use XMPP. Matrix could get there with work. For now, here's a nice comparison of Matrix vs XMPP. I'm sure there are others, but I didn't have them installed.
XMPP > * ;)