Leslie Ellis's blog

Tech Since 9/11: It's Changed A Lot

That crisp air that comes with autumn offset by the miasmic 10th anniversary of a national tragedy, seems a useful reason for reflection. This week, we’ll look back to 9/11/01 to see what the cable technology community was focused on back then.

For starters, it won’t all fit here. You’ve been busy. We’ve been busy. Sheesh.

Back then, the hot topic meter redlined on things like how to get ready for DOCSIS 1.1, “broadcast ITV” and how cable voice-over-IP might work, someday.

Set-top memory, always a thorn, topped out at 4 Megabytes of flash and 8 MB of RAM - and that was for the newer, souped-up boxes.

About 12 million digital boxes dotted the field then. Digital video recorders hadn’t yet happened. At the time, debates centered on which was the better of two potential approaches: Integrated (into the box) or networked (hello, cloud!).

A few months earlier, in July of 2001, some 26,000 HBO customers in a Time Warner Cable system were offered on-demand viewing of The Sopranos and Sex and the City. It was the first blush of on-demand video beyond movies, and the 3,000 people (11.5%) who decided to give it a go buckled the system.

HDTV hadn’t happened yet. In 2002, upwards of 2 million HDTV displays, at an average of $1,500 apiece, were expected to enter U.S. living rooms.

Other emerging technologies: Wi-Fi; switched digital video; E-911; and OCAP.

A thrice-looming FCC deadline for set-tops outfitted with removable security - first called “PODs,” for point of deployment modules, later rebranded to CableCards - was set for January of 2005, then July of 2006 and, ultimately, July of ‘07. The industry responded, fielding double-digit millions of Cable- Card boxes, only to see the consumer electronics side disappear from the scene.

It would be two more years until Bill Gates made his famous plea for “all-IP,” not just all-digital, and three more years until Charter pioneered the “digital simulcast,” in its Long Beach, Calif., system.

Since then, by the way, the Internet protocol (IP) scene took off big time, and is threading its way into just about every technology of the business, from content creation to distribution (CDNs), encoding (adaptive streaming), security (DRM), navigation (cloud), and the back office (”Web interfaces”).

Another contextual placeholder: By the end of 2004, technologists were openly wondering whether the telcos could really get into the video business - this time around.

IPv6, IMS, fragmented MPEG-4, HTML5, clouds, DLNA and MoCA, to toss together a jumble of superactive areas of work for today’s technologists, were barely on the drawing board a decade ago.

And that all preceded the conflagration of smartphones, connected devices, tablets, PCs, laptops, and other video-capable, IP-linked screens wanting to play video.

May we live in interesting times, indeed.

———————————————————

Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog.

What Happened on World IPv6 Day

It’s less than two weeks since the June 8 “World IPv6 Day,” and the results came in clean during last week’s IPv6 Summit in Chicago.

The highlights from the half-day summit, which attracted network experts from ARIN, Best Buy, Comcast, Facebook, Time Warner Cable, Turner Broadcasting, among others:

• On the June 8 test day, Comcast’s call center volumes were normal; two-thirds of consumer calls fielded by Time Warner Cable were along the lines of “what’s all this about IPv6?”

• Thousands of websites turned on IPv6 - and left it on.

• When IPv4 was created in 1978, 4.3 billion addresses seemed like plenty. Now, with 7 billion people on the planet, many of whom regularly use as many as five devices with IP addresses, 4.3 billion seems … puny.

• The most frequently asked question of John Curran, CEO of the American Registry for Internet Numbers (ARIN): Why is IPv6 not backwardscompatible to IPv4? “Because we already had millions approaching billions of v4 addresses out there that couldn’t be changed, or couldn’t be reliably updated to v6.”

• The transition to IPv6 will be hardest for broadband access providers, like cable. “Your customers want access to the entire Internet. If your neighbor can’t connect to a web site because it’s on the wrong protocol, he’s not going to think it’s his problem. He’s going to think it’s your problem.” (Curran)

