Comcast Inc. may have cast a much wider net in their effort to
bring customers inline increase subscriber value. The Slingbox is set to become the latest example of collateral damage in the war against user content.
Quick recap: Slingbox is the generic name for a family of special-purpose devices that can stream TV content for remote viewing. In the same way that VCRs and DVRs allow time-shiftin watching a live broadcast at a different time, the Slingbox allows for “space-shifting” by watching content at the same time from a different place than the physical location of the cable connection or satellite dish. SlingPlayer application available on Windows, Mac and smart-phones allows connecting to the device from any Internet connection and streaming almost the same video/sound that one would see see watching television in comfort of the living room. “Almost” being the operative keyword, because video quality or how closely the streamed content approximate the original, is crucially dependent on available bandwidth. That includes both the upstream bandwidth available on the connection where the SlingBox is located and the downstream bandwidth at the remote location where the traveling customer is trying to tune in to his local TV station. As noted earlier here, downstream bandwidth is usually abundant while upstream bandwidth is the scarce commodity and the expected bottleneck for scenarios involving streaming from home. SlingBox FAQ notes that about 250-300kbps is the minimum recommended bandwidth. That turns out to be an understatement similar to Vista minimum hardware requirements. In this bloggers’s experience ~500kbps is required to avoid compression artifacts and closer to 800 kbps is called for when the signal is intended for display on a TV at standard watching distances instead of a tiny window on a laptop screen.
This is where the Comcast story comes in, only weeks after the company finally admitted to interfering with the operation of BitTorrent protocol. Recent experiments on trying to stream content from a Slingbox attached to a residential Comcast broadband line suggests that the traffic-shaping may be more widespread than peer-to-peer alone. SlingPlayer uses a sophisticated, adoptive algorithm to optimize image quality for the maximum available bandwidth on any given connection. It starts out by streaming a few frames at low quality, successively increasing the transmission rate until the channel is close to saturation or the client can not keep up with the decompression.
When streaming from a wireless home network where the Slingbox is located, bandwidth peaks out 2-3 Mbps and the image quality is very good. In a more representative scenario, during 2006 a SlingBox A/V routinely delivered cable content from Florida, behind a Cox 9.0/1.5Mbps broadband connection hitting anywhere between 700-800 kbps sustained, good enough to watch on a 32″ TV. (Ironically the downstream side of that connection in Chicago was Comcast.)
It turns out Comcast is happier to go along with receiving content than serving it. Below are pictures of bandwidth usage when streaming from a SlingBox Solo on a Comcast 9.0/1.5Mbps connection in Philadelphia.
- Image from task manager’s network view
- Image from perfmon, TCP/IP bytes received per second and packets per second
[Update: added second trace using perfmon– Jan 9, 2008]
As expected, the connection rate shows the initial gradual climb to roughly ~700 kbps. But after two minutes something very strange happens: it drops precipitously, shedding 50% of the bandwidth in a matter of seconds and flat-lines at around 350.
- These results can be reproduced consistently, at different times of day, from a wide array of streaming locations: broadband at home in NYC, a corporate LAN in Silicon Valley, free hotel networks in San Francisco, even a 3G wireless modem. Without exception all of them exhibit the same jagged, initial climb followed by a sharp drop and flat-line.
- The flat-line is very suspicious: “organic” network traffic is subject to random perturbations due to effects of congestion along the way.
- We can rule out the client side as being source of the problem because it repros independently of how the streaming side is connected to the Internet. It’s unlikely to be a bug in SlingPlayer or bad interaction with a particular operating system’s networking implementation because it repros on Windows, OS-X and Mobile versions. Even allowing for the possibility that all of the cross-platform variants share the same code base, and susceptible to sharing the same bug, there is the mysterious fact that this “bug” never occurs when SlingPlayer connects over a home network– not crossing any Comcast controlled space– where it easily hits multiple Mbps.
- Disconnecting from the Slingbox and immediately reconnecting restores the initial spike of high bandwidth– so there is no transient congestion issue either. That spike then follows the same pattern, eventually dropping off to a flat-line.
- At this point the most plausible explanation is: Comcast has engaged in wide-spread traffic-shaping which downgrades available upstream bandwidth to a fraction of the stated value and in particular interferes with the operation of the Slingbox.