Slashdot Mirror
Comcast's Congestion Catch-22
An anonymous reader sends us to Telephony Online for a story about Comcast's second attempt at traffic management (free registration may be required). After the heavy criticism they received from customers and the FCC about their first system, they've adopted a more even-handed "protocol agnostic" approach. Nevertheless, they're once again under scrutiny from the FCC, this time for the way their system interacts with VOIP traffic. By ignoring specific protocols, the occasional bandwidth limits on high-usage customers interferes with those customers' VOIP, yet Comcast's own Digital Voice is unaffected. Quoting:
"The shocking thing is just how big a Pandora's box the FCC has appeared to open — and it just keeps getting bigger. When the FCC first started addressing bandwidth usage and DPI issues, it quickly found itself up to its knees in network management minutia. Not long after that, it followed another logical path of the DPI question and asked service providers and Web companies about their use of DPI for behavioral targeting. Now it seemingly has opened up huge questions about what it means to be a voice carrier in the age of IP. It's not hard to imagine the next step: What about video? Telco IPTV services are delivered in roughly the same way as carrier VoIP services — via packets running on the same physical network but a prioritized logical signaling stream. Is that fair to over-the-top video service providers?"
The ISP supplying my workplace regularly blocks HTTP for up to hours at a time. Nothing else, just outgoing(!) port 80. First connections get dropped silently, then after a while it moves on to forged TCP reset packets when trying to connect to anything. Which is pretty worrying because they're the only ISP available here.
The problem is that the DOCSIS spec involves having your own little slice of frequency for downstream but everyone shares upstream. Your DOCSIS 1 stuff would let you dump 5 or 6 megabits to each of thousands (well, okay, maybe hundreds) :) of subscribers at once if you could actually feed the data into your head end fast enough. But sending the data back upstream is done on a shared frequency. Some line cards have multiple frequencies (no idea what they are now; when I worked for Cisco Santa Cruz when they were developing the Cisco DOCSIS modem ref design firmware it was the MC11 and MC16, I think, the MC16 had six upstream channels) so that you could send the same downstream to a whole bunch of places, but segment their upstream and feed it into the different upstreams (inputs on the line card.) If you run out of bandwidth you can charge more, and buy more bandwidth. But if you run out of upstream bandwidth on the line card, you have to add a line card and go forth and physically segment your network.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
My god every other first world country has huge bandwidth where these types of things aren't even a consideration.
Every other first world country has immensely higher population density. Canada's population is overwhelmingly located in certain centers and the remote population of Canada has just as much trouble as the remote population of the USA.
This does not adequately explain why we don't have higher speed in the areas of extremely high population density, of course.
We can solve these problems by forming community ISPs to wirelessly handle the last mile solution, which works in most places. Using solar-powered (or hell, wind-powered, it's very easy) mesh networks would work practically everywhere. IMO we would ideally replace the internet entirely with an alt-power mesh network. You can cross hills by putting a wind generator on top, running PoE as far as possible and putting PoE APs at each end of the wire. Wind generators can be made entirely out of junkyard parts (as can a welder to build it with, if you are crafty. a plastic fuel tank, some jumper cables, some scavenged wire and you've got a welder. The wind generator itself is made out of body metal, a steering knuckle, a wheel, an alternator. Easier to make with an oil drum instead of the body metal, though.
The problem here is one of "meh". We have great ideas but never seem to execute. I put myself in this category.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
"Comcast Digital Voice uses Internet Protocol and not the Internet. Comcast Digital
Voice calls travel on our private, managed network -- not over the public Internet. That makes
it superior to other 'Best Effort' services delivering phone traffic over the public Internet."
Source (emphasis mine): http://www.comcast.com/MediaLibrary/1/1/About/PressRoom/Documents/ProductsAndServices/digital_voice.pdf
My comments here are my own; I do not speak for my employer.
Did you read the part in the summary which said that Comcast VOIP was unaffected by this problem?
What was not mentioned is that Comcast's VOIP is out of band. I'm no comcast apologist (comcast's policies were the straw that broke the came'ls back and got me to move to a new house where I could get verizon FIOS) but this is less of an issue that it has been made out to be. From day one, comcast's VOIP has used seperate channels from their internet services. Their VOIP is limited to connecting to POTS or other comcast VOIP customers. It is not on the internet, it is only on a comcast private intranet.
When information is power, privacy is freedom.
You don't understand cable system design. The reason for the 6:1 ratio between upstream and downstream is not because Cisco (or anyone else) thinks you can oversubscribe the upstream spectrum, but because upstream carrier to noise ratios are much worse than downstream. Because of the lower CNR, upstream modulation has to have a lot more interleaving and error correction (and much lower symbol rates). It also helps isolate noise problems to a smaller service area.
Part of DOCSIS 3 spec is 64QAM upstream. Some operators are trying it now, and finding out that there's a whole new level of plant maintenance necessary to deliver a good upstream bit error rate. Meanwhile, the normal downstream carrier is 256QAM (6.4MSym/s symbol rate), which requires a 3dB improvement in CNR over 64QAM at the same symbol rate. As fiber is driven deeper into the cable network it will be much easier to increase the upstream modulation to 256QAM and downstream modulation at 1024QAM. Typical cable systems today use 16QAM modulation in the upstream, with a 3.2 MSym/s symbol rate.
And, it is fairly common to have multiple upstream carriers in a node (neighborhood). DOCSIS 3.0 adds support multiple downstream carriers* through devices called edge QAMS. The downside of that is most operators have 65 or so analog channels, several dozen digital cable channels, 4-5 VOD carriers, and one DOCSIS 2.0 carriers in the downstream. The push is to get rid of the analog channels, but that's politically unpopular since it would require all customers to get a set top box for every TV (someday tru-2-way TVs and set top boxes will be at Best Buy, but it's a long time coming). Once 3.0 is deployed, the typical system may have 3 or more bonded downstream carriers/service group, about 500 customers. End users will need a new modem to get full use of the channel bonding, but it should be worth it for the much greater increase in speed.
Finally, everyone always gets the "shared bandwidth" argument wrong. Most people think of DOCSIS like classic Ethernet, with a hub or daisy chain cable. This means that Ethernet NICs need to use CSMA/CA to avoid collisions. There is no way for a cable modem to hear another one, so the CMTS assigns a mini-slot to a cable modem when it is provisioned/registered (which essentially makes a TDMA channel). the ONLY time a modem is permitted to transmit is at it's assigned mini-slot. Over the years, CMTS software has improved, and operator's understanding of the configuration has become much more granular, to the point that bandwidth optimization is much better understood than it was 10 years ago, along with moving from 7200 series network engines to VXR and above (in the case of Cisco).
*There is some use of multiple downstreams now, it has been in the spec since DOCSIS 1.1, but isn't needed on much more than a temporary basis. Individual modems can only tune one carrier at at time, so it is typically used to get more customers on a node than it is used to get higher speeds. However, some operators have used multiple downstreams to isolate business class customers from everyone else.
"Well, good luck finding a judge that doesn't run a bestiality site."
The problem is that ISP's pay per megabyte for uploads. Downloads are free for them except for the cost of the line and equipment maintenance., etc.
Horse crap. ISPs pay the same for bandwidth usage up or down.
To clarify... Comcast Digital Voice, like any PacketCable service, uses reserved capacity. It comes off of the cable modem channel, at the physical layer (minislots), and it keeps the telephone calls off of the Internet. CDV is NOT an Internet phone service at all. It's a separate access network, using MGCP-derived signaling and RTP/IP encapsulation of voice.
If the phone is not in use, then a tiny bit more capacity on the cable (100 kbps/call) is made available for data. If you think that's unfair, fine, but that's how PacketCable works, and it maximizes efficiency for the whole system. It's safe, legal, and non-fattening.