@jennasmith wrote:
QoS: On my side I can prioritize UDP game ports, but like you said, once traffic hits the ISP network it’s out of my control unless they support QoS. Most residential ISPs don’t, so that explains why results are mixed.
Often, where you most want ISP QoS is on their link to you, as that's often a bottleneck.
As an alternative, you can police lower priority inbound ISP traffic to somewhat guarantee your critical traffic always has the bandwidth it needs. In theory, it seems a fine alternative. In practice, your ingress policing is after the traffic has been sent down the link toward you, and as the ingress traffic can burst above the policed bandwidth, it doesn't actually guarantee the bandwidth you want it to, but to insure there is sufficient ingress bandwidth, you have to police at a much higher value to try to slow ingress traffic before it uses your critical bandwidth.
For example, say your ingress bandwidth was 10 Mbps, and you wanted to insure 1 Mbps for gaming traffic, to try to insure that, you may need, and probably will need, to police non gaming traffic higher than 9 Mbps. Possibly much higher. The disadvantage, of course, is you're policing traffic all the time, even when there's no real need to. For example, if you're not running a gaming app, you wouldn't want to police at all. (Actually, with an EEM script, you might be able to conditionally police only when there is gaming traffic.)
@jennasmith wrote:
Different public IPs: Yes, each ISP assigns a separate public IP, and I see exactly what you’re describing — when one ISP fails, game sessions drop because the server only recognizes the old IP.
Exactly! For traffic that doesn't hold an actual session, like some web traffic, such a failure might have no to minimal impact.
@jennasmith wrote:
Same public IP: That would definitely solve the issue, but realistically not possible here. I was actually looking at alternatives like running a VPN tunnel with a single public endpoint. I have seen some discussions in apkdazy gaming communities about using this kind of setup to mask ISP changes and reduce lag. Might be worth experimenting with.
You could certainly try VPN, but I would expect performance to be even worse. First, VPN usually is encrypted, which will add some lag. Second, VPN may cause packet fragmentation, more lag. Third, and perhaps worst of all, if using some VPN server, out on the Internet, you have the additional transit time to/from that site, which is unlikely, to be "in line" with the direct transit path between your client and the game server. (I.e. rather than client<>game-server, client<>VPN-server<>game-server.) Fourth, although the game server will see one IP, the VPN tunnel will likely see your ISP public IP, which negates the whole point. (Usually, the point of using a VPN, is to keep secret your traffic between you and the VPN server. Like, if the ISP were to block some specific traffic, such traffic wouldn't be visible to the ISP, unless VPN server was in the ISP network.)
