Skip to main content

On Ethernet and DOCSIS

A chewy topic is starting to make the rounds amongst the industry’s technical ranks, enough so that it seemed plausible to tackle as this week’s translation.

It is this: What’s the difference between Ethernet and DOCSIS, the cable-modem specification?

It tends to pop up within three giant steps of any technical conversation containing the word “convergence,” and especially the convergence of IP-based services and devices in the home.

Video is always a good example. Say you overhear someone asking why digital set-tops don’t have Ethernet jacks. The reasoning: Most of today’s advanced boxes contain an embedded cable modem, which is inherently based on Internet Protocol (IP). To move IP video in and out of those boxes, to whatever other devices, why not do it over Ethernet?

That question typically beelines to uncertainties about whether Ethernet has the security needed by copyright holders, and whether it has adequate “QoS,” or “quality of service,” to handle video’s large and small needs.

It also elicits questions about the distance limitations of Ethernet, and whether you’d need to put in some kind of hub — which circles neatly back to the question of why set-tops don’t have Ethernet jacks.

Over the past several weeks, I’ve posed the Ethernet vs. DOCSIS question to a dozen or so smart tech-side people. Without getting too far into the mud of data networking, here’s what they had to say.

Once upon a time, when DOCSIS — the Data Over Cable Service Interface Specification — was created, it had one mission: To move IP data over cable’s hybrid-fiber coax (HFC) networks. By design, HFC networks deliver shareable bandwidth to pockets of 500-ish homes.

That meant DOCSIS had to straddle two design challenges: How to navigate the physical plant itself, and how to protect against data collisions inside shared bandwidth.

To deal with the physical plant, DOCSIS articulated two things: A channel width for sending traffic (6 MHz in the downstream, 200 kHz to 6.4 MHz in the upstream) and a modulation format (QAM, or quadrature amplitude modulation, in the downstream, QPSK, or quaternary phase shift keying, in the upstream).

To protect against data collisions, DOCSIS applied a more deterministic method than Ethernet. It regularly issued specific time slots, to move data to and from multiple cable modems.

Ethernet also describes how interconnected things communicate over a shared medium, but it does so differently. Say you’re a device that speaks Ethernet. You’re at a cocktail party with 500 other Ethernet devices. The room is silent. Everyone is listening.

You decide to say something. Just as you blurt your packets, someone else decides to speak, too. Your packets collide.

In Ethernet, you both stop, wait a random amount of time, then repeat yourselves. The randomized wait interval helps to assure that you don’t collide again. In DOCSIS, everyone in the room has a pre-assigned series of time slots that dictate when speech can occur.

Chances are high that if you’re reading this on a computer, it is connected to broadband over some form of wired or wireless Ethernet, provided by you or your employer.

At the other end of the network, where your broadband service provider links out to the Internet and/or its private, “managed” network, there’s probably a Gigabit Ethernet link.

So there’s Ethernet, in one form or another, at each ends, but not in the middle. The middle is DOCSIS.

It boils down to this: When DOCSIS was created, Ethernet didn’t have many of the “convergence friendly” attributes it has now. Nor had Gigabit Ethernet, or “Gig E,” gained such dominance in metropolitan and wide area networks as a remarkably cheap, fast way to move data over fiber.

Will set-tops get Ethernet jacks? Probably, some day. Will Ethernet replace DOCSIS? Probably not.

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