NNSquad - Network Neutrality Squad
[ NNSquad ] Cable, TCP/IP, and Convergence
An NNSquad reader took issue with my posting earlier today where I said that "digital cable is of course already (MPEG) TCP/IP." Technically he has a point -- depending on which layers of modern cable systems we're looking at. Since the rapid advancing of this technology is quickly blurring lines -- I would assert that in the end making some aspects of these differences inconsequential from a policy standpoint -- let's spend a couple of minutes reviewing, in simplified form, how cable systems work and how this relates to our issues of concern. This may be more about cable than you ever wanted to know. Traditional analog cable (or the fully analog channels of a partly digital cable plant) is pretty easy. Analog modulation, fixed width analog channels, analog demod, processing, display. Done. Digital cable uses more advanced modulation techniques to fit multiple digital (for example, standard definition) channels as (usually) MPEG-2 streams into the space otherwise taken up by a single analog channel, often using crypto and imposing various access rights (DRM - e.g., CCI byte) along the way. Cable systems would likely migrate to MPEG-4 if possible due to bandwidth savings, but the massive installed base of MPEG-2 equipment suggests that this will take significant time. So far, this is pretty much a digital version of analog channels. All channels stream toward all users, all of the time. On an appropriately provisioned 2-way physical plant, DOCSIS can be used to arbitrarily assign some portion of digital capacity (e.g. 256 QAM modulation) to Internet access services. Back to those ordinary MPEG video streams. Since they're all streaming at once toward all users, no real interaction is required to view them. But this changes when you introduce Pay Per View (PPV), Video on Demand (VOD), or centralized DVR services, all of which require more control by users (particularly the latter two). Another aspect where more control is required is the rapid deployment of Switched Digital Video (SDV) by cable companies. SDV avoids the need of sending all streams to everyone all the time, instead sending less heavily viewed streams to particular neighborhood nodes (typically N-thousand subs each) *only* when someone on that node tunes to one of those channels. As you can imagine, the "command and control" aspects of this can be complex, as are interesting issues of deciding when to timeout channels that you suspect are no longer being viewed (or recorded). TCP/IP is heavily used for these control and management functions and is now essential for these systems to operate. Meanwhile there is a clear push toward the deployment of fully TCP/IP-based systems in advanced cable environments, in parallel with experimentation with MPEG-4 compression. The advantages of this sort of convergence are obvious -- but again, there's a lot of already deployed equipment to deal with, some of which (like advanced downloaded-firmware java-based set-top MPEG-2 boxes) have only been out in subscriber homes for relatively brief periods of time in many systems. So some of these changes may come comparatively slowly. This is all interesting from a technical standpoint, but ultimately has little to offer from a *policy* point of view. A key policy issue of note is that ISPs (whether cable, DSL, or whatever) are usually in a position to unilaterally determine what percentage of their total digital capacity will be devoted to their own video services that don't impact usage/bandwidth caps, vs. general purpose Internet access (and the competing video services that depend on this), in terms of Internet speed, latency, usage caps, and so on. So becoming too diverted by the details of the technology in this case is an easy way to lose track of the ball -- and you'll find that often those parties who most oppose Network Neutrality concepts will attempt such diversions as a matter of course. That's how I see it, anyway. --Lauren-- NNSquad Moderator