Monthly Archives: August 2006

Inside the Peer-to-Peer Tool Kit

by Leslie Ellis // August 28 2006

Three summers ago, this column spotted an odd little marker along the broadband highway: Data engineers were no longer gladdened by the yellow school buses rolling children back to school. Alas, the consumption spikes generated by the children of broadband customers had been surpassed by peer-to-peer traffic.

Back then, “P2P” was all about swapping audio files. This was back when grandparents were nearly arrested for the songs their grandchildren illegally downloaded. Video swapping wasn’t much more than a grim prediction.

A brief refresher on peer-to-peer: It’s the highly automated version of kids going to the PC to share music and video files. In P2P arrangements, portions of each participant’s hard drive hold pieces of a song or video. Those chunks of audio or video get automatically plucked off, in the background, at any time of day or night, unattended.

Broadband, because it is fast and “always on,” is the great enabler of P2P.

In 2003, the big names in P2P were Napster and KaZaa. Bit Torrent and Gnutella, two of the biggest bandwidth eaters today, were but shapeless lines of code.

P2P and the 80/20 Rule

The unwavering prediction from the bandwidth watchers in the summer of 2003: P2P is growing fast. It isn’t going away. It won’t stop seeking ways to ride on broadband.

They were right. P2P traffic now falls handily into the scores of examples of the 80/20 rule: 80% of bandwidth is used by 20% of users, most of which are P2P traffickers.

For the people who maintain the nation’s broadband networks, it’s well known that P2P traffic is most deleterious in the upstream (home outwards) direction. That’s because the upstream path is so very much more slender than the downstream path.

Here’s how the upstream usage looks. Say you’re serving residential broadband into a system with half a million customers. Within one work week, your upstream patterns probably track something like this: P2P traffic, 80 percent. Requests for web pages, 9 percent. Email transmissions, one percent. In the tailing remainder: Games, voice services, instant messaging, news groups, and streaming.

Then and now, broadband technologists wanted tools to preserve the speeds expected by the 80% of their customers who weren’t dabbling in P2P. One technique was known, but clunky: “Byte caps,” which count the packets transmitted by the “big talkers” in the upstream, and clamp them down to a maximum allowable number of bytes, per month.

Critics used phrases like “brute force” to describe the byte caps. Capping bandwidth, they warned, was akin to punishing customers, which could drive them to competing providers. They asked for better data forensics.

New Tools for P2P

A vendor community emerged, populated by companies like C-COR Electronics, Camiant Inc., Ellacoya Networks, and Sandvine Inc., among others. From them, another category of P2P management emerged: Mitigation, both “in line” and “passive.”

“In line” mitigation means the tool stands right in the middle of the broadband bit stream. One type of in-line mitigation, for example, is called “deep packet inspection,” or DPI. It works like this: Somewhere in the broadband equipment chain, a “packet sniffer” inspects the contents of every packet transiting the broadband pipe (yes, even if they’re encrypted).

Any packets identified as P2P are handled according to rules set within a “policy server.” (Sometimes, deep packet inspection happens inside a policy server, or visa versa, depending on the vendor.)

A policy server might individually limit the P2P packets. Or, it might limit all P2P bits, in aggregate, from all P2P transmitters. It depends on the nature of the offense, the degree of congestion, and the intentions of the operator.

What’s “passive” about “passive mitigation” is its location — as in, not directly in the flow of broadband bits. Passive mitigation techniques work off to the side, replicating chunks of data to check for P2P bits.

Either way — In-line or passive — mitigation walks a fine line. When less than a quarter of your customers are potentially disrupting everyone else, something has to give.

The trick is to minimize the impact of P2P traffic on the network — especially the upstream — so that “ordinary” broadband customers still get service that feels lightning fast, and P2P dabblers don’t get cranky and leave.

My favorite tale of P2P handling turned out to be untrue, but it still makes for a good urban legend. It goes like this: A cable operator (first letter “C”) added a second channel for cable modem traffic. All bandwidth hogs, meaning heavy P2P users, were put on the new channel. Reasoning: Let them compete with themselves for available bandwidth.

Brilliant, right? Maybe someone ought to try it.  Hint, hint.

This column originally appeared in the Technology section of Multichannel News.

