*Technically some ISPs can (and probably do) look at the ServerNameIndication to determine hostname and therefore whether they’re video flows or not, but I’ve not heard any real world examples of this being done.
IIRC, it's now called ECH, because AFAIK the focus changed from "encrypt the SNI" to "encrypt the whole Client Hello".
By doing that, they can get a good estimate of your connections available bandwidth, which is needed for the decision whether to automatically switch to a higher/lower quality feed.
It also means they can use 'dumb' servers which don't do any application-specific logic for throttling.
(The issue is not the router, though - this doesn't happen on my laptop. I think my phone is just more aggressive in assuming the Wi-Fi is down and it's better to switch to cellular. But couple that with my phone's policy to use VPN on cellular, and the switch becomes much higher friction. I tried simply disabling cellular data, but then it's even worse because every time the phone disconnects from Wi-Fi it pops an alert telling me to enable cellular data.)
Snooping like this is EXACTLY why we still have unencrypted ServerNameIndication, even to this day in ECH (which still leaves the outer SNI in the clear).
You really don't when every modern browser sends SNI, which exposes the full domain name it's trying to connect to.
Many browsers these days support using DoH without changing any OS settings.
And ECH will still reveal the outer SNI, apparently.
The burst mechanism of your provider possibly squeezes below your normal speed to compensate for the burst, but ends up confusing TCP flow.
Those burst and squeeze cycles can cause some undesirable bandwidth oscillations.
Say you're bursting 1gbps on a connection with 100ms latency. That connection squeezes to 20mbps suddenly. In the best case in those 100ms that the sender cannot even react to the change, we receive 10mbytes. Those 10mbytes that now have to be throttled away either get dropped or end up in a buffer. Now you either have a 5 second backlog latency or massive packet loss for 100ms while this resolves. And things overcompensate. And worst case, you end up in a oscillation pattern, the throttle goes off, and you burst again.
This happens and is measurable.
Anyway, annoying… at least http supports resuming, so it is possible to kill and restart manually, or use aria2c to circumvent it.
The trick is just to do your own rate limiting without burst at the right limit, that bypasses whatever shitty burst implementation your ISP modem has and weird shit won't happen anymore.
This is a pretty standard feature of DOCSIS, I believe. It allows bursting above the provisioned connection speed for a few seconds when there's capacity on the shared network segment.
Most ISPs don't have one fat pipe to this magical "internet" place, they have multiple pipes going different places and not all of them are even listed in peeringdb, so their route to a particular CDN might be over private peering which is limited in size (e.g. 1-10Gb). Sure, then excess traffic might go over public peering but that might also then get saturated, or the ISP might force traffic over the private peering to keep the public peering clear for general traffic.
If you use a VPN then the traffic will come from a different route and different peering, thus be subject to the capacity of that route. What the OP probably wants is for Zen to have better peering with Akamai (they already have some announced routes).
They try to limit bandwidth to video sites, but since most video traffic is transferred by HTTPS these days they end up just making a massive list of IP's which look like they might be sending video data and dropping some percentage of traffic to those IP's. Most CDN's are probably on the list.
End result is most video sites drop back to SD rather than HD.
If you do a speedtest, it will come out as fast. If you VPN, that will also be fast.
The IP range has nothing todo with it - it is the route the packets traverse and what the packets look like when they pass the shaper device that matters.
You could theoretically find out which device on the path is doing the dropping by manipulating the TTL of packets in a live TCP session and seeing when you get back TTL exceeded messages.