The hit machine keeps rolling, when it comes to colorful ways to describe the largess of the IPv6 address space. Last week’s addition: If you were to cram all of the IPv4 addresses into a ball, it’d have the density of a golf ball. IPv6? A ball the size of the sun.

• The measure of success in transitioning is expressed in terms of things not broken: “World IPv6 day was pretty much a non-event, from a brokenness perspective.” (John Brzozowski, Comcast)

• Retailers wouldn’t venture a guess on what percentage of the IP-connectable consumer gadgets on their shelves are IPv4, vs. IPv6, and they’re concerned. “Any products that aren’t ready for IPv6 will cause return rates to go up. That not only drives up cost, but it keeps consumers on the sidelines - nobody wants to buy a product that doesn’t work right.” (Stephen Bosch, director of strategy and business development, Best Buy)

• Useful web links to stay current with the IPv6 transition: www.arin.net, www.getipv6.info, www.teamARIN.net.

• Content providers are finding it “relatively straightforward” to transition to IPv6. “The routers tend to work, load balancers and other appliances that go into providing a web site, those are improving in quality.” (Sam Gassel, Turner Broadcasting)

• Quote of the meeting, from Comcast’s IPv6 shepherd John Brzozowski, about World IPv6 day: “It was a wasted 37 hours of not sleeping, for me.”

________________________________________
Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog

Your Cable Show Jargon Descrambler

Whether you call it “TV Everywhere,” or “The Four Anys” (anything, anywhere, anytime, any device), IP video, or cable over IP, a lot of what we’ll see and hear at this week’s Cable Show in Chicago is about where cable goes next: Other screens, beyond the TV.

So yes, you’re going to see a lot of video on non-traditional displays: Tablets, lots of tablets, and smart phones, and PCs. And yes, you’ve seen that before. What’s different, and what will continue to be different, is the plumbing underneath.

All together now: It’s IP. Internet Protocol. (Which is different than “the Internet.”)

Why does this matter? Because we’re moving to a world where stuff can be done without set-top boxes, at least as they exist in hardware. Now, it’s set-tops; next, it’s gateways that bridge between set-tops and cable modems, and ultimately, it’s video delivered completely over IP, from the network, to the end devices.

Because of that, the industry can’t exactly call the shots anymore, in terms of how things do or don’t interact with that set-top box. This may make you cry out in delight, or it might make you twist a napkin into shreds.

Either way, in a world where other forces call the shots, it’s important to glom onto the most pervasive batch of open standards.

Which is why, at this week’s show, if you happen to peer under the hood of just about anything, you’ll probably run into one, if not all, of these terms: MoCA, DLNA, DTCP-IP, “the DRMs,” HTML5. (Maybe a little SAML, here and there.)

A quick refresher:

MoCA: MultiMedia over Coax Alliance. It describes how to put the bits on the coaxial wires already inside homes, to connect everything up. Good for flinging multiple HD streams around the house.

DLNA: Digital Living Network Alliance: It tells each connectable device how to describe itself, iconically. I’m a PC, my icon is this; I’m a tablet, my icon is this.

DTCP-IP: Digital Transmission Copy Protection over Internet Protocol. Security, in the form of copy protection, for those IP-connected, video-hungry screens.

DRM: Digital Rights Management. Security for the video asset, as opposed to security for “the ride” over the pipes.

HTML-5: Hypertext Markup Language version 5. A way to render the user interface on those other connected screens.

As for SAML (pronounced as a word that rhymes with camel) - it stands for Security Assertion Markup Language, and it’s about single sign on. So that when you surf from one video source to another, you don’t have to log in all over again.

Go take a look at Neustar Media (booth ES-67) for a good example of SAML in action. Why: Because they’ve figured out the “everywhere” part of TV Everywhere, at least for movies and episodic/on-demand television.

See you in the Windy City!

Click here for more Cable Show 2011 coverage.

Stumped by gibberish? Visit Leslie Ellis at multichannel.com/blog or translation-please.com.

What to Wear on World IPv6 Day

This Wednesday, June 8, is World IPv6 Day. What happens on a day with that weighty a milestone? Testing, testing and more testing.

