Packet Shaping as a Means of Flow Control
by Leslie Ellis // June 18 2007
Last week’s mailbox was stuffed with queries about the terms “packet shaping” and “traffic shaping.” They stemmed from a piece in Broadband Reports about an e-mail sent by Time Warner Cable to its broadband data customers in Rochester, N.Y.
The June 6 email describes a “network management tool to improve the operation of the network for all subscribers.” The technology, called “packet shaping,” will roll out nationally. Impact? “A small minority of users may experience slower speeds during peak hours when using certain applications that use a lot of bandwidth.”
Rather than focusing on the furious written responses from the Vocal Indignant, who sputtered aplenty on the topic, this week’s translation will instead attempt to describe how “packet shaping” works.
For starters, “packet shaping” is tech-talk for flow control. It tends to get mixed up with the term “peer-to-peer (P2P) mitigation.” Know going in that network engineers view the two terms as apple and orange, but for reasons that fall well outside of the allowable word count of this column.
Meanwhile, ongoing research from CableLabs about how bits move to and from (and especially from) cable modems shows a persistent case of 80/20 – in that 80% of available bandwidth is used by 20% of customers.
In non-peak times, maybe it’s not such a big deal. But during busy times, the logic goes, it’s not fair to the other 80% of customers, vying for the 20% of remaining bandwidth.
Hence the decisions by most operators (not just Time Warner) to apply mitigation techniques to keep their pipes (especially their upstream pipes) unclogged.
Packet shaping doesn’t change the shape of a packet (duh), because packets have but one shape: Digital. Zeros and ones. More, P2P mitigation monitors and manages packets that pass beyond the headend part of a broadband data system, known as the CMTS, or Cable Modem Termination System.
Generally speaking, this involves the use of gear that sits either “in-line” or side-car to the link between the CMTS, and the larger Internet. Its job is to watch the stream of packets flowing through the CMTS.
What makes this all such a provocation to the Vocal Indignant are the decisions made by service providers about what packets represent potential clogs. (How would you like to be called the hog?)
The focus now is on two types of traffic, which comprise that 80% usage pattern. One is news groups. Before the World Wide Web, we called these “bulletin boards.” They served academicians and hobbyists exchanging information and files. Problem is, those files keep getting bigger and bigger – video devours packets.
The other group represents Peer-to-Peer traffic. That’s the stuff of Bit Torrent, KaZaa, Joost, and their ilk. P2P techniques use broadband networks to connect the end-point “peers” (people’s PCs), to share the processing load. Because there’s big action at the end points of a P2P network, it generates a heavy packet flow.
Here’s what happens. Most operators use mitigation gear from companies like Cisco, Ellacoya, and Sandvine, among others. Features vary by manufacturer, obviously. In general, though, the flow control box sits there. Watching.
If a packet header comes in that’s identified as newsgroup or P2P traffic, the flow control box allows the current transmission to complete (“finish up what you’re doing there”) but then might throttle back that sender from future sessions of that traffic type, during the specified peak times (“and come back in a few hours.”)
Tangibly, this means that most people (80%) see no impact. Maybe things even seem a little faster. For news group and P2P partakers, maybe those activities slow during prime time. (If constrained to upstream traffic, even this group may see no impact.)
Notably, another MSO, active with P2P mitigation for more than 2 years now, installed it silently – to no complaints. Easier to ask forgiveness than permission?
This column originally appeared in the Technology section of Multichannel News.