People are excited about online TV getting big in 2016. Alon Maor of Qwilt predicts in Multichannel News that this will be “the year of the skinny bundle.” Wired echoes that sentiment. The Wall Street Journal’s Geoffrey A. Fowler said, “it’s no longer the technology that holds back cable cutting–it’s the lawyers.”

Well, I’m here to say, lawyers can’t take all the blame. In my experience, it’s the technology, too. Some of the problem is that most discussion about the future of online TV and cable cutting fails to distinguish streaming video-on-demand (SVOD) and streaming linear TV (“linear” means continuous pre-programmed and live “channels”, often with commercials, much like traditional cable).

SVOD includes Netflix, HBO Go, and Hulu. Yes, SVOD technology is very good. The major SVOD players spend millions on networks and caching so that their (static) content is as close to consumers as possible.

But streaming linear TV–like Sling and live sports–cannot be cached like static content and appears to have kinks to iron out before mass-market adoption. Read online video analysts and you realize that streaming linear and live TV online is an entirely different animal from SVOD. In August, Ben Popper at the Verge had a fascinating longform piece about the MLB’s streaming TV operation, Major League Baseball Advanced Media (BAM), which is the industry leader doing live streaming video. (HBO hired BAM for streaming the latest Game of Thrones season after HBO Go’s in-house streaming offering suffered from outages.)

Linear online TV is hard! As one BAM executive explains vividly,

What people forget is that the internet, as a technology was never designed to do something like this–deliver flawless video simultaneously to millions of people. I liken it to trying to live on Mercury. The planet is completely inhospitable. Every day all you’re doing is [fighting] a battle for survival in a place that really does not want you.

So I say this understanding the significant technical difficulties they face: in my experience, streaming linear TV is not ready for prime-time yet. (If I could find information about how firms do it, I would also distinguish pre-recorded linear TV–like Sling’s HGTV channel–from live online TV, because firms likely use different network topologies. Another time, perhaps.) Perhaps I’m an outlier, but media reports about Sling outages suggest that I’m not. I used Sling TV for the past few months and had high hopes but I just dropped my subscription. My test for acceptable streaming quality is: “Would I invite friends over to watch something using this streaming service?” Most SVOD services pass that test. Through caching and streaming protocols, SVOD operators can assure pretty consistent streaming even during times of moderate congestion.

Since linear TV typically has programming that is transmitted (nearly) live, operators can’t really do the distributed caching of content that makes SVOD function well. As a result, streaming linear TV like Sling TV and WatchESPN (a Sling subscription gives you access to ESPN’s online sports portal) currently do not pass my test. Frankly, the streaming quality varied from excellent to unwatchable. Punching into the app and casting it to my TV, I was never sure which Sling would show up that day: Good Sling or Bad Sling. On good days, the Monday Night Football game looked better than cable TV. Other days, the stream would, for instance, work well and then fail at every commercial break (perhaps the commercials were stored on another, overwhelmed server?).

Now, it’s impossible to know for sure where the network bottleneck is and why a video stream is stuttering. To be more certain that the problem was with Sling TV or WatchESPN and not, say, my Chromecast, my Wifi, or my ISP, every time Sling or WatchESPN had several severe streaming problems in a period of short time, I did an unscientific test. I would close down the Sling app, open up Netflix, and start streaming Netflix via my Chromecast. Without exception for the past three months, Netflix loaded quickly and streamed well. Keeping everything the same except the source of content suggests (but doesn’t prove) that the problem was not a local network or device problem.

There are ways of using network architecture and protocols to improve linear TV on broadband, typically with dedicated servers and last-mile bandwidth reservation. Comcast Stream TV is an example and LTE Broadcast might someday soon provide linear and live TV for mobile customers. But given so-called net neutrality rules, these services are controversial and regulated. ISPs can have their own proprietary TV service like Stream TV but, given net neutrality hysteria, probably won’t offer dedicated bandwidth to distributors like Sling. In this narrow area, the FCC’s rules are a pretty good deal for larger, vertically integrated firms that can put programming bundles together. It’s not so great for the small ISPs and WISPs who want to respond to cable cutter demands and offer a quality TV product from another company via broadband.