By now, this should be ringing some bells. Sometime between Halloween and the next New Year, the set of Internet-protocol addresses under the current numbering system, IPv4, will vanish. Kaput. No more.

In its place will be IPv6 addresses. That’s important because of the increasing number of things in our daily lives that work best (or only) when connected to the Internet. Anything that hooks up to the Internet gets an IP address: computers, laptops, smartphones, connected TVs, tablets.

The great thing about IPv6 addresses is that there will apparently always be enough to go around, no matter how Internet-crazy and cloud-addicted we get. Its breadth is the layman’s equivalent of “gazillions.”

Lately, though, I’ve been wondering about what happens when something goes wrong. What happens in that IPv4-heavy household, when there’s no more IPv4? Does the Internet seem slower? Do certain apps lock up? Blue screen of death?

In wholly unscientific hallway discussions with people who work on this transition for a living, it appears that more than half of home routers (the thing after the cable modem that sprays signal around for all your stuff) are IPv4. Many of the “connected TVs,” so splashy just six months ago at CES, aren’t IPv6.

Turns out that the question of what happens has different answers. As with most other complex technological marathons, it depends. (Sorry! Sorry!)

Most, if not all, of the major cable providers are transitioning to IPv6 in a way that should earn them the right to say, “We got ya covered.” IPv4, IPv6, sure. Either. If they do their thing right, you’ll keep doing your things right, no issues.

Always in these conversations, though, one tech term emerges, spoken ominously: carrier-grade NAT, where NAT stands for Network Address Translation. Boiled way down, it goes like this: Share the limited number of IPv4 addresses among everyone who needs them.

Surprise: It’s starting to look like certain applications won’t do well in a carrier-grade NAT environment. Think of any app that needs to talk a lot, back and forth with the “cloud.” Streaming video comes to mind, and over-the-top voice, and peer-topeer file-sharing.

Which brings us back to World IPv6 Day. What goes wrong will hopefully get a lot more informed - because forearmed is forewarned.

As for what to wear: Geek out, brothers and sisters. And if you’re aching for more, don’t forget the IPv6 Summit at next week’s Cable Show in Chicago, on Tuesday, June 14. Maybe I’ll see you there.

Stumped by gibberish? Visit Leslie Ellis at multichannel.com/blog or translation-please.com.

The Care and Feeding of Upstream Channel Bonding

Lots of action lately around the topic of upstream channel bonding, especially as more and larger digital stuff wants transit across that slender spectral area.

A brief review: Cable spectrum comes in two stripes: down and up. All the bits of online video, Netflix streaming, Skype calls, HDTV, video on demand - stuff heading into your house - that’s the downstream signal path. Most (95%) of an operator’s total available bandwidth is pointed downstream.

The upstream signal path is the tiny sliver of spectrum set aside to move the bits that leave your house. Your part of a voice-over-Internet protocol phone call. A click to fetch a Web page. Pausing an on-demand movie.

Ask any engineer what’s happening in the upstream, usage-wise, and you’ll hear a variation of this: Average and peak consumption is on the rise. As digital consumers, we’re not only sending more stuff upstream, we’re sending bigger stuff. “Your part of a VoIP call” is a whole different thing than “your part of a video chat.” Voice moves at 64 Kilobits per second; video in the Megabits per second.

That’s why we’re starting to hear more about upstream channel bonding - a method that lets cable modems transmit across multiple channels at once. Cox made news on the topic last week, with word that its tests of a 12-channel bond yielded a 400-Mbps link.

(Note: Great stuff, but be careful anytime you see mention of 88 MHz as the upper boundary of the upstream. The upstream path tops out at 54 MHz. Going higher is a fine goal, but it isn’t a finger snap and a “voila.”)

One big difference between upstream and downstream bonding is channel width. While downstream channels all weigh in at 6 MHz, upstream channels can be sized at 1.6 MHz, 3.2 MHz, and 6.4 MHz.

Why? Because the upstream signal path was never envisioned or designed to carry broadcast video, which was what dictated 6-MHz channelization, back in the earliest days of analog television.

