How Peer-to-Peer Impact is Mitigated

Author:
Publish date:
Updated on

Three summers ago, this column spotted an odd little marker along the broadband highway: Data engineers were no longer gladdened by the yellow 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 are 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. BitTorrent 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 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%. Requests for web pages, 9%. Email transmissions, 1%. The 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. A vendor community emerged, populated by companies like C-Cor Electronics Inc., Camiant Inc., Ellacoya Networks, and Sandvine Inc., among others. 

PACKET SNIFFER

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.

Stumped by gibberish? Visit Leslie Ellis at www.translation-please.com.

Related