To: Mkilloran who wrote (9789 ) 12/17/2000 7:30:27 PM From: Frank A. Coluccio Read Replies (2) | Respond to of 12823 Mkilloran, Thanks for the wealth of stimulating and provacative issues and information that you've brought to the thread this evening. It's apparent that you've done your homework, although I would caution, as MikeM has, that there is quite a bit of marketing vapor out there passing itself off as information. But I suspect that many of the vendor claims will materialize and come true, even if the eventual time frames and actual deployment scenarios result in rendering the current predictions skewed. What I find disconcerting to some extent, from a networking perspective, is the closed-endedness of the architectures that support these features. There is a hint that there will be linkage to Internet-related functionality, as you have described (where the STB knows what you are looking at and keeps score), but I suspect that there is a strong possibility that it's going to be a one way street. Because, as I have read them (I've delved into STB architectural issues and features before, abeit not enough it seems), there is a certain captivity, which is characterized by a set of constraints and lock-outs that run directly against the grain of open networking. For example, in some subtle but critical ways some features on these platforms (like those that will depend on end point to end point (e2e) IP networking) will not play very well with Internet, unless kludginess is built into their gateways and routers, which would be necessary to marry the attributes of a VPN with those of the greater 'Net. And here, again, it would be up to the discretion of the cable operator to either permit or deny those features. We see this already in regular cable modem services, where certain types of interaction are outright blocked, because admitting them could cause congestion at this time. Then again, maybe the momentum is shifting the other way, from "open" networking to proprietary designs where each vendor-service provider combination locks in their end users in their own unique way. We've seen this before, haven't we? Remember Wang? Anyone care to comment on this? Yes, a closed network is one way in which the industry standards-setting bodies allow its service providers the ability to lock in their customers. This technique is particularly handy when there is no other way to differentiate one self in an environment that is starved of competition due to Rights of Way issues and the entrenched kinds of "loyalties" that usually follow in such circumstances. Or, at least that is how it was perceived prior to the advent of the 'Net as we now know it, and prior to the prospects of fiber overbuilders encroaching on their serving areas. And lest we forget, it *was* during those earlier days when the roots were set for what we see coming onto the market today, not only for HFC, but for DSL and PONs, as well. But I suspect that many customers would prefer to _not_ be locked in, per se. I can't quite articulate what it is, yet, but there is something here that will not scale with the rest of the 'Net, and therein is where a degree of peril lies for service providers and end users, alike, IMO. There are two ways to deliver services to customers, the open way and the closed way. The ways that you have expanded on tonight are all closed ways, which will very likely win over the masses, at first. But I believe that for some users this will come at the expense of some future disappointments, as new RFCs and the applications they support materialize, down the road. And let's not forget the enabling characteristics of future super high bandwidth platforms that will make all of these features which depend on compression and widgetry, moot. In the end, maybe this says something about open networking. And why many of the expectations of the bubble brats never truly materialized as they had hoped. Because, ultimately, it's difficult to monetize openness. Can it be done at all? How? Comments and corrections welcome. FAC