So I expect linear online TV to remain niche until the quality improves. A big draw of Sling is the cancel-at-any-time policy which lowers the risk if you’re dissatisfied with programming and allows single-season sports fans like me to subscribe for a season or two. I subscribed in the fall and winter to watch NCAA and NFL football. Sling recognizes that a lot of its subscribers are like me. But if Sling and other linear TV programmers want to expand beyond niche, they’ll need higher-quality streams. (And Sling might wish to remain niche so they don’t upset their programmers by cannibalizing traditional subscription TV.) Would I sign up for Sling again? Sure. Maybe the prognosticators are right, and the technology will develop rapidly in 2016. I have my doubts.

“Net neutrality is a dead man walking,” Marvin Ammori stated in Wired last week, citing the probable demise of the FCC’s Open Internet rules in court. I’d agree for a different reason. Net neutrality has been dead ever since the FCC released its net neutrality order in December 2010. (This is not to say the damaging rules should be upheld by the DC Circuit. For many reasons, the Order should be struck down.) I agree with Ammori because we already have the Internet “fast lane” many net neutrality proponents wanted to prevent. Since that goal is precluded, all the rules do is hang Damocles’ Sword over ISPs regarding traffic management.

The 2010 rules managed to make both sides unhappy. The ISPs face severe penalties if three FCC commissioners believe ISP network management practices “unreasonably discriminate” against certain traffic. Public interest groups, on the other hand, were dissatisfied because they wanted ISPs reclassified as common carriers to prevent deep-pocketed content creators from allying with ISPs to create an Internet “fast lane” for some companies, relegating most other websites to the so-called “winding dirt road” of the public Internet.

Proponents emphasize different goals of net neutrality (to the point–many argue–it’s hard to discern what the term means). But if preventing the creation of a fast lane is the main goal of net neutrality, it’s dead already. Consider two popularly-cited net neutrality “violations” that do not violate the Open Internet Order: Netflix’ Open Connect program and Comcast not counting its Xfinity video-on-demand (VOD) service against customers’ data limits

Both cases involve the creation of a fast lane for certain content and activists rail against them. Both cases also involve network practices expressly exempted from net neutrality regulations. The FCC exempted these sorts of services because they are important, benefit the public, and should be encouraged. With Open Connect, Netflix scatters its many servers across the country closer to households, which allows its content to stream at a higher quality than most other video sites. Comcast gives its Xfinity VOD fast-lane treatment as well, which is completely legal since VOD from a cable company is a “specialized service” exempt from the rules.

“Specialized service” needs some explanation since it’s a novel concept from the FCC order. The net neutrality rules distinguish between “broadband Internet access service” (BIAS)–to which the regulations apply–and specialized (or managed) services–to which they don’t apply. The exemption of specialized services opens up a dangerous loophole in the view of proponents.

BIAS is what most consider “the Internet.” It’s the everyday websites we access on our computers and smartphones. What are specialized services? In the sleepy month of August the FCC’s Open Internet Advisory Committee released its report on what criteria specialized service needs to meet to be exempt from net neutrality scrutiny (these are influential and advisory, but not binding):

1. The service doesn’t reach large parts of the Internet, and
2. The service is an “application level” service.

The Advisory Committee also thought that “capacity isolation” is a good indicator that a service should be exempt. With capacity isolation, the ISP has one broadband connection going to the home but is separating the service’s data stream from the conventional Internet stream consumers use to visit Facebook, YouTube, and the like. This is how Comcast’s streaming of Xfinity to Xboxes is exempt–it is a proprietary network going into the home. As long as carriers don’t divert BIAS capacity for the application, the FCC will likely turn a blind eye.

What are some examples? Specialized service is marked by higher-quality streams that typically don’t suffer from jitter and latency. If you have “digital voice” from Comcast, for example, you are receiving a specialized service–proprietary VoIP. Specialized service can also include data streams like VOD, e-reader downloads, heart monitor data, and gaming services. The FCC exempted these because some are important enough that they shouldn’t compete with BIAS Internet. It would be obviously damaging to have digital phone service or health monitors getting disrupted because others are checking up on their fantasy football team. The FCC also wanted to spur investment in specialized services and video companies like Netflix are considering pairing up with ISPs to deliver a better experience to customers.

That is to say, the net neutrality effort has failed even worse than most realize. The FCC essentially prohibited innovative business models in BIAS, freezing that service into common-carrier-like status. Further, we have an Internet fast lane (which I consider a significant public benefit, though net neutrality proponents often do not). As business models evolve and the costs of server networks fall, our two-tier system will become more apparent.

Very happy to see the discussion over The Wall Street Journal‘s Google/net neutrality story. Always good to see holes poked and the truth set free.