Countdown to ‘Seven-oh-Seven’

by Leslie Ellis // August 14 2006

It’s official. There’s now less than a year left to prepare for the July 1, 2007 FCC deadline, which  prohibits cable operators from deploying set-top boxes with embedded security.

That means today’s inventory of digital video boxes, which carry their security mechanisms on the inside, needs to wane. Subtract a quarter, to Spring of 2007. (Fielded boxes don’t need to be replaced, but new installs have to use removable security.)

Next, manufacturers need to be given fair notice of actual order volumes for each model of new box, so they can ramp up their production lines in time. Subtract two more quarters. Now we’re at November of this year.

Oh, and don’t forget testing, of the boxes and the cards. Which brings us to right about …. now.

A Brief History of Time

Here’s the short version of how this all came to pass: The 1996 Telecom Act mandated retail availability of “navigation devices,” meaning set-tops. Two years later, the FCC issued “navigational device rules,” stipulating a July, 2000 deadline for cable operators to provide “point of deployment” modules (now called CableCards) to customers who buy a set-top or TV with built-in set-top.

The industry met the deadline, but nonetheless was told by the FCC to stop deploying boxes with embedded security after January of 2005 — the so-called “integration ban.” All multichannel video providers were included, except direct broadcast satellite providers.

Then, in December, 2002, the cable and consumer electronics industries filed their landmark “plug and play” agreement for one-way devices to the FCC. In April of 2003, the FCC pushed the integration ban back to July 1, 2006.

Meanwhile, work advanced on whats known as “downloadable conditional access” (see the May 9, 2004 translation), which would eliminate the need for the CableCard. The system was demonstrated to the FCC, which liked what it saw enough to push the integration ban to July, 2007. That brings us to now.

This year produced a flurry of waiver requests: Comcast and Charter both asked for exemptions on low-cost, limited capability boxes. Watch for a yay or nay soon.

Verizon also asked for a waiver last month, saying that it’s also cooking up a downloadable security method. And besides, they’re new to the multichannel video provider scene. Have mercy, they say.

Multi-Stream & Two-Way

Technologists tend to get a little worked up when describing the workflow triggered for them by the FCC deadline. They usually start with a reminder that the security card itself is different and more advanced than the cards going into today’s one-way TVs.

For starters, all leased set-top boxes are inherently two-way, so the cards also deliver two-way content, like video on demand and electronic program guides. That’s one difference. Also, most of the new cards are “multi-stream,” meaning they can simultaneously decrypt more than one scrambled string of bits.

Then there’s the logistics involved with upgrading headend controllers, testing set-tops, ordering them for scale, getting rid of the warehoused boxes with integrated security, dealing with what will be a massive inventory of CableCards, and making sure all existing applications run on the new type of box.

That kind of work intensity would seem to put the big kibosh, or at least a serious dent, into any other system initiatives — like, say, rolling out much of anything else.

Say It Isn’t So

Any way you look at it, if you’re a cable operator, the July 1, 2007 deadline is a big fat bummer. It’s costly, it slows progress on competitive initiatives, and it carries zero benefit for consumers.

Let’s start with the cost. Early estimates put the price tag as high as $480 mil. per year, for the whole industry, and until downloadable security is ready and deployable.

That’s a guess, of course. Right now, CableCards go only to those customers who buy an HDTV or digital TV with a “built in” cable set-top — the “unidirectional” or one-way TVs. After July 1, 2007, CableCards will be required for all leased boxes. It’s a huge difference in card volume.

Here’s how that math comes together: Aggregate industry volume of 6 million units per year, times $60 to $80 for the total card plus slot interface costs, equals $360-$480 mil. per year.

For everyday people, the FCC’s rule does this: Nothing. It means that when you sign up for digital video service, whether standard definition or high definition, you get a box that has a card slot in it, instead of a box that doesn’t have a card slot in it.

Try explaining this to your non-industry friends. The reaction registers somewhere between “but why?” and “so what?”

Yet, as of right now, you have to do it. It’ll cost you money. It’s a distraction from innovations that actually offer new features. Theres nothing marketable about it.

And, short of a waiver, extension, or ban of the ban, there’s but 11 more months to get ready. Tick tock.

This column originally appeared in the Technology section of Multichannel News.