Interesting discovery about VPNs and packet loss on a lossy FTTC connection

Status
Not open for further replies.

g67575

g67575

g67575

Soldato
Joined
30 Jun 2019
Posts
8,159
So, I get a fair bit of packet loss on my line (FTTC, ECI cabinet), I think due to a weak signal on the upstream.

I've found that I can virtually eliminate packet loss by using a free (unlimited) VPN called Proton, connecting via the Netherlands servers.

The important thing to enable is TCP. Any other protocol reported lots of packet loss. Using the default 'TUN' adapter is probably a good idea too. Advanced options off.

The other interesting thing to note, is that packet loss with the enabled VPN doesn't seem to increase when others in my home are using the same connection.

This does increase latency compared to the VPN set off, but not much.

I tested this using the following website:
https://speed.measurementlab.net/#/

Retransmission seems to be reporting as 0%, tested 10+ times.

The test server is located in Amsterdam, according to the results page.

Also, the latency would ofc be lower if you pay to use a UK VPN.
 
Last edited:
I thought it was reporting "<0.01%" packet loss before, I believe that sites inaccurate aswell & like I previously mentioned it's worth using something like SmokePing if you want an accurate representation of ping/jitter/packet loss.
Not worth routing through a VPN for that little packet loss imo.

Anyway I don't see why you didn't just continue off from any of your threads that I've listed rather than just polluting the subforum with more and more:

https://forums.overclockers.co.uk/threads/are-mlabs-test-results-accurate.18947265/
https://forums.overclockers.co.uk/t...-802-11a-but-1-2-loss-over-ethernet.18947244/
https://forums.overclockers.co.uk/t...c-lantiq-vs-broadcom-modem-chipsets.18946752/
 
g67575 said:
So, I get a fair bit of packet loss on my line (FTTC, ECI cabinet), I think due to a weak signal on the upstream.

I've found that I can virtually eliminate packet loss by using a free (unlimited) VPN called Proton, connecting via the Netherlands servers.

The important thing to enable is TCP. Any other protocol reported lots of packet loss. Using the default 'TUN' adapter is probably a good idea too. Advanced options off.

The other interesting thing to note, is that packet loss with the enabled VPN doesn't seem to increase when others in my home are using the same connection.

This does increase latency compared to the VPN set off, but not much.

I tested this using the following website:
https://speed.measurementlab.net/#/

Retransmission seems to be reporting as 0%, tested 10+ times.

The test server is located in Amsterdam, according to the results page.

Also, the latency would ofc be lower if you pay to use a UK VPN.
Click to expand...

I hate to dent your enthusiasm, but what you've discovered has nothing to do with your FTTC line and is actually just an inherent property of TCP.

TCP is a reliable tranport - its purpose is to ensure that every packet arrives and is in the right order. So of course running a tunnel over TCP makes the tunnel more reliable. There's nothing surprising about that at all.

Plus, using any internet website to test the reliability of your FTTC line is to always risk being misled. If you want to test packet loss on the FTTC line, you should be testing just that. Ideally doing things like pinging the other end of the PPP link from your router and in any case don't use anything off your ISP's network. In doing so you should also consider that you are also relying on the ISPs systems (either their routers terminating the PPP links, or whatever you are pinging instead) not being overloaded to respond in a timely manner.

If your ISP doesn't offer useful tools, then the thinkbroadband BQM is generally reliable, but it too will test more than just your FTTC link.
 
Packet loss (not really packets but that's another matter) shouldn't be happening between an FTTC cabinet and your modem - DLM will kick in to turn interleaving on and there's a lot of error correction that can get involved.

As far as I know your only source for your packet loss figure is some Mlab test that nobody can vouch for. You need to get two endpoints you control and run tests between them to see what's going on.

I'm sat on a leased line, cabled into the network, and Mlab reports 0.17% packet loss which I know just is not true. I don't think any in-browser test can accurately report these sorts of figures.

Here's the actual figures from an application being used on the network, in this case Teams:
rohUKtL.png
 
Last edited:
@Caged - I think their may be a fault with my line, as there's significant packet loss in things like Google Stadia and other game streaming programs on my line.

We know it's not our master socket, as we've recently rewired that to check if the problem is on our end, and we tried the test socket also.

Apparently the connections can be loose / degraded at the street cabinet. Or, maybe there's just a wiring fault in our street.
 
VersionMonkey said:
TCP is a reliable tranport - its purpose is to ensure that every packet arrives and is in the right order. So of course running a tunnel over TCP makes the tunnel more reliable. There's nothing surprising about that at all.
Click to expand...

Tbh, I was surprised that there's a free, unlimited VPN that can be configured in this way, although with no UK server. The speeds aren't bad either, generally around 20mbps for me. Some speed loss, but not that much.

Reliable data transmission has it's merits, a TCP VPN was more reliable than I'd expected, I thought there would be at least some retransmission. I think it depends heavily on the server location and reliability of the servers (maybe server capacity too).
 
Last edited:
g67575 said:
@0007 - I see, I didn't realise you owned these forums :p
Click to expand...

He doesn't but you've been warned before about creating endless, pointless threads and the fact that numerous members are also picking up on it should give you a hint. Try to think and use existing threads if you can.
 
No, because in a video call the most important thing is the latency and not whether tiny amounts of packet loss is present in a codec that *is designed to be able to handle a certain amount of loss*. There is *zero* point in retransmitting lost data from half a second ago because it's not needed any more.

Doing anything inside a TCP tunnel should always result in zero retransmission, that is the entire point of TCP.
 
As noted previously, you really shouldn't run TCP within a TCP tunnel, as you get meltdown. This is why most VPNs use UDP for the tunnel.
 
Hopefully, the packet loss issues on my line have been addressed now. My ISP sent an engineer to check my line and another engineer did some work at my street cabinet. Can't see any changes in line stats, but not getting packet loss in Google Stadia now. Maybe they did something to boost the upstream signal?

I'm guessing that if the connection can handle Stadia / game streaming smoothly, it should be fine for pretty much everything else.
 
Status
Not open for further replies.
Back
Top Bottom