But let’s not allow the eruptions, backlashes, recriminations, and “debunkings” — This topic has been debunked. End of story. Over. Sit down! — obscure the still-fundamental issues. This is a terrific starting point for debate, not an end.

Content delivery networks (CDNs) and caching have always been a part of my analysis of the net neutrality debate. Here was testimony that George Gilder and I prepared for a Senate Commerce Committee hearing almost five years ago, in April 2004, where we predicted that a somewhat obscure new MCI “network layers” proposal, as it was then called, would be the next big communications policy issue. (At about the same time, my now-colleague Adam Thierer was also identifying this as an emerging issue/threat.)

Gilder and I tried to make the point that this “layers” — or network neutrality — proposal would, even if attractive in theory, be very difficult to define or implement. Networks are a dynamic realm of ever-shifting bottlenecks, where bandwidth, storage, caching, and peering, in the core, edge, and access, in the data center, on end-user devices, from the heavens and under the seas, constantly require new architectures, upgrades, and investments, thus triggering further cascades of hardware, software, and protocol changes elsewhere in this growing global web. It seemed to us at the time, ill-defined as it was, that this new policy proposal was probably a weapon for one group of Internet companies, with one type of business model, to bludgeon another set of Internet companies with a different business model. 

We wrote extensively about storage, caching, and content delivery networks in the pages of the Gilder Technology Report, first laying out the big conceptual issues in a 1999 article, “The Antediluvian Paradigm.” [Correction: “The Post-Diluvian Paradigm”] Gilder coined a word for this nexus of storage and bandwidth: Storewidth. Gilder and I even hosted a conference, also dubbed “Storewidth,” dedicated to these storage, memory, and content delivery network technologies. See, for instance, this press release for the 2001 conference with all the big players in the field, including Akamai, EMC, Network Appliance, Mirror Image, and one Eric Schmidt, chief executive officer of . . . Novell. In 2002, Google’s Larry Page spoke, as did Jay Adelson, founder of the big data-center-network-peering company Equinix, Yahoo!, and many of the big network and content companies.

This interplay between bandwidth, storage, and latency, caching, content, and conduit, was the very point of the conference. What are the technical and economic trade-offs? Where will the Net be modular? And where will it be integrated? Where will content be stored, and who will pay? In many ways, the conference was ahead of its time. And my humble view is that Schmidt and Page may have even adopted some of the key insights of these conferences and turned them into some of Google’s most successful applications and architectures. A talk by Yale computer scientist David Gelernter in particular, I remember, seemed to have a profound impact on the way attendees visualized this coming “cloud” that would enable the death of the desktop. Remember, at the time, Google was still just a search engine company that hosted its then-thousands of servers in the data centers of Equinix and a few other hosting companies. Today, Google, with its global cloud platform and desktop killing apps, has become the supreme storewidth company.

I offer this background because some of us have been thinking about these topics for a (relatively) long time. When we first began analyzing this new “network layers” and then “network neutrality” policy concept five or more years ago, we did so with these profound architectural questions in mind. The Net, and the bits and applications traversing it, moves so fast, that we need all these technical solutions — routing, switching, QoS, CDNs, etc. — to make it work, let alone make it fast and robust.  

So yesterday’s Wall Street Journal story was not noteworthy for exposing some brand new network technology or architectural scheme. No, it seemed noteworthy (again, pending the accuracy of the reporting and the follow-on assertions) because (1) it highlighted the reality of this already existing architecture — something a few of us have been trying for years to expose and highlight as a shortcoming of the neutrality concept — and (2) suggested Google and others were softening their stance on the net neutrality policy issue. 

Now it’s perfectly possible the article is mistaken, that no one is softening on the push for net neutrality regulation. Let’s have the truth, indeed. But it is a good thing that we are getting deeper into the technology and architecture of the Net because a clearer understanding will expose net neutrality’s big flaws. As Gilder and I surmised five years ago, net neutrality, as ill-defined as it still is after all this time, seems one group’s attempt to get the upper hand on competitors using the heavy hand of government. My networks, good; your networks, bad. My content delivery bandwidth-saving latency-reducing fix, good; your content-delivery bandwidth-saving latency-reducing method, “evil.”

More to come. . . .

Correction: The issue of the Gilder Technology Report I referred to was of course titled “The Post-Diluvian Paradigm.” The meaning of this title was that after the flood of bandwidth — or capacity — was deployed, we would still need latency- and hop-reducing and other performance-enhancing technologies and architectures to make the cloud function robustly.