Which makes competing with them effectively impossible except for a very-few other megacorps.

Most bandwidth is via settlement-free peering with thousands of ISPs around the world. At least that's how we did it at Twitch, and how we did it when I worked at a large CDN before that. There are still costs for backhaul, interconnect, colocation space, dark fiber, network hardware, and transit to fill the gaps. But this talk about how "Google can magically do it 5x cheaper" is nonsense.

Genuine question - aren't those gaps essentially what make a video streaming service operate at scale though? It'd be like saying "ya this bus can get everyone from NYC to Philly at $10 but doesn't stop anywhere in between", or am I missing something about all of those gap filling components?

I've worked at 2 ISPs and we obviously didn't have this peering policy, because it's dumb and it breaks the Internet. We also didn't throttle video, because it's dumb and breaks the Internet.

This is the model for all networks, indeed, most businesses - they pay a big upfront and moderate recurring cost to make a fast network (or restaurant or widget factory) and then sell it in slices with a large freedom to choose a pricing model. Pay per terabyte is a pretty reasonable way to pass on the network's fixed cost to consumers, just like part of the cost of the restaurant meal covers the interior decorations, even though the decorations don't actually cost more the more people eat, until the restaurant gets so busy it needs to expand.

  > For every terabit of bandwidth, you have to physically build out a terabit of network.

So the 'terabit of network' the content provider needs to build need only span a few hundred feet within a single building.

Not all networks are the same. Some have terabit backbones and gigabit edges, some have the reverse. We'd still call both of them, roughly, terabits of network, and you still have to build them. The one with the terabit core might actually be easier because you have less of the expensive really fast equipment.

The only point I wanted to make is that the 'terabit of network' doesn't have to be end to end, so it's not as scary as it may sound.

If you're wondering, if you can't get peering, you wind up like Twitch. In South Korea. South Korean telecom law explicitly shifts the capital expenditure costs of ISPs over to other online services, which is sort of like the fucked-up opposite of Net Neutrality regulation. So Twitch was being bled dry to pay for the chaebols' network expansion. Hell, even after Twitch left, South Korea fined them for leaving!

...is there some reason for Twitch to pay such a fine? Were any grounds stated for it?

> According to Yonhap, the KCC made the decision that Twitch terminating the ability for users in South Korea to access VODs wasn’t necessary to keep the service alive. When asked to justify their claims, Twitch declined due to contractual obligations related to keeping user and site data private.

> Additionally, Twitch would have to present evidence that their decision to gradually take features away from South Korean users & leave the country was necessary. This means that Twitch isn’t likely to return service to South Korea any time soon.

> There’s also a good chance Twitch will be forced to provide refunds for those who have been affected by the service being discontinued, with the KCC warning Twitch that they need to prepare “user protection measures” as they cease service in the country.

https://www.dexerto.com/twitch/south-korea-fines-twitch-over...

95th billing, adaptive, progressive playing and just cap buffer to the minimum to keep playing. Equals ~$1M/month for +10 tbit/s egress.

Source: Worked at one of the largest bandwidth consumers in the world.

Mindgeek? :-)

It's a bit surprising that you were not getting significantly better prices than individuals.

[edit] and that have good deliverability worldwide, no weird paths to other consumer IPs that intermittently fail to route or inexplicably have dial-up transfer speeds. And have anything like a real SLA.

You would think the VMs are the expensive part, but no, egress is easily multiple times the cost of the compute.

You can get 100x cheaper and unmetered at a low cost provider like OVH or hetzner or similar bare metal data centers .

It doesn’t even need significant monthly commits to get that pricing if you are running video streaming at scale you are not running on AWS or even tier 2 like OVH for sure

* up to 2TB per month

* if our upstream is saturated we're going to look at our biggest users and if the number is really big we'll send them a polite email to please reduce it or pay more.

There are reports of people getting emails from Hetzner after sending multiple Gbps continuously for several months. That's the level you have to reach before the * kicks in. Only 1Gbps servers are unmetered, so you'd have to have several.

If you want to know a better approximation of their true cost just look at their non-unlimited plans: 20TB/month included for free; 1€/TB (excl VAT) after that.

I have one more interesting data point to add: I was quoted 950€/month for a dedicated 10Gbps between Berlin and Amsterdam (about 600km) plus peering at AMS-IX, or 300€ for 1Gbps. (They're not secretive and you can just ask for a quote using their sales contact form). Extrapolating, it seems that 1€ is worth about 2.5 petabyte-kilometers, at least within the dense interconnections of continental Europe. About twice the price of shipping a petabyte of hard drives the same distance.

I will point out that this is still about 50x-80x cheaper than Amazon. Not far off the claim of 100x.

Cloudflare and most other Object Storage Providers either fully free egress for all users or at-least for inter-cloud transit so you can then put a free/cheap CDN like Cloudflare in front and not pay all that much for b/w.

AWS refuses to participate. Costs of retrieval of all data plus associated bandwidth is a so high for many people that they stick to S3 including me.

The cloud bandwidth you get on your VPS has nothing to do with costs at the scale where you’ve racks in data centers.

The number above was a thousand dollars per month per 10gbps, and AWS would charge more than a hundred thousand dollars at the listed $0.05/GB price.

Nonetheless it does give a ballpark for the cost of bandwidth being a lot lower than people think. A 10G internet connection would be cheaper to provide in some parts of that equation and more expensive in others - should end up in the same ballpark.

And honestly 10 cents per Mbps sounds kind of high for raw transit, I interpreted it as a price for actual utilization.

Add 10-25% profit for that company to get closer to true "raw transit" pricing from the carriers directly.

But sure, if you want citations for $0.10 per Mbps in bulk for transit, that's easy to find/beat.

https://he.net/ "Get BGP+IPv6+IPv4 for $0.06/Mbps!"

https://www.fdcservers.net/ip-transit Europe, North America: 10Gbps $499/month

And telegeography just sells information, but they had a blog post that's now three years out of date reporting that "In Q2 2021, the lowest 10 GigE prices on offer were at the brink of $0.09 per Mbps per month. The lowest for 100 GigE were $0.06 per Mbps per month."

You need to factor in that your utilization won't be 100%, but if you're comparing 6 cents for a Mbps and and 5 cents for a gigabyte, then the exact point where AWS is 100x more expensive is when your line is 36% utilized.

At even higher scale (YouTube, Facebook or even Netflix ) you are going to be putting content caching servers at the local ISP PoPs : it is mutually beneficial to do so .

It is hard to directly compete on long-form video because of audience and content depth advantage Google has with YouTube.

There are successful niche players who are fairly large (like Vimeo or Twitch or even OnlyFans) who focus on specific markets that don't require social network advantage like corporate or smaller segments etc.

For general purpose media, creators are going to focus on the platform with most audience and vice-versa, very hard to break that.

Jump into a 'bare metal' datacenter and things can get much different.

They'll have to do that eventually, right?

Especially if the amount of content uploaded keeps going up, so the relative benefit of deleting old stuff is small.

I agree. That's why I've recently made a practice of backing up things to which I'd regret permanently losing access.

https://ourworldindata.org/grapher/historical-cost-of-comput...

I have two accounts from my youth with mostly fansubs and "funny" vids. (A "Everybody Draw Mohammed Day"-Video that, 11 years after its upload, got band in Pakistan.) It includes two very successful (over 1M views combined) uploads of political TV shows. I will not log in to this this accounts. So this stuff will get deleted. So in the long run, stuff will disappear from YT.

[1] https://blog.google/technology/safety-security/updating-our-...

Would be nice if they would write that into the actual policy and don't just add a random sentence to a blog post.

However, implementing this in practice is non-trivial. Knowing what is "everyday content" versus what is "once a month content".

To add more complexity -- you have these semi-predictable hype-waves especially two peaks in case of most YT videos where a "once-a-month" content becomes an "everyday" content before again becoming a "once-a-month" content. It feels you could specifically optimise for this -- reduce storage costs without sacrificing UX.

Caching is hard but this sounds like an ARC would likely catch this, if it occurs on a small number of videos concurrently.

After that, you can plunge into colder storages and warm things up as you stream. Additionally, if you need longer to 'defrost' things, just cache a few more MB at the front. Cheat a bit by assuming 480p to start with if you need to; even less to store.

Maybe Google holds your content in 7 data centers round the world (~1 per continent for planned maintenance + latency + reduced oceanic fiber usage).

But with old rarely streamed content they might cut that down to just 3.

The question is whether YT is serving up the one (redundantly-backed storage) copy they have of your almost-never-watched video, or whether it's serving it up from one of 1,000+ copies it's made across the globe for currently popular videos.

My guess is that the first step will be to re-encode all the non-popular videos with severe lossy compression.

You know that because when they release a new format (eg. HDR or a different resolution), they re-encode from the original. Various people have tested that with moire patterns and various other ways to demonstrate if something was encoded more than once.

I suspect that’s Google beginning to trim unprofitable channels using a lot of storage: delete them for bullshit reasons.

Well, there's this:

https://www.microsoft.com/en-us/research/project/project-sil...

This sounds like a good answer, but falls away drastically when you realise the vast majority of consumer of YouTube are outside of the USA, which in turn means so are those bandwidth costs.

Are you guessing or have I missed something here? I can't see how this could be a significant enough factor to make the global model work.