Modulation methods tend to notch down a step, compared to the downstream, too. That’s because it’s way noisier in that slice of spectrum - and when you’re sending through noise, just like when you’re flying through turbulence, it works better if you slow down.

The fastest of the three upstream modulation methods - 64 QAM - runs at around 7.5 Mbps on a 1.6 MHz channel width, 15 Mbps at 3.2 MHz, and 30 Mbps at 6.4 MHz. Most cable modems running DOCSIS 3.0 are configured to bond four upstream channels. So, four bonded 6.4 MHz channels running 64-QAM yields is around 120 Mbps. Cox bonded 12 channels at 64 QAM to get to 400 Mbps.

That’s a quickie on upstream channel bonding - an enormously useful tool for a spectrallystrained domain.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at translation- please.com or multichannel.com/blog.

Canada, Elections and Network Congestion

Toronto - Last week’s SCTE Canadian Summit brought an odd and unsettling portend of what can happen with usage-based billing for broadband services.

As this column has detailed before, the major telcos and cable companies of Canada launched what they call “additional usage billing” in 2008-2009.

Two years before that, in Rogers’ case, a phased plan educated consumers about which gadgets (cameras, initially) use what bandwidth. Usage totals started showing up on monthly bills. Closer to launch, thermometer-looking meters showed up on people’s PC screens to show ongoing usage.

No consumer freak-out happened at launch, because most subscribers were far from going over the limit (in Rogers’ case, $1.25 per Gigabyte over 95 GB per month on a high-end tier; $5 per Gigabyte over 2 GB for the lowest tier; nobody pays more than $25 in overages ever).

So, as rollouts go, it was highly consumer- focused. For that reason, Canada is often held up as the model about how to go about it when the time comes.

Fast-forward to now. New since then is Netflix streaming; higher since then is a compound annual growth rate of 45% (and growing) for Internet usage.

(Aside: Keynoter Tony Werner, chief technical officer of Comcast, quipped that it’s not just difficult, but impossible, to find historical examples of any consumable product with a 45% compound annual growth rate, over time. “I figured, maybe electricity? Alcohol? Nothing. Although I’ve not seen a bar where $40/ month gets you all you can drink, either.”)

And, in Canada, it’s election season. Part of the buzz at last week’s SCTE event involved a tweet by Canadian industry minister Tony Clement questioning the existence of network congestion.

Suddenly, and not unlike cable’s early toe-dipping into additional usage billing here, cable is the anti-Christ, greedily tipping usage meters into fistfuls of cash.

Never mind that people stream more than they download, or that Netflix traffic represents 20% to 50% of bits carried. Never mind that operators are doubling broadband network capacity every year, on a flat-out sprint to keep up with usage.

Technologists at the Canadian SCTE Summit positioned Clement’s tweet as a compliment. Clement’s skepticism about network congestion “means we’re doing a hell of a good job” in staying ahead of consumption, said Rogers senior vice president of engineering Dermot O’Carroll.

Canada already was doing a hell of a good job. The fact that usage-based billing became an election lightning rod so quickly and venomously? That’s the odd portend.

Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog.

What's Clogging Up the Pipes

Last week, we looked to the north at claims by an elected official in Canada that “additional usage billing,” as they call it up there, should be overruled because there’s no evidence of congestion on the Internet.

This week, we’ll go a little deeper into what’s clogging the network - because it’s not just Netflix bits causing that sustained, 45% (and higher) compound annual growth in broadband Internet usage.

First let’s hit the obvious: There are more subscribers, buying more devices that want to attach to the network. Look around your house. Bet you a dime there’s at least 10 items seeking an Internet connection (don’t forget digital picture frames, game players and all of your handheld gadgetry).

Then there’s the very nature of the “adaptive codec,” also known as “fragmented MPEG-4.” MPEG-4 is the latest chapter in video compression. It works by chunking a compressed video stream into several different sizes, then sending along the right size for how much bandwidth is available. Congested network? Send the smaller chunk. Lots of elbow room? Send the biggest one you can. For that reason, adaptive streaming behaves like a gas, filling all available space - or network pipe, in this case.

