To: Natedog who wrote (9157 ) 11/12/2000 11:47:39 AM From: Frank A. Coluccio Read Replies (1) | Respond to of 12823 Nathanc, Forsooth! For the record, there was no implied message in my writing "delete." It certainly was not a personal attack, nor was it a slam at your earlier message. My original message was a ramble, something that I got into at length, and it really didn't address your post, so I deleted it. Sorry for the confusion. The essence of what I wrote in that earlier message can be found in parts of this very good article on Video on Demand -VOD- that I picked up in America's Network Magazine. Note the author's observations about the nature of the challenges that each media type must face and overcome (I've snipped some of this and pasted it below). Unfortunately he doesn't adequately address xMDS or any other form or wireless. Which is really strange! Nor does the article make a case for FTTH in explicit terms. I suppose that one could read several messages into the absence of both of these platforms in his treatment, as well.VOD: Life after Death Beaten down by years of disappointment, video on demand is finally showing that it can survive in a consumer-driven marketplace. But do providers have the heart to give it another shot? - By Dan Sweeney Complete article:americasnetwork.com Here's a snippet:First of all, it [vod] requires a high speed network meeting stringent conditions of latency and throughput. Strong arguments can be made that networks capable of meeting the requirements of large scale video deployments do not exist. All VOD deployments to date have been over hybrid fiber coax CATV systems or DSL networks. Neither platform as it is presently constituted is ideal. CATV cable systems are still overwhelmingly analog and have no provisions for statistical multiplexing or QoS. Indeed, most of the available bandwidth is inflexibly dedicated to circuit video. DSL services , on the other hand, provide dedicated circuits to each subscriber and ATM, frame relay, or IP with QoS on the backbone, which makes them inherently better adapted to VOD, but (fac edit: DLS's) generally low throughput speeds of existing services are highly problematic. The new VDSL services provide the requisite speeds, but are so limited in range and so dependent upon high quality plants, that their ultimate success in the marketplace appears in doubt. "Existing infrastructure is still pretty marginal," admits PassEdge’s Plymale. "What we really need is IP video with QoS provisions and tunneling, and we’re not there yet. Obviously, it’s not gonna come overnight." Dan Sheerin of n-CUBE sees other changes required as well. "Two to five channels have to be allocated to the VOD function and to do that without cutting into broadcast, you need to digitize all of the video. You also want to limit the number of homes on a single cable to no more than a thousand." Some industry observers believe that extra capacity isn’t really needed, citing average usage rates of three to five orders per subscriber per month, a figure based primarily on past experience with pay per view. But, others, including Cox and Blockbuster, are suggesting implementations of VOD that go considerably beyond occasional movies on demand and would utilize the capabilities of the system to perform what is in effect time shifting, accessing regular television programs or specials from a database and viewing them outside of their normal time slots. Time shifting via VCRs or digital storage based devices such as TiVO has historically been eschewed by most viewers, and some would argue on that basis that a VOD variant would not tax network capacity. Ignored in such arguments is the sheer convenience of a time shifting function that does not demand the viewer to program a recording device. The fact is that no one knows because the service has never been offered. Whatever the ultimate mix and quantity of VOD services, sheer network capacity and flexibility isn’t the only requirement for putting VOD services in place. VOD works on a client-server model, and in this case the servers are specialized video servers while the clients would normally be set top boxes though they could be specialized modems. Both are expensive and are not being shipped in quantity at the present time. Video servers themselves are massively parallel supercomputers utilizing special devices and bearing little resemblance to ordinary data servers. Instead of primarily supporting random access and bursty transmissions, video servers must support high continuous data rates without interruptions and sequential access file retrieval, and must normally support a variety of protocols as well, including IP, IP multicast, ATM, and MPEG-1,and MPEG2 streaming. Terabit memory is an absolute requirement in a commercial system as is the ability to output hundreds if not thousands of simultaneous streams. The actual designs in use today are strictly proprietary in most respects, but the Oracle Video Client Server software is becoming the de facto standard for linking the servers with the set top boxes. There is actually much more to this piece. I suggest that you go to the url above. It contains some good historical anecdotes, such as the Orlando FSN and the earlier n-Cube trials, and some good notes on the evolution of this space from both the telco adn cableco perspectives. FAC