I don't know how things currently are, but YouTube was a mess.

I worked for an ISP (in Russia), and in the early 2010s, we had quite a lot of complaints about YT videos buffering. We've checked our network very carefully and found no signs of any trouble. And we've confirmed issues and were able to reproduce them even when the network was least busy. We've tried to re-route traffic via different uplinks, even messed with the DNS records a little bit (I admit this grave sin) - sometimes with some temporary improvement effect, but mostly to no avail. And of course, we've talked a lot to our peers. This was quite a major headache, and we were out of ideas what else we could do (we weren't anywhere large enough to get a Google Global Cache server). Then Google did something (IIRC, mid-2012), and we've stopped getting the complaints.

With VPN you're probably hitting different YouTube servers. I guess we should've tried to route via some VPNs too, not just physical peerings we had. Never occurred to us at that time.

I left that company in 2015. Don't know how things are now.

My point is, even without a malicious intent sometimes things look the way you describe.

I do remember someone mentioning at some point that most video codecs were never intended for realtime streaming. That was in a blurb for a new video codec intended for streaming though, iirc in the context of video conferencing. Might be related, I'm not sure.

It's not related. Companies like Youtube and Google don't do real-time encoding of their video streams, they encode "offline" (= prior) and stream the already-encoded video many times. So real-time'ness of video codecs is not relevant to this topic.

In that context it was because most video algorithms are designed to chunk, which reduces bandwidth at the cost of increasing latency. That's a good trade off for Youtube, but not as good in a real time scenario like video conferencing.

The first example is more likely congestion than throttling, but that's only really a difference in the manner that your ISP is being cheap (and not having enough bandwidth upstream).

Using a VPN in this case is probably causing your traffic to take a different route than everyone else's youtube traffic, thus avoiding the congestion bottleneck.

Netflix may have a local cache nearer to you, so you don't hit the congestion (and the amount of content in a Netflix cache is probably a lot less than Youtube).

Example 2 could be a packet-lossy network which causes your TCP connection to ramp back. If it's constant packet loss, your TCP connection will probably get slower and slower: TCP uses packet loss as a signal it's going too fast, but if that's not the cause of the loss, your connection will just keep getting slower.

> but that's only really a difference in the manner that your ISP is being cheap

Doesn't that depend on the peering agreements? How do you know it isn't the case that problem at the links isn't due to the video service paying for insufficient bandwidth?

Where the bottleneck exists is difficult to pinpoint, for sure. Especially just based on a vague description. I'm making some assumptions.

Isn't TCP a lossless protocol? I thought it ended the session if the packets were dropped.

Edit: downvoted for asking a question. Thanks reddit.

Whenever you send a packet in TCP, the recipient sends back an "ACK" packet confirming receipt. If some timeout interval passes, the packet will be sent again. This means that some packet loss will not interfere with a TCP connection.

This is used for congestion control: Imagine you have a computer with a 1gbps LAN hooked up to a 100mbps network. You can send packets at 1gpbs over the LAN, but 90% of them would be dropped at the speed change point. The TCP stack will notice it is losing packets, and will throttle itself accordingly.

TCP is actually more complicated than just this, but this is one of the more important parts.

Packets can be dropped and TCP will retry (among other things; packet loss is a hueristic.) It won't just cut the session on some amount of packet loss, that would lead to constant failures.

Can you name the guilty for your fellow Aussies? Also Netflix might be better / not throttled due to their OpenConnect program which would be saving the ISP traffic https://openconnect.netflix.com/en/

Netflix will always be much, much faster because there is a peering box inside your ISPs network. So when you are watching a movie it's only pulling the data from somewhere geographically pretty close to you.

Google has peering boxes too.

But at Netflix' scale? I mean Netflix has a relatively fixed offering, something that will fit in a unit in a datacenter with content updates at most once a week, whereas Youtube gets 500 hours of video uploaded every minute.

Generally you are going to connect to Netflix or Google and then it is up to them how they serve their traffic. Presumably only a small percentage of YouTube videos gets a lot of the traffic. They could even control that by which videos gets suggested. Which would be my personal theory why Google search results have arguably been getting worse. Because they seemingly have a lot of incentive, both in terms of load and ads, to serve the same things to many people.

Sure, but if you don't share the taste for mass pop culture (which, as a HNer, are unlikely to), then you'll never hit the peerbox cache.

Netflix small fixed library is significantly better for cache hits.

It generally doesn't matter that much. If you miss the cache you are going to hit Google's network, which will serve from their own data center over their own networks. That mostly isn't paid for by the ISP, but Google's customers. The problem with wireless is that the wireless part isn't Google's network nor "fixed" infrastructure. So it becomes costly for the ISP.

Wireless towers are fixed to the ground just like the fiber they rely on for internet connectivity.

Google and Netflix peering boxes mean that ISPs with peering boxes at the same peering point can download as much as they want, within reason, for free from that peering box.

You might be confusing CDNs with peering boxes. As might I.

It's also testing network speed and will adjust quality on the fly to the user.

At home I used Centurylink's "home" class of their DSL connection. At work we had Centurylink's dedicated ethernet connection. I could never really watch youtube at home because it would pause, buffer, play 5 seconds, buffer, etc. Once I VPN'd into work (which was 2 miles away) I could watch youtube without issues.

I'm sure it's a technical issue or something, but that is my experience with Centurylink and Youtube.

Now I use Verizon and only have issues with youtube when it's "congested."

It could also be that your ISP has a Netflix cache server but not Google's (or vice versa.)

My anecdote doesn't quite explain the symptoms you had, but as an Optus customer I would find terrible download speeds correlated with Sea-Me-We3 being damaged. Local sites or content cached in Australia performed fine (for obvious reasons).

Recently it seems it gets damaged every four months or so. [1]

[1] https://en.wikipedia.org/wiki/SEA-ME-WE_3#Service_disruption...

If you're on Optus cable it could also be that they have let the network fall into disrepair due to the NBN eventually replacing it

Optus was (and probably is still) slow, but extra slow at the times SMW3 was broken.

I have discovered that Stan (Australian Netflix competitor) tends to stream a lot more reliably than Youtube and adult streaming sites.

It could also be bad peering / routing.