In a collaborative system the components can all operate on their own whether or not they participate in the overall system. Does this represent a cost penalty to the overall system? Does it matter? Discuss from the perspective of some of the examples (Please use the examples below to answer the questions)

Collaborative system examples Systems built and operated voluntarily are not unusual, even if they seem very different from classical systems engineering practice. Most of the read- ers of this book will be living in capitalist democracies where social order through distributed decisions is the philosophical core of government and society. Nations differ in the degree to which they choose to centralize vs. decentralize decision making, but the fundamental principle of organization is voluntary collaboration. This book is concerned with technological sys- tems, albeit sometimes systems with heavy social or political overtones. So, we take as our examples systems whose building blocks are primarily tech- nical. The initial examples are the Internet, intelligent transportation systems (for road traffic), and joint air defense systems. The Internet When we say "the Internet" we are not referring to the collection of appli- cations that have become so popular (e-mail, World Wide Web, chats, etc.). Instead, we are referring to the underlying communications infrastructure on which the distributed applications run. A picture of the Internet that tried to show all of the physical communications links active at one time would be a sea of lines with little or no apparent order, but, properly viewed, the Internet has a clear structure. The structure is a set of protocols called TCP/IP for Transmission Control Protocol/Internet Protocol. Their relationship to other protocols commonly encountered in the Internet is shown in Figure 7.1. The TCP/IP suite includes the IP, TCP, and UDP protocols in the figure. Note in Figure 7.1 that all of the applications shown ultimately depend on IP. Applications can use only communications services supported by IP. IP, in turn, runs on many link and physical layer protocols. IP is link friendly" in that it can be made to work on nearly any communications channel. This has made it easy to distribute widely, but prevents much exploitation of the unique features of any particular communication channel. Web Application Web Application Web Application TCP UDP Others Ethernet X.25 HDLC Others Figure 7.1 The TCP/IP family protocols are based on distributed operation and management. All data is encapsulated in packets, which are independently forwarded through the Internet. Routing decisions are made locally at each routing node. Each routing node develops its own estimate of the connection state of the system through the exchange of routing messages (also encap sulated as IP packets). The distributed estimates of connection state are not and need not be, entirely consistent or complete. Packet forwarding works in the presence of some errors in the routing tables (although introduction of bad information can also lead to collapse). The distributed nature of routing information, and the memoryless for warding, allows the Internet to operate without central control or direction. A decentralized development community matches this decentralized archi tecture. There is no central body with coercive power to issue or enforce standards. There is a central body which issues standards, the Internet Engi- neering Task Force (IETF), but its practices are unlike nearly any other standards body. The IETF approach to standards is, fundamentally, to issue only those which have already been developed and deployed. Almost any body can go to the IETF and try and form a working group to build standards in a given area. The organization accepts nearly any working group that has the backing of a significant subset of participants. The working group can issue "internet-drafts" with minimal overhead. For a draft to advance to the Internet equivalent of a published standard it must be implemented and deployed by two or more independent organizations. All Internet standards are available for free, and very strong efforts are made to keep them unen- cumbered by intellectual property. Proprietary elements are usually accepted only as optional extensions to an open standard Distributed operation, distributed development, and distributed man agement are linked. The Internet can be developed in a collaborative way largely because its operation is collaborative. Because the Internet uses best- effort forwarding and distributed routing, it can easily offer new services without changing the underlying protocols. Those new services can be implemented and deployed by groups that have no involvement in devel- oping or operating the underlying protocols; but only so long as those new services do not require any new underlying services. For example, groups were able to develop and deploy IP-Phone (a voice over the Internet appli- cation) without any cooperation from TCP/IP developers or even Internet service providers. However, the IP-Phone application cannot offer any qual ity of service guarantees because the protocols it is built on do not offer simultaneous delay and error rate bounding In contrast, networks using more centralized control can offer richer building block network services, including quality of service guarantees. However, they are much less able to allow distributed operation. Also, the collaborative environments that have produced telecommunications stan- dards have been much slower moving than the Internet standards bodies. They have not adopted some of the practices of the Internet bodies that have enabled them to move quickly and rapidly capture market share. Of course, Carrely becording and underly The TCP/IP family protocols are based on distributed operation and management. All data is encapsulated in packets, which are independently forwarded through the Internet. Routing decisions are made locally at each routing node. Each routing node develops its own estimate of the connection state of the system through the exchange of routing messages (also encap sulated as IP packets). The distributed estimates of connection state are not and need not be, entirely consistent or complete. Packet forwarding works in the presence of some errors in the routing tables (although introduction of bad information can also lead to collapse). The distributed nature of routing information, and the memoryless for warding, allows the Internet to operate without central control or direction. A decentralized development community matches this decentralized archi tecture. There is no central body with coercive power to issue or enforce standards. There is a central body which issues standards, the Internet Engi- neering Task Force (IETF), but its practices are unlike nearly any other standards body. The IETF approach to standards is, fundamentally, to issue only those which have already been developed and deployed. Almost any body can go to the IETF and try and form a working group to build standards in a given area. The organization accepts nearly any working group that has the backing of a significant subset of participants. The working group can issue "internet-drafts" with minimal overhead. For a draft to advance to the Internet equivalent of a published standard it must be implemented and deployed by two or more independent organizations. All Internet standards are available for free, and very strong efforts are made to keep them unen- cumbered by intellectual property. Proprietary elements are usually accepted only as optional extensions to an open standard Distributed operation, distributed development, and distributed man agement are linked. The Internet can be developed in a collaborative way largely because its operation is collaborative. Because the Internet uses best- effort forwarding and distributed routing, it can easily offer new services without changing the underlying protocols. Those new services can be implemented and deployed by groups that have no involvement in devel- oping or operating the underlying protocols; but only so long as those new services do not require any new underlying services. For example, groups were able to develop and deploy IP-Phone (a voice over the Internet appli- cation) without any cooperation from TCP/IP developers or even Internet service providers. However, the IP-Phone application cannot offer any qual ity of service guarantees because the protocols it is built on do not offer simultaneous delay and error rate bounding In contrast, networks using more centralized control can offer richer building block network services, including quality of service guarantees. However, they are much less able to allow distributed operation. Also, the collaborative environments that have produced telecommunications stan- dards have been much slower moving than the Internet standards bodies. They have not adopted some of the practices of the Internet bodies that have enabled them to move quickly and rapidly capture market share. Of course, Carrely becording and underly Instead, we are referring to the underlying communications infrastructure on which the distributed applications run. A picture of the Internet that tried to show all of the physical communications links active at one time would be a sea of lines with little or no apparent order, but, properly viewed, the Internet has a clear structure. The structure is a set of protocols called TCP/IP for Transmission Control Protocol/Internet Protocol. Their relationship to other protocols commonly encountered in the Internet is shown in Figure 7.1. The TCP/IP suite includes the IP, TCP, and UDP protocols in the figure. Note in Figure 7.1 that all of the applications shown ultimately depend on IP. Applications can use only communications services supported by IP. IP, in turn, runs on many link and physical layer protocols. IP is link friendly" in that it can be made to work on nearly any communications channel. This has made it easy to distribute widely, but prevents much exploitation of the unique features of any particular communication channel. Web Application Web Application Web Application TCP UDP Others Ethernet X.25 HDLC Others Figure 7.1