Connection unstable should be computed using the connection speed when the VPN is off

[data-sync-user]

Right now, we consider the connection as unstable if there is more than 1 sec from a ping and its response. This is not good enough for slow internet connections. I suggest computing a quick speed test using ICMP packages before activating the VPN, and at any network connectivity changes. We can use the speed value to extend/reduce that 1-second gap.

┆Issue is synchronized with this Jira Task ┆Reporter: Andrea Marchesini

[data-sync-user]

➤ Andrea Marchesini commented:

This could fix https://mozilla-hub.atlassian.net/browse/VPN-1159 ( https://mozilla-hub.atlassian.net/browse/VPN-1159|smart-link ).

[data-sync-user]

➤ Owen Kirby commented:

The connection stability thresholds have been through a few rounds of tweaking since this issue was filed. I suspect that it may now be fixed (current algorithm uses 1000ms greater than the baseline latency measurement to doh.mullvad.net)

I think we should spend no more than half a day testing and then close this issue if there are no further problems found.

[data-sync-user]

➤ Naomi Kirby commented:

This has been implemented, and my steps to test on a Linux machine are as follows:

1. Open a terminal, and start a ping session to the Mullvad Anycast DOH server using the command ping 194.242.2.2 and leave this running in the background to demonstrate the current network latency.

2. Determine the default network interface that your machine uses for routing by running the command: ip route get 194.242.2.2 this should print something like: 194.242.2.2 via 192.168.1.1 dev src 192.168.1.237 uid 1000 we are interested in the value of and will use it later.

3. Test that the VPN client triggers an unstable network condition at 1000ms above than the baseline latency as follows:

   1. Open the client and leave the client disconnected for 2-3 minutes to settle on a baseline latency measurement.
   2. Select a nearby location and activate the VPN. This should result in a small increase in the reported latency.
   3. Simulate a slow connection by injecting 600ms of latency with the command: sudo tc qdisc replace dev root netem delay 600ms this should dramatically increase the latency of the ping command from step 1. But this should not trigger an unstable network condition.
   4. Increase the injected latency to 800ms with the command: sudo tc qdisc replace dev root netem delay 800ms This should make the latency even worse, still should not trigger an unstable network condition.
   5. Increase the injected latency to 1200ms with the command: sudo tc qdisc replace dev root netem delay 1200ms This should almost immediately trigger an unstable network condition and a silent server switch.
   6. Remove the latency injection with sudo tc qdisc del dev root
   7. Deactivate and close the VPN client.

4. Repeat the test, but manipulate the baseline network latency measurement.

   1. Configure a baseline 400ms delay on the network with the command: sudo tc qdisc replace dev root netem delay 400ms
   2. Open the client and leave the client disconnected for 2-3 minutes to settle on a baseline latency measurement.
   3. Select a nearby location and activate the VPN.
   4. Increase the injected latency to 1200ms with the command: sudo tc qdisc replace dev root netem delay 1200ms. Now that the baseline latency is somewhere around 400ms this should not trigger an unstable network condition.
   5. Increase the injected latency to 1600ms with the command: sudo tc qdisc replace dev root netem delay 1600ms. This should almost immediately trigger an unstable network condition and a silent server switch.
   6. Remove the latency injection with sudo tc qdisc del dev root
   7. Deactivate and close the VPN client.

[data-sync-user]

➤ Valentina Virlics commented:

Verified this while following the provided steps on Linux Kinetic/Jammy, using Mozilla VPN 2.15.0 (2.15.0~rc20230421013654-kinetic1)/2.15.0 (2.15.0~rc20230421013654-jammy1).

• 3.e - the app immediately goes into Unstable state while setting the latency to 1200ms
• 4.d - the Unstable state is triggered after around 30s, but the client recovers.
• 4.e - the client goes immediately into Unstable and remains like this

Are this behaviors correct, Naomi Kirby ? Also, at 4d, you wanted to say 1200 instead of 400?

For this type of tickets (where QA is needed) please put them into “Merged“ state, together with a fixVersion. This way we are sure that nothing bypasses our radar. Thank you!

[data-sync-user]

➤ Santiago Andrigo commented:

Naomi Kirby On which fixVersion did this go?

Moving to Done since QA verified it already.

[data-sync-user]

➤ Naomi Kirby commented:

This was included in the 2.15 release.