TLDR is at the bottom.
A few months ago I upgraded my router and in the process of setting up OpenWRT on it and for the first time I enabled IPv6 along with IPv4.
I expected lower jitter under load as a result of the upgrade but the improvement was lower than what I expected and after looking into it I learned about bufferbloat and that SQM could fix it.
Setting up SQM did improve performance but the cost in terms of bandwidth was higher than expected. So, after a few weeks when I looked into again, I realized that I missed a couple of settings that improved performance and reduced the bandwidth requirement but the performance was inconsistent.
I also started observing some packet loss. This was never an issue when I was using the older router so my instinct was that it was due to SQM.
After a lot of troubleshooting it turned out to not be SQM and I verified it by disabling SQM completely.
It was because I had enabled IPv6. The solution to this Steam forum post suggested disabling it as a fix but disabling it (through Windows) in the device running Steam did not fix it for me but disabling it in the router did.
I am still not sure why having IPv6 enabled was causing packet loss. Maybe one of the very knowledgeable people here can explain the cause and the fix. If not I will try to update the post with the cause and the fix when I get around to it.
TLDR: Enabling IPv6 in the router can cause packet loss when under load. Disabling it in the router settings and just using IPv4 is a workaround.
Sounds like a problem with your ISP
I believe so too. I will verify it and update the post.
I have confirmed that it's a problem with the ISP because the IPv6 traffic is being tunneled over IPv4.
I would not be amazed if that would be an MTU issue... if the tunnel MTU is not large enough full sized IPv6 packets might cause IPv4 fragmentation to happen and small fragments "eat" a lot of capacity... which might cause a higher network load that then might trigger the ISP's traffic shaper... a test would be to enable IPv6 again (for the testing) and then install tracepath (I believe apk update ; apk add iputils-tracepath) and run it fir both IPv4 and IPv6:
tracepath -4 www.google.com
tracepath -6 www.google.com
And then post the results here.
I am currently using a Windows machine so I used ping to figure out what the MTU by testing a few values. The IPv6 MTU is 1444 and the IPv6 MTU is 1464. I used these commands: ping google.com -6 -l 1444 and ping google.com -f -l 1464.
So here is the challenge, this will detect fragmentation within IPv4 and IPv6, but if the fragmentation only happens in the outer IPv4 tunnel it is possible that the IPv6 packet's do not fragment flag is simply not evaluated and honored...
I can not say if tracepath is better under these conditions, but it certainly is worth a try and you can install and run it on the OpenWrt router itself (you know how to log into the router via ssh over a terminal, I assume).
I ran the commands on the router and these are the outputs:
root@OpenWrt:~# tracepath -4 www.google.com
1?: [LOCALHOST] pmtu 1492
root@OpenWrt:~# tracepath -6 www.google.com
1?: [LOCALHOST] 0.068ms pmtu 1492
Would the whole output help? It was mostly just no entries until 30 hops and then this message:
Too many hops: pmtu 1492
Resume: pmtu 1492
Mmmh, this is unfortunately not showing what I expected... so given your IPv6 is tunneled through IPv4 we still need to figure out how this deals with real MTU...
I did the setup for IPv6 from scratch and this time it seems to be a lot more stable. I am not sure what the issue was last time. I will update the post if I face the problem again or figure out what was the cause.
The comment about IPv6 traffic is not being being tunneled over IPv4 may not be accurate given the pMTU for IPv6 is 1492.