7 ms·
> What I found most interesting, was that there were some use-cases when the network with Wireguard performed even better than without it (probably related to c
by maltalex 8y ago
> What I found most interesting, was that there were some use-cases when the network with Wireguard performed even better than without it (probably related to congestion control).
It could be the different routing.
Your ISP's routing might be sub-optimal to certain destinations. After all, it chooses routes based (at least in part) on cost, not performance.
There are commercial products that do this sort of tunneling (among other things) to lower routing latencies.
- newaccoutnas 8y agoCould also be packet-shaping/QoS on the ISP side
- arendtio 8y agoPossible but I am not exactly sure what caused the difference. I used fast.com for testing and when I increased the number of parallel connections the performance degradation was lower when using Wireguard. I assumed that it is related to congestion control as Wireguard uses UDP AFAIK and otherwise I would use TCP on the bottleneck part of the connection.
- atonse 8y agoThe ISP might be doing it knowing you're connecting to Netflix. But if you do a VPN, they don't know those specific packets are going to Netflix, so they can't shape the packets.
- dboreham 8y agoThey certainly can shape any traffic you cause to transit their network. What you mean is they can't selectively shape that traffic. But then why would they want to do that?
- nitrogen 8y ago"Why" doesn't matter when it has already been proven that they do. Just search through HN for any discussion of net neutrality.
- eximius 8y agoIf they can degrade your traffic from 1080p to 720p without a customer complaining, then they don't need to expand their network to support more users which increases their profit margins. In short, because they can and they're assholes.
- kingosticks 8y agoWouldn't it be appear more performant to queue latency insensitive packets separately to others?
- maltalex 8y agoWireguard might be using UDP, but you're still tunneling TCP on top of it. So the congestion control is still there and kicking.
- Operyl 8y agoThe congestion control is less likely on the server side, whereas congestion control on an ISPs network is much more so.