Here’s one that’s start to show up more: machine-to-machine computing. Tony Werner, chief technology officer of Comcast, pointed out during his keynote at the SCTE Canada Summit on March 8 that while population growth is less than 1% per year, machines are growing at 50% per year - many of them network-connected and talking.

What does that mean? Not a lot of bits, but lots of machines moving them: software updates, virus updates, distributed computing. Like the fun-to-say “Berkley BOINC” (pronounced “boink”), described as follows on its website: “Use the idle time on your computer to cure diseases, study global warming, discover pulsars, and do many other types of scientific research.” Early on, a predominant use was “SETI,” for “Search for Extraterrestrial Intelligence.” All of your geekier friends had it. These days, my favorite is the Electric Sheep screen saver.

Then there’s pixels per person, which measures the amount of screen we look at as humans. Right now, and according to data from Cisco Systems’ ongoing VNI (Visual Networking Index) research, you view 1.4 million pixels; within three years, that nearly doubles - you’ll be looking at screens with an aggregate pixel count of 2.3 million.

Does broadband usage ever plateau? Doesn’t seem likely. That’s good news for all the stuff we do electronically; bad news for those who built, maintain and augment those broadband pipelines.

________________________________________

Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog.

More Language of Commercial Services

Billions. That’s the hook for just about every discussion about commercial services these days - those big buckets of cash, just waiting to be hauled in.

How big? The market for metro Ethernet services is projected to attract $40.2 billion by 2014; cable’s share of that could be as high as $10 billion (citing data from Vertical Systems).

And that’s about the only thing that’ll get your pulse up. If you haven’t yet wandered into to the business of serving businesses, know going in that it’s as dry as sawdust. Jargon? Maybe a little. Here’s a sampling, from a recent batch of notes: “Since devices can have multiple Ethernet virtual circuits running across them, they may each have different logical MEGs - because you wouldn’t want MEPs for customer A’s service to be able to collect data from customer B’s EVC.” Heavens no!

Let’s start at the beginning, using DOCSIS as the conversational foundation. We mostly know DOCSIS as the specification for cable modems that serve residences with broadband services. But it’s also under heavy tweak to be a foundational technology for serving businesses with connectivity.

What do businesses need that households typically don’t? For starters, guarantees. SLAs, as they’re called, for Service Level Agreements. That means they want to assurances about throughput - are my data moving at the rate of speed I purchased? - and overall network availability.

They want to be able to monitor and receive proof against things like frame delay, and frame loss. “Frame” is a term from the carrier world, meaning groups of digital packets associated with linking one local area network (LAN), to another. So frame delay indicates the time it takes to get from the place where data is transmitting, to the place where it ends up. Frame loss counts how many packets are dropped or damaged en route.

Usually, businesses want to manage their services themselves - another difference from residential data services. And, they need ways to customize their data plans accordingly.

Which brings us back (kind of) to the jargon sentence. Loosely translated, it means this: When you’re linking businesses with “virtualized” (cloud-based) Ethernet services, you want to make sure the professional-grade cable modems associated with the local State Farm offices don’t have visibility into those serving the pizza chain.

The good news: Those buckets of cash are real. Comcast, Cox Communications and Time Warner Cable surpassed $1 billion (individually) last year, in terms of revenue collected from businesses.

Which means it’s probably time to elbow past the dullness of the commercial services scene. Dig in, learn the lingo, bring in the haul. It’ll be fun.

________________________________________

Stumped by gibberish? Visit Leslie Ellis at translationplease.com or multichannel.com/blog.

Where Does 'Network' End and 'Cloud' Begin?

Cloud. It’s everywhere in the intersecting languages of business and tech.

As a person of words and tech, it’s noticeable that lately even “cloud” has lost its participle - like how the British talk about taking someone to “hospital,” not “the hospital.”Example, from a recent batch of notes: “Cloud is a big space, with lots of different players. Cloud isn’t just one particular thing - it’s what Amazon does, yes, but it’s a lot more than IaaS (infrastructure as a service).”

In general, “cloud” is a catch-all term that means services or functions you used to get locally on a fixed machine at your house or workplace, but that you now get from anywhere, in real time, delivered to you over the Internet.

