I think this is just what you see with typical ISP "traffic shapers".<p>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.<p>End result is most video sites drop back to SD rather than HD.<p>If you do a speedtest, it will come out as fast. If you VPN, that will also be fast.<p>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.<p>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.
You might want to consider switching from Zen to AAISP[1].<p>Zen used to be decent, now pretty much only the only residential ISP left that offers quality support is AAISP. They also have all sorts of stats monitoring[2] on all customer lines by default, which they expose to customers on the portal.<p>AAISP will also, unlike many ISPs, not shy away from giving Openscreech a strong poke with a very sharp stick if the underlying issue with your line is due to Openreach. They know how to play the BT game.<p>No affiliation with AAISP other than knowing a number of their customers, not a customer myself due to completely unrelated reasons which are entirely beyond their control.<p>They are not the cheapest ISP in town, but it very much is a case of you get what you pay for.<p>[1]<a href="https://www.aa.net.uk/" rel="nofollow noreferrer">https://www.aa.net.uk/</a>
[2]<a href="https://support.aa.net.uk/Category:Diagnostic_Tools" rel="nofollow noreferrer">https://support.aa.net.uk/Category:Diagnostic_Tools</a>
This behavior would be fully explained if the Akamai <-> Zen interconnect is simply overloaded.<p>Internet connectivity is not transitive, throwing a VPN into the mix changes the A <-> B scenario to A <-> C <-> B, which can have <i>very</i> different properties, since the paths may have very little in common. For multihomed A and B, the paths may in fact have nothing in common at all.<p>Same applies to IPv4 vs. IPv6, the routing may be entirely different, especially with a CDN you might even straight up get a different CDN instance.
I had an issue recently where my Spotify playback kept pausing due to being unable to download the songs quickly enough on my 75Mbps fiber connection.<p>My ISP has a strong presence on a local forum where I posted my issue.<p>Long story short, despite my ISP actually having an Akamai cluster on their own network, Akamai’s DNS was resolving my ISP’s customers to a cluster on a different ISP’s network.<p>That different ISP either had terrible peering, or the theory is they were throttling their Akamai cluster’s IPs to other ISPs.<p>Fortunately my ISP managed to convince Akamai to fix the DNS resolution.<p>Needless to say, I’m super impressed I can actually get the attention of the right people at my ISP to resolve this kind of issue.
Just curious if MSS or PMTU blocking has anything to do with the problem.<p>In the 2 different Wireshark dumps, a relevant difference is MSS=1460 and MSS=1380 in the second one.<p>I'd recommend setting the local NIC MTU to a low value just to see if it has an impact. However, the Wireshark dump doesn't show packet fragmentation, so perhaps this isn't a problem at all?
So I have seen this before - a lot of ISPs now days are using "optimiser" boxes that are designed to throttle Elephant Flows (<a href="https://en.wikipedia.org/wiki/Elephant_flow" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Elephant_flow</a>) to reduce overall consumption. Usually they add a little bit of buffering or the occasional TCP congestion notification to cause a client to back-off and (for example), reduce the streaming video bitrate. But I've also seen bad configuration that can cause this sort of issue - e.g. an mis-configuration that limits you to 2kbps vs 2mbps. The reason the Wireguard tunnel works fine is because it's UDP-based and you can't trigger the same congestion notification behaviour over UDP. These boxes are usually inline to your traffic and are often referred to as "middle-boxes" - more commonly they're used in mobile (4G/5G) RAN aggregation networks where bandwidth is more scarce but they're now being sold into fix-line network providers as a cost-cutting measure.
Looks like net neutrality is going down the shitter. Except it's not the way ISPs would have originally wanted, with CDNs taking stewardship of what's allowed and what's not.
HN's hug of death<p><a href="https://web.archive.org/web/20231123142332/https://blog.abctaylor.com/how-i-discovered-caching-cdns-were-throttling-my-everyday-browsing/" rel="nofollow noreferrer">https://web.archive.org/web/20231123142332/https://blog.abct...</a><p>Funny thing is the author apparently doesn't use the caching CDN, thus users are not getting throttled but having 503...
<a href="https://web.archive.org/web/20231123121535/https://blog.abctaylor.com/how-i-discovered-caching-cdns-were-throttling-my-everyday-browsing/" rel="nofollow noreferrer">https://web.archive.org/web/20231123121535/https://blog.abct...</a><p>In case anyone else wants to read it while it's hugged to death.
I’m with zen. This lines up with my experience. Time to move to AA.<p>Except farnell.com which is shit everywhere because their entire platform is a turd.
I had a weird one on my network I never managed to solve before I moved:<p>I had symmetrical 1gbps up and down. When wired, I could get nearly the full amount on the WAN. When wireless, I could only get 300mbps to the WAN.<p>However, when wireless, I could get ~800mbps to another device on the LAN. I could also get 800mbps to the internet if I proxied from my wireless devices to my wired device before going to the WAN.<p>My router company sent me two additional routers, one with a similar chipset and one with a chipset from a different vendor and this persisted. I checked it with a competing router and it persisted.<p>It did not matter what the wireless device was, Mac, windows, phones, or tablets, and it persisted.<p>Moved somewhere else with a different ISP and it immediately stopped. I still don’t know how an ISP would identify and throttle a wireless device, but that was pretty much the only explanation I could come up with.
I got blacklisted by Akamai once for some very lightweight automation of web page screenshots (once every ~5 seconds, different sites). Do not recommend the experience.<p>The ironic thing was I was blacklisted from loading Akamai's help pages about what to do if you are blacklisted. I never did find their tool, I wonder if it would have been blocked too. <a href="https://www.akamai.com/us/en/clientrep-lookup/" rel="nofollow noreferrer">https://www.akamai.com/us/en/clientrep-lookup/</a><p>The ban expired after about 3 days.
You should look into image optimization, especially when you are self hosting. Use thumbnails for big images, webp looks decent enough and files are smaller than png. Prefer system fonts - why should you serve those too, when each visitor usually have dozens of them available on their device already? Oh, and favicon really can be smaller.
I had a problem with Zen recently-ish too. Ultimately was an Openreach thing at the local exchange apparently. The good Zen support was still ultimately there, but it took a little time for things to fall into place. Standard L1 checklist inflation. Thankfully though Zen are one of the few ISPs where I felt like it was worth it to send packet traces because a decent chunk of folks there would know what they are.<p>On the other hand, I think any ISP at the mercy of openreach is doomed to have limited support.<p>I have fibre to the property, and was having periods of 1hr-2hr day of my gigabit speeds dropping to 4-5MB. openreach themselves were blindly sending engineers to look for an issue that couldn’t physically be at my house.<p>Not much you can do there either as an ISP or as a customer besides wait for openreach to figure out they’re wasting their own time
How odd, I'm also with Zen, albeit on 900/100 FTTP and have no such issues, but then again, I also have a /48 IPv6 prefix delegation and so whatever wants to use IPv6 uses that.<p>BBC, Farnell, everything else - just works, and works fast.
I guess that there is a congestion somewhere in the path, maybe between your ISP and CDN.
I have been worked in an ISP for a while and this was the root cause of problems like yours.
I'm with Zen and have a good experience over the last few years, one of the only companies where customer service has been decent - when I was on ADSL the fault finder on their router helped identify a nearby a problem, once BT openreach replaced the cable connectivity was really good, probably would have been given the runaround by another provider and had to live with a flakey connection.
Where is the discovery though? I don't follow how you got to the point where you think it's CDN's that are throttling you. For all I know it could be something like a faulty router, right?
>> Stable 6ms ping to 1.1.1.1<p>Please note, pinging public DNS servers is a useless metric, because you would never know if your provider hijacks your DNS packets or even all traffic to those public servers.
I doubt it is a global throttling by an IP address. The most common reason is ISP traffic shaping and ISP ingress/egress deals with the networks it is connected to.
Why don't you setup IPv6 if that solves the problem for IPv6 enabled sites?<p>You also seem to know your way around networking as well, genuinely curious.