![]() |
![]() |
|
![]() |
![]() |
![]() |
The first compelling reason to PC-fy intermediate network nodes is the time to bring new technologies to the market place. No better example exists than the evolution of multimedia technologies. It is difficult to purchase a PC that does not incorporate very powerful multimedia capabilities. But the network technologies to take advantage of these end-node capabilities may have to wait 5-10 years before they reach the market. The reason is simple, the communications industry has created a paradigm of standardizing interfaces through complex, committee processes. Within a closed-box industry, standards are required for the interactions along the wires that connect closed boxes of multiple vendors. This requires committees and very long processes. It can take nearly a decade to introduce a substantial new technology. Even more trivial incremental changes in technology (e.g. the transition from 10Mb Ethernet to 100Mb Ethernet) requires a few years of deliberations. (Contrast this with similar incremental changes in processor speeds, memory size or disk capacity.) This long cycle to create and deliver new communication technologies to the market often results in great uncertainty. Vendors cannot be certain that their investment in pursuing a "standard" will yield adequate value. The avalanche collapse of the OSI standards is an excellent example of this uncertainty. Vendors collectively invested several thousands of person-years in OSI over 20 years (some still do) in just developing complex standards that have never accomplished more than a miniscule market impact. This is not account for significant investment in development of products based on these standards. A somewhat similar situation may be replayed through the ATM standardization efforts. It is already becoming evident that alternative technologies may accomplish much more cost effective broadband communications at substantial lesser complexity to build and operate. Only time will tell whether ATM designs through committees can compete with alternative solutions created through agile innovative vendors (e.g., 1Gb Ethernets, label-switching and other fascinating recent developments). A second and important factor to shape the future of the communications industry is the economics of its products. Loosely speaking one can compare the relative shares of software and hardware components involved in an intermediate node. In general, the share of software, measured in total investment in development and in its contributions to competitive edge, is substantially larger than the value of hardware and continues to grow. A closed-box vendor can leverage the investment in this software only on the market base of its customers. The result is an enormous economic inefficiency where vendors invest immense resources to replicate development of software, rather than build on previous components developed by others; and then, sell this software to a small market segment. This problem is not addressed by the current frenzy of acquisitions. Large vendors merely replicate the software development over their different products and then sell these to a fraction of their market. A new market structure that permits a vendor to develop and sell their software to the entire market will offer substantial greater efficiency to both vendors and their consumers. This economic inefficiency is the key force responsible for the lack of manageability in current networks. Users expect box vendors to bundle management software solutions with their box. But vendors cannot expect direct returns on investment in such software. Nor can other vendors build effective management software solutions that can handle the large variety of proprietary boxes. The entire industry and its users are locked in paradigms that create enormous hurdles to progress. Finally, it is interesting to note that the communication industry still maintains frozen conceptual paradigms of rapidly decreasing relevance. For example, intermediate nodes are difficult to distinguish from end nodes architecturally. Both node types are boxes that have buses to which various forms of cards are attached to perform useful processing functions. In the case of end nodes, one standardizes the bus interfaces and then anyone can build cards that offer useful functions. In the case of intermediate nodes, the bus is proprietary and the function provided by the cards attached to it are standardized. When this wire-based approach to standardization governed hardware interactions it was a viable competing alternative to standardizing bus interfaces. However, in a communication world shaped by software and applications this makes decreasing sense. Software functions are best standardized through appropriate API, rather through the syntactic structure of the bits and bytes that the software components exchange. An API, in analogy with bus interfaces, hides the details of internal component interactions and allows modular and efficient evolution. In contrast, standardizing the syntax of bits exchanged (protocols), analogous to wires, is often a poor method to develop, change and evolve software. When the functions supported by the software become complex, the protocol "standards" for their bit-level exchanges no longer allow simple and effective development. The collapse of OSI is an illustration of the limits of wire-based thinking in standardizing complex software functions. Furthermore, in a world of Gbs networks, the plastic boundaries of boxes which wires cross are insignificant. There is no reason why the motion of bits through these wires to support applications software be subject to different paradigms than other data traffic, say from attached disk to display. Now try to imagine the computing industry if application developers had to conceptualize a word processor in terms of the syntax of accessing bits on the disk surface or sending them to a screen. And what if these wire-oriented paradigm for building software were to be developed by standards committees? |
![]() |
|
[NetScript] [Publications] [People] [Download] [Links] |
![]() |
![]() |
Distributed Computing and Communications Lab |