@legacy1 wrote:
If ack suppression being a thing and VM not liking VPN one reason is VM calculate what a VPN packet size is for ack down a tunnel and rate limit them size packets causing low download speed.
This is wrong. It neither does happen this way or can.
Ack suppression has no impact on the speeds of VPN services that use TCP over TCP as all the packets going to remote servers via the VPN will have payloads - has to be something inside each packet for the VPN service to know what you're trying to reach, can't just sent empty acks and expect it to know which flow they refer to.
Any empty acknowledgments are communication between VPN client and VPN endpoint only and are not carrying traffic to remote services.
VM do not rate limit any size of packet. If they started rate limiting small TCP packets they'd break gaming and voice services for starters. The only limitation is the amount of packets per second that may be sent upstream due to the DoCSIS request-grant-transmit cycle, and concatenation helps a ton with this.
Ack suppression on its own doesn't rate limit anything. Going by this post you neither understand it or TCP and shouldn't be posting about it to other customers who may not know better: your technical explanation is, frankly, gobbledegook and completely ignores the basic functionality of both ack suppression and VPNs riding over TCP.
I would suggest it's far more likely the VPNs are riding over UDP and hence taking the 'slow' path through the hub CPU that was put in place to mitigate the Intel chipset bug with DNS. Surfshark by default uses Wireguard, Wireguard uses UDP to avoid the issues that impact TCP over TCP regardless of the access network it's being carried over.