Continuing from Part 1.
To cut to the chase, your coaxial cable (and hence your cable company) is capable of delivering (roughly somewhat less than) 5Gbps into your house.
The math for that number is pretty simple. There's about 750mhz (or so) or RF spectrum avaible, divided into 6mhz "channels". Why 6mhz? Because that's about how much spectrum you need to deliver an uncompressed analog NTSC AV signal - in the digital world, that translates into (about) 40Mbps. So 40*125 = 5 (you know, adjusting for decimal places).
That sounds like a big number, and it is, but there are a few mitigating factors, as discussed last time.
First, it is a "shared" connection. There a certain number of households grouped into a "service group", usually between 200 to 2000 (very broadly), which connect to some physical networking gear at the cable plant (I use the term "plant" very loosely here). Within that service group, DOCSIS (the cable networking data interface protocol) basically works like a form of encrypted ethernet. Everybody in that service group sees all the packets, but cannot decode those packets.
So right off the bat, your effective sustained speed (more on this concept in a bit), is 5Gbps divided by [number of homes in your service group].
Additionally, some portion of that spectrum, those channels, is consumed by television - In fact, almost all of it. Today, only a single 6mhz channel is allocated to your High Speed Data (HSD) connection. That's a big part of what DOCSIS 3.0 promises - the ability to "bond" channels to effectively multiply the available bandwidth by N number of 6mhz channels.
Assuming there's channel spectrum to allocate...
In digital form, some 10 to 16 or so Standard-Def (SD) channels can fit in a single 6mhz channel (multiplexed into a single MPEG container over that channel, for those curious - this is also important because it has implications for compressions; specifically regarding CBR v. VBR). Two to maybe 3 or four High-Def (HD) channels can fit in the same 40Mbps. The range incidentally, is largely a function of compression quality per digital channel; this is probably worth a future post.
Short version: you get either 1 analog channel, 10 to 16 (or so) SD digital channels, or 2 to 4 (or so) HD digital channels.
Thr rub is this: most of the U.S. is still analog. Or at least, enough of it that most cable operators carry around 80 or so analog channels (out of a possible 110 or so). Then they consume another 6 to 8 or so "double carrying" the same channels in digital form, and the rest is allocated to HD channels (triple carrying many channels) and VOD (Video-On-Demand - more on how this works in a future post also).
Which doesn't leave a lot of room for your HSD connection.
Interesting, the core technology and bandwidth available compares reasonably favorably even with newer technologies like optical fiber (remember that we're talking about the connection to the home from the "edge" of the network - "inside" the cable network is often optical fiber, already; the challenge here is the "last mile"). Mostly the advantage of networks like FiOS is smaller service group sizes (owing to larger capital investments and other "late mover" advantages), and less legacy encumberances.
11 comments:
Is the bulk of the analog hold-over in old analog STB's still in consumer hands or is it people with CATV compatible TV's and coax wired directly to the TV? If it's mostly the former then it's well with the Cable company's control to migrate people off of analog at a pace that they determine (capital costs in all the new STB's required aside).
Any relief coming when the FCC mandates digital for OTA transmissions and everyone is going to be expected to have a STB of some kind anyway? i.e. even if that doesn't directly provide relief, seems like a jolting enough of an event to the end-user that it would be a good time to do the same.
It's actually a really interesting and classic problem if you look at the whole network and include things like the in-house DVR into the picture. All sorts of possibilities for leveraging multicast, pre-caching things close to the end user (say when a particular show is going to be promoted on VOD), etc. Your basic multi-level cache architecture, just on a much larger scale.
And while I'm taking a break from alleyinsider and reality (filling your blog with my random thoughts ;-) ) - I'm kind of surprised that none of the VOD systems are looking at what is working with Netflix and Tivo with community ratings and feedback loops and providing a similar capability. The interaction with the end users is so 1990.
Alas, its mostly the latter - roughly half of people just plug the coax into their "cable ready" (AKA analog tuner) TV.
In terms of CDN and precaching - yes, though conditional access (content security), rights management, and content mgmt generally is still a little tricky, especially because the return path for most STBs (settop boxes) is really, really REALLY pathetic. Think 25Kbps (kiloBITS) or so, shared by 200 to 2000 homes...
Yeah - that VOD thing is great, but lame; wish someone would do something with that ... :P
Yeah I’d echo Pat’s comment about this being so 1990. I’d thought there is something more interesting on the front burner in those cable shops, but apparently not. So cable continues to run the video apps on the more or less legacy topology while the voice products are on IP, while with Fios it’s the opposite, video on IP while voice routed through the legacy systems through the backend… it’s easier to move voice to IP than to move video to IP so we shall see. Aren’t cable guys playing with IMS? Or do you think a flash mail client is more important? Yuk.
Pat, you are not still wasting your great talent at that dead place are you?
Yeah, I'm still chugging along in my little pocket of excitement in what is rapidly turning into a wasteland. I get to work on my own self-contained projects for the most part and get paid for it so it's a hard gig to walk away from if you can get it.
Hey only a decade behind isn't bad, all things considered :)
The problem space isn't quite the same (mostly from a "starting set" perspective), and the volume of content is pretty large, by any standards.
See slide 4 of this.
That said, I do agree that the multicast video distributiom model is in serious transition to an IP-based on demand (in the technical sense) delivery scenario.
Not sure I agree about the "which-is-easier" argument - routing and on-net/off-net issues make video easier, I think. But its proabably moot, the proof will be in execution, not architecture.
I'm not sure how much clustering there is on content (particularly for VOD which is the only non-multicast video that I'm aware of) but it's a shame that you can't use off-hours, multicast and unused space on DVR's to pre-deliver expected hot VOD titles (like the first week something comes out or a video that's going to be promoted).
Granted, this would only work for the households with a DVR and I don't have a real sense for how much bandwidth is used up by VOD (like is it actually worth the effort) but if there's a high correlation to DVR's and VOD users it could easily free up some bandwidth.
It'd be a shame to try to completely move away from multicast given most IP networks would kill to have real multicast support out to the end users.
Oh, and I'd probably round it off to 2 decades at this point (17 years is much closer to 20 than 10) ;-)
In the end, there's really nothing magical about "IP". If you have a way to address a stream of data to a particular device efficiently then IP doesn't really buy you anything except for headaches around buffering, guaranteed delivery, etc.
FWIW, I think voice is a harder nut to crack with QOS and real latency requirements. Granted, a lot of groundwork was done with SIP but from a networking path it's a lot harder to deliver a low-latency jitter-free connection than it is to bulk deliver a stream of data in a single direction.
Fiber baby!
Last Result:
Download Speed: 93792 kbps (11724 KB/sec transfer rate)
Upload Speed: 19830 kbps (2478.8 KB/sec transfer rate)
http://www.speakeasy.net/speedtest/
Pat, that's pathetic. but then I certainly understand, that darn place poison people's mind.
There is no magic about IP in a technical sense. But certain combination of architecture and business model create the chance for other parties to participate in the value chain and no I am not talking about thousands of passionate home broadcasters blabing about their personal spiritual freckiness; Or integrating consumer's other behavior pattern on devices such as that little computer running OSX in your pocket. Yes it's all in the execution, but there is a difference in executing what. not that I disagree with you in such a significant way, but those cute new generation of Flash stuffs that usable by anyone and everyone add no value to my CMCSA shares. I guess I will be safe betting on T and VZ and against TW and CMCSA for the next few quarters now.
I'm still not sure I quite get what value would be added by IP specifically. As long as you need to physically attach the coax cable to a box of some kind, the actual transport doesn't matter as long as it's well defined and documented (standard would be a nice bonus). Even though VZ uses IP, it's IP over coax and still has to go to the STB for CA and decoding. CableCard and OCAP are probably doing more for opening up the platform for others to inject value than an IP solution would.
Just because something's over IP doesn't necessarily make it easier. There are so many envelopes around the actual video itself that it probably actually makes the situation worse (i.e. I seriously doubt it's implemented as RTSP so what's the actual protocol for negotiating the bitstream, buffering, fallback, etc - what envelope is wrapped around the actual video stream?).
ATSC and QAM are nicely documented and if it weren't for the CA encryption on the feeds, everyone and their brother could be creating value-added products.
Most of this is about the last-mile. There's a fair amount of value in being able to use IP for the backbone and distribution networks so you can use commercial off-the-shelf routing, switching and transit.
BTW, I'm pretty sure VZ uses IP for VOD mostly to keep it out of the wavelengths they are using for multicast video delivery so they can keep those channels specifically for video and not have to eat into it for IP and VOD. That way the get the benefit of using standard CMTS equipment for their video and not have to worry about eating up channels for other uses.
Stupid question, but I couldn't easily find it documented anywhere so I figured to ask - How much of the 6Mhz channel is wasted as a buffer between channels? I assume it's because of a ton of legacy equipment but it strikes me as odd that everything is based on the per-channel level of granularity in the cable system. Would you get the same amount of bandwidth by bonding 10 6Mhz channels logically as you would by using the frequency space occupied by 10 consecutive channels and treating it as one big channel? Depends on how wide the gaps are between channels but I would have figured that would allow you to get rid of 18 of the frequency buffers within the block.
Guess it depends on how hard-up you are for extracting more bandwidth out of the system (assuming my understanding of the analog part of the system is even remotely accurate).
Yeah, me again...
Sort of wondering what the efficiency of your upstream IP bandwidth looks like. Downstream is easy since you have one source controlling all of the bits it can schedule them as needed and get up to 100% efficiency/utilization on the available bandwidth. For upstream you have collisions, scheduling, etc. so the actual achieved efficiency is somewhere under 100% (how far under and how it varies by node size would be really interesting).
Thought that would make for a more interesting "secret" on bandwidth and tieis in really well with my earlier question on P2P :-)
Assuming a closed system and only P2P traffic, the upstream and downstream requirements end up being equal (assuming you're actually downloading 100% of the time). The shared bus upstream link for cable seems to be a particularly painful hurdle.
Post a Comment