Maybe you’ve experienced what happens when the “in real time” part of “cloud” isn’t there: No connection means no Facebook, no access to the files you stored on SugarSync or Dropbox. (This usually happens when you’re out of town and either bored out of your mind, or in desperate need of your stuff.)

In cable, navigating subscription TV via something other than the remote is a good cloud example. Letting consumers use their gadgets (iPads come to mind) to change channels, set the digital video recorder or stream TV means acknowledging that different screens have different decompression engines, resolutions and communication passageways than set-tops.

So instead of trying to do everything from the set-top, why not use the cloud - the connection - to bridge the differences?

Here’s where I get flummoxed when it comes to cable and cloud: Where does “the network” end, and “the cloud” begin? Lots of people use the two terms synonymously: Cloud is network; network is cloud.

For those of us who grew up in cable knowing “network” as the word that grew up out of “plant” - where “plant” is the connectors, coaxial cable, pole-line hardware, pedestals, fiber, lasers and related headend whatnot needed to move video, data and voice signals from one place to another - the distinction is nebulous.

It’s good, says a cloud-engineering pal, to tease the two terms apart. Part of it involves getting to know the “data center,” a place filled with servers and software that “abstract” the stuff running over a network from the network itself. Part of it, too, involves knowing the difference between “service” and “server.”

More on that next time.

________________________________________

Stumped by gibberish? Visit Leslie Ellis at multichannel.com/blog or translationplease.com.

Where Network and Cloud Meet (Part 2)

Last week, we looked for the intersection of “cloud” - for it has lost its participle, it’s that popular - and the network. Where does the network end and the cloud begin? That is the question.

There’s no easy pocket map, but two signposts exist. One is the swift rise of the “data center.” Another lies in the tacit differences between “server” and “service.”

Let’s start with the data center. For as long as I can remember, the central nervous system for any cable plant was (and is, for now) the headend. It’s a term borrowed long ago from train transit, to indicate a central point for signal collection, processing and transmission to connected homes. (In rail transit, the locomotive at the front, or “head” end, generates the electricity needed for most everything else.)

These days, a place as important as the headend is the data center. Same ambience - a chilled room filled with racks of gear - but instead of processors, modulators and combiners, data centers hold servers, servers and more servers. Some ingest content coming in from content delivery networks or CDNs - big, Internet-protocol backbones moving content as fragments of files, not processed streams of contiguous video packets.

Other servers store those video files; still others “transcode” them, to suit the resolution and display needs of the screens at the end of the line - TVs, sure, but also PCs, handhelds, tablets and the growing landscape of video-capable gadgetry.

Still others work as “web-service” bridges between traditional back-office functions and the new world of web-based everything.

In a “cloud” sense, then, data centers are the place where video content comes in over IP, gets wrapped in DRM (digital rights management) and is sent out again in IP, through the CMTS, to a cable modem, into a Wi-Fi or Ethernet router in the house, to the display device.

(In a headend scenario, signals come in over satellite or terrestrial antennas, get processed, encrypted, re-modulated, combined, and sent out through headend controllers to set-tops, connected to TVs.)

This brings us to the second video cloud differentiator - the server vs. the service. In today’s “client-server” parlance, a “client” - a set-top, let’s say - talks to a server (think VOD pump). Each client knows precisely what data to expect from that server, and if the server hiccups or nods off, communication halts.

A “service” model extends traditional client-server activities to a peer-to-peer model, where each client essentially “discovers” the right server for what it needs. The servers themselves, and their databases, might be “virtualized” across multiple data centers. The data each client needs may be assimilated from many different servers. One might take the initial request (”I need video”), while others fulfill it.

Where does network meet cloud? In the data center, for starters, using Web-service interfaces to the “classic” (seems nicer than “legacy”) gear. One thing does seem certain: Everywhere you look, “cloud” will continue to stretch a hazy cover over everything we used to think we knew about video transmission.

________________________________________

Stumped by gibberish? Visit Leslie Ellis at www.translation-please.com or multichannel.com/blog.

Syndicate content