Possible 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.
Wireguard might be using UDP, but you're still tunneling TCP on top of it. So the congestion control is still there and kicking.
The congestion control is less likely on the server side, whereas congestion control on an ISPs network is much more so.
The 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.
They 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?
If 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.
"Why" doesn't matter when it has already been proven that they do.
Just search through HN for any discussion of net neutrality.
Re:Warp – Mobile VPN
by kingosticks on Tuesday April 02, 2019 @04:35AM
(#19552124)
Wouldn't it be appear more performant to queue latency insensitive packets separately to others?
Re:Warp – Mobile VPN
by newaccoutnas on Monday April 01, 2019 @11:22AM
(#19544253)
Could also be packet-shaping/QoS on the ISP side
Sure. Especially in countries that don't have network neutrality...
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.