Why you can’t solve an internet problem with a broadcast mindset, and why copying without understanding always fails. – By founder Stef van der Ziel.

In 2010 I gave a presentation at a telecom conference. The speaker before me was Cisco, a major vendor building CDN edge sites with complex, expensive appliances. A million euros per zone, without any overarching management software. My presentation that followed was titled: “The appliance is dead.”

We had just developed our Video Exchange platform. A control plane on top of a streaming data plane, both running on standard hardware with a standard software stack. Multi-tenant, multi-vendor, multi-pipeline, multi-workflow, centrally managed. Internet first, without broadcast legacy. The intelligence lived in the software, which meant the delivery layer could be built with cheap, generic hardware. A fraction of the cost. A disruptively different approach. An internet approach, not a broadcasting approach.

Half the room, the operators, loved it. The other half, the hardware vendors, went pale. They saw their business model of wildly expensive appliances evaporate before their eyes.

Jumbo frames

Not long after, through a mutual telecom partner, we ended up in a project with one of those appliance builders, a Swedish one. Their edge servers, primarily designed for digital cable television, were to become part of our stack and suddenly had to do internet streaming as well. They couldn’t pull it off. The servers simply couldn’t get a connection to the outside world working.

We stepped in to help debug, and then the problem surfaced: their TCP stack was hardwired for jumbo frames.

For those who don’t work with networks daily: jumbo frames work fine in a closed, fully controlled chain. On the open internet, they don’t work. And that is exactly the point. This wasn’t a bug, it was a worldview, cast in code.

Traditional broadcast engineering assumes a rigid chain that you control from end to end. Fixed bitrates, predictable timing, known equipment, constant conditions. The internet is the exact opposite: dynamic, unpredictable, heterogeneous and messy. Those who build for the internet build for variation. Those who think broadcast build for perfection and break at the first deviation.

They had to rebuild their entire system from the core up. And because they had no knowledge of internet streaming and caching, we built those applications into their product for them. Our platform was already architected so that any arbitrary edge could run in a mix. To us, their server was simply one of many flavors.

The thundering herd

In the early days of HLS live streaming, virtually everyone ran into the same problem, except almost nobody had noticed it yet. We called this the thundering herd problem. With live streaming, all viewers request the newest manifest and the newest chunks at virtually the same moment. That by definition means a cache miss, and a classic cache then forwards all requests to the origin. The origin collapses under the load, so the stream goes down. Caching, the entire reason you build or use a CDN to offload the origin and scale up traffic, simply doesn’t work.

Because we were among the first to work with live HLS, we spotted this immediately and built a solution for open source caches: hold all identical requests, forward exactly one to the origin, and fork the response out to all waiting requesters. Problem solved. Today, request coalescing is a standard feature in modern caches. Back then it was unique, and it gave us a major head start.

We shared that technique under strict agreements with that Swedish partner, exclusively for joint projects, and under NDA. Not much later, that same partner presented the technique at a conference. As their own unique invention. Shame on them. End of partnership.

Copying without understanding

You can copy a feature. You can rebuild a demo. You can even put an entire team of interns on a clone, because we saw that happen too with those Swedes. You can try to rebuild something with AI. But what you cannot copy is the understanding from which that feature emerged.

Those who never saw the thundering herd coming don’t understand why the solution works and where the edge cases lie. Those who hardwire their TCP stack to jumbo frames haven’t made a single mistake; they think structurally wrong about the medium they are building for. Such parties are always one problem behind. They solve what we already solved earlier, and in the future they will break on what we are solving today.

We still see that pattern sixteen years later. There are still platforms on the market that were designed from a broadcast mindset, even though they implement adaptive internet streaming. They anchor their logic to assumptions about perfect, rigid input. They work fine in the demo and in a controlled acceptance environment, and they become unstable the moment the real world walks in with external sources, real timing jitter and real network conditions. Exactly like that edge server that couldn’t get internet working back in 2010.

Building for the messy reality

Our philosophy hasn’t changed since 1994. Assume input is imperfect. Assume networks stutter. Assume that tomorrow a protocol, a codec or a device will appear that doesn’t exist today. Assume that later on you will have to work with new external encoders, packagers, origins and CDNs. Build your intelligence into the software, keep your hardware generic, and design your architecture so that every component is replaceable, instead of a black box that works internally but breaks the moment you have to integrate. Because that too belongs in a digitally sovereign world.

That is not a feature you can copy. That is a mindset. And you only earn it by encountering the problems first, understanding them first, and solving them first.

The appliance is dead. The rigid chain is dead. Those who want to serve the internet must think internet.

Jet-Stream. Sovereign, sustainable, accessible. Pioneers since 1994.

Go back to see all blogposts