August 27, 2012

∴ How Apple's TV Box Might Work

We’ve been kicking around the idea of an Apple Television since Steve Jobs' biographer wrote that the Apple boss had “finally cracked” how to improve TV content delivery. It was a tantalizing idea for a future Apple product, but no-one has yet come up with actual design or implementation details. It’s the implementation that’ll make Apple’s product unique, revolutionary and disruptive.

The new Apple product will revolve, I think, around a little-known, little-used network technology called IP Multicast. It’s been around as long as the Internet Protocol, but most Internet users have never heard of it because so little has been done with it.

Most Internet communication occurs when a client connects to a server, requests data, and disconnects. Browse the web, check your email or stream a movie and you’re connecting your client machine and software to a server somewhere, retrieving data and closing the connection. It works well as far as it goes, but it doesn’t scale very well.

Recall what happened when Victoria’s Secret staged their first online “fashion show.” Their servers were immediately drowned in stream requests, and few users were able to watch the lingerie parade. We even have words for this sort of thing: John Gruber routinely Fireballs sites with his attention.

Service providers have created work-arounds for this kind of problem, often moving content to multiple servers or contracting with companies like Akamai to carry their content on hundreds of servers located around the world. Either way users are better served, but the original problem still exists. Client-server doesn’t cleanly scale beyond a few hundred users.

Enter IP Multicast, which turns the problem on its head. Rather than waiting for client connections, the server streams its content connectionless on one of many multicast addresses. This block of addresses, set aside by the IPv4 and IPv6 standards, is available for clients to listen in on.

You can join millions, even billions of others watching the big game If your client software listens in on the Super Bowl audio/video stream, without a network traffic jam in sight. The server only sees the one multicast address it’s broadcasting to, so its load is very light.

The trouble with multicasting is that there's little incentive to use it. Internet backbone routers aren’t configured to route it. Client software isn’t coded to make use of it. And no-one makes money when content is floating through the ether, free for the taking.

Enter the modern Internet Service Provider. Let’s use Comcast as an example. That company, the largest US cable TV and Internet provider, has aggressively rolled out IPv6 across their entire footprint recently. The routers within their corner of the Internet are theirs, so routing multicast packets is under their control rather than a committee of backbone providers. And they already have carriage agreements in place to convey all the TV content customers care about.

I’m speculating, but here’s how the whole thing might work.

Let’s say you want to become a “Comcast IPTV” customer, using a new or existing Apple TV 2 or 3. Those iOS-based devices are critical to the solution, because they’ll allow customers to download apps from an Apple TV App Store, among them the Comcast app. Signup will be handled within the app, and payment will flow through an iTunes account.

Once authorized, the customer is presented with a program guide of all Comcast-carried content currently available in their area. Network channels, “cable” tiers, pay-for movie channels, sports channels are all available through the Comcast app via IP multicast, one channel per multicast address. The customer selects a channel, the app “tunes” to the appropriate address and content appears.

There’s no need for DVR capability; content is stored in Comcast or iCloud cloud storage as it's broadcast and delivered on-demand when requested. The customer who “records” favorite programs for later playback is simply subscribing to that content as he might a podcast.

The much-maligned Apple podcast app takes on a more interesting aspect, now.

This scheme only works because

  1. Comcast controls the content and  the network, allowing them to keep programming within their IP network by properly configuring internal routers,
  2. the Comcast app only functions for properly authorized customers, so there’s no free riding (adding an encryption layer to the codec further improves security),
  3. the H.264 codec is efficient enough to handle the data, and the recently unveiled H.265 codec halves the necessary bandwidth again, and
  4. Comcast permits content flow without counting it against their per-customer service caps.

In short, the service provider is in control of the entire data path, so revenue is assured. Eventually Comcast moves all of their television customers off traditional coax-delivered content and onto IPTV. Their triple-play package becomes IP-only.

Everyone wins: Comcast makes equivalent revenue while moving customers to a newer, more modern and flexible medium; Apple sells several boatloads of Apple TV 3s (and beyond) as they become the exclusive provider of the new Comcast IPTV “set-top boxes,” and customers get a more flexible means of watching TV content with a better and more intuitive Apple-designed UI.

I believe that's how Steve cracked it.

No comments:

Post a Comment

Above all, follow Wheaton's Law: don't be a dick.