=================================================== From takhoa@owlnet.rice.edu Wed Jan 21 17:56:47 2004 =================================================== This is not a controversal paper because it only re-tells history. It's interesting to see how early decisions fit well within the end-to-end argument. For example, according to the paper, building a network that assumes too much (such as reliable delivery) is not a good idea since it cannot support different types of service. It's also interesting to know that TCP and IP were originally a single protocol and later split to support a more modular and end-to-end structure, and that UDP was introduced to complement the purpose of TCP. The author also gives answers to why some of the the pressing issues with the Internet, such as accountability and performance, were not addressed in the original design. Due to the fact that the Internet were originally designed for the military, it makes sense that a circuit switched network is not acceptable. For those who criticize the design of the Internet, a historical look back at its intial purpose shows that the Internet was very well designed to the original specification and requirements. The need to retain state information was cleverly answered by making end hosts and individual packets responsible, thus alleviating the need to rely on the stability of the underlying links. Regardless of the difficulty in understand and simulating the behaviors of the Internet, I am impressed with how insightful "back-of-envelop" analyses were. However, since ideas shaping the Internet today have been refined and morphed (sometimes akwardly) from those original analyses, it is easy for us to relate the original analyses to the sucess of the Internet and credit their insightfulness. Different analyses might have been more insightful and offer a better evolution of the Internet. However, since there are no other "Internet"s today to compare with, it is difficult to gauge the insightfulness of those original analyses. =================================================== From gulati@cs.rice.edu Wed Jan 21 21:20:38 2004 =================================================== The design philosophy of DARPA internet protocols This paper talks about the original properties that were desired from protocols like IP and TCP with major focus on IP. The IP was designed primarily for military use and internetworking diverse networks used by defence agencies. So survivabilty and ability to support heterogeous networks were given importance over accountability of resources and cost effectiveness. Ability to route around failures required hosts to maintain all the state associated with a flow and network to just store and forward the packets. This put all the complexity and decision power in hosts rather than network. TCP was integrated with IP to add reliability to the network. Later on with the advent of new applications like XNET, multimedia and voice transfers, it was realized that TCP can't support all services and it was separated from IP to coexists with UDP(it provides fast, but unreliable transport over IP) in a higher layer. Hence IP was defined just as a means to route packets by acting as a glue to connect heterogenous networks and thus minimal set of features required by all the services above IP were included in IP. This allows multiple applications to use IP according to their own characteristics and usage requirements. Although both TCP/IP are in both military and commercial use today, some of the design choices that were made earlier doesn't match the needs of users today. So active research in areas of accounting, performance improvement, cost minimization is required to make TCP/IP work for future applications. =================================================== From twngan@cs.rice.edu Thu Jan 22 06:23:55 2004 =================================================== After 15 years of development of the IP protocol and related packet switched networking, this paper tries to provide the rationale and the design philosophy behind the decision choices. It was mostly influenced by DARPA's goal of providing "effective" techniques, which emphasizes on survivability and interoperability. As a result, many other desirable features are not incorporated into the design, such as accounting and resource management. The author suggests a more virtual circuit-like building block instead of pure datagram; the basic idea is to have "flows" of data and soft states. =================================================== From animesh@cs.rice.edu Thu Jan 22 15:00:25 2004 =================================================== Review ( The Design of the DARPA Internet Protocols) ------ This paper describes the design rationales behind the development of the TCP/IP architecture. The main goal was to design an architecture that would allow to interconnect the diverse existing networks. They proposed packet switching as a technique multiplexing these diverse networks and the datagram was would thus serve as an entity which is transported across the underlying networks. The other goal of the architecture was to recover from transient failures of intermediate gateways/ networks and for this purpose they decided to keep all state related to the connection at the endpoints. They called this technique fate-sharing. The other design goal was to support varied services with different requirements of latency/bandwidth/reliability. Providing some or all of these guarantees at lower layers would imply overhead for applications that might not need them. It was decided therefore that the architecture be layered into IP layer which dealt nly with the transmission of the datagrams with 'best effort' and a higher TCP layer whcih could provide the reliability guarantees to applications that might need it. There were other requirements from the architecture like distributed management of resources which figured low in the priorities and incorporating these goals into the design are still ongoing research. Ieas of using notion of flows for accounting and mananging resources have been suggested. =================================================== From anwis@cs.rice.edu Thu Jan 22 15:15:49 2004 =================================================== The Design Philosophy of the DARPA Internet Protocols This paper discusses the motivation behind why the TCP/IP suite is how it is at present. The main design goal was to interconnect heteregenous networks into a large internetwork efficiently. Since packet switching was well understood, and the individual networks were packet switched, the decision was made to create an internetwork via gateways that were simply packet switching processors. A wide variety of networks are supported by requiring that the network simply provide a best effort service and have the ability to send a single packet to the correct destination. More complex needs, such as reliable delivery or provision of multiple levels of service could be provided by higher layers. Otherwise, these services would have to reimplemented for every network and for every host interface to the network. Two other important design goals were also to survive in case some portion of the network failed and to provide a variety of service. To protect against network failure, the designers decided to implement all state information in the end-hosts rather than the intermediate nodes. Thus, the intermediate routers are purely packet switched and the complexity of implementation is put upon the end hosts. Of course, the advantage here is that information for a host will be lost only if the host dies when it is not needed in any case. The original TCP protocol was meant to provide a service for different requirements such as speed, latency, and reliability. However, it was quickly realized that the needs of applications outstripped the service that could be provided by one transport layer. This realization forced the separation of TCP and IP into two separate layers. IP would provide best-effort service and would form the building block upon which more demanding transport protocols could be built, such as those requiring reliable in order delivery. The author clarifies that datagrams were not designed simply because applications require them, but because they were to form the building blocks of higher layers as mentioned above. In fact, most applications require more service than a pure datagram can provide. The designers of the original TCP/IP suite did not wish to constrain the implementors with irrelevant details because they realized that the implementation would be different for 1200 bps phone lines and 1Gbps optical links. Therefore, the designers were only concerned with forcing logical correctness of the implementation. However, they soon realized that performance was just as important as logical correctness, but unfortunately, there were not any formal tools to describe performance. Finally, the author discusses the rationale behind some of the important developments of TCP. For example, the designers decided to acknowledge bytes instead of packets to eliminate the problem of packets will a small number of data bytes. In other words, retransmissions of packets with one byte each would cause a flood of packet retransmissions. On the other hand, if bytes were acknowledged, then all the bytes could be gathered into one single packet for retransmission. =================================================== From mittal@cs.rice.edu Thu Jan 22 15:22:30 2004 =================================================== Paper 2 - The Design Philosophy of the DARPA Internet Protocols This paper seeks to explain some of the historical perspectives that have influenced the design philosophies behind the TCP/IP architecture. TCP/IP was basically developed by DARPA around 15 years ago. When TCP/IP was first proposed, the motivation was to have a technique that could utilize the existing interconnected networks. Since most of the applications being supported were served by packet switching technique, packet switching was accepted as the fundamental component of the architecture. Besides the primary goal, there were a number of subsidiary goals as well, which included network communication despite loss of networks, supporting multiple types of services and network architectures, distributing management of resources, cost-effectiveness, accountability of service use etc. TCP owes its evolution to the order in which these goals were assigned importance. For example, survivability was put as the first goal since the protocol was designed to operate in a military context. Similary, accountability was put as the last goal since it mattered the least. Also, the author feels that the relationship between architecture and performance is complex. However, there is no definite way of formalizing performance constraints within an architecture. The original ARPANET host-to-host protocol had flow control on basis of both bytes and packets. In TCP however, regulation of byte delivery was chosen, for several reasons : ability to permit insertion of control information, ability to break TCP packet into smaller packets if required and for acknowledging bytes rather than packets. Also, datagram is the basic entity tranported over the network. Datagram is a building block over which services should be built. In short, the paper highlights some of the decisions that contribute to the present architecture of TCP/IP. It has met with the goals that it was specifically designed for, those related to defense and military operations. It remains to be seen what modifications these protocols would undergo when the major objectives would be accountability, real-time communications, security and reliability of data transfer etc. The evolution would continue to be monitored by requirements and desires, and it is inevitable that effort would be to 'hack' the existing architecture rather than a redesign each time, purely because of legacy and backward compatibility. =================================================== From santa@cs.rice.edu Thu Jan 22 15:30:10 2004 =================================================== The Design Philosophy of the DARPA Internet Protocols The fundamental goals of the DARPA Internet Protocols in order of significance have been detailed by the author. The Internet has transformed from a military/educational network to a commercial network today and has changed the siginificance of some of these goals though. The primary goal was to develop an effective technique for multiplexed utilization of existing interconnected networks. The second level goals in order are: # Continue despite loss of networks and gateways. This gave rise to the end-to-end principle where all the complexity and state is stored at the endpoints and the routers themselves are stateless. # Support multiple types of communication. For example, low latency, high reliability, etc. This led to TCP and IP to be separated into layers rather than being in one layer as they initially were. # Accomodate a variety of networks. The very basic was expected from networks such as a minimum data packet size that the network must be able to handle. # Distributed management of resources # Cost effective. # Low effort. # Resources be accountable. This goal was the least important, and should have been pretty high up on the list had the Internet been conceptualized as a commercial network. =================================================== From amislove@rice.edu Thu Jan 22 15:50:16 2004 =================================================== In this paper, the author describes the design philosophy behind the Internet protocols, including IP, TCP, and UDP. This paper does not present the protocols (they had existed for a number of years before), but it aims to simply describe the experience gained from desiging and deploying the protocols. The paper begins by discussing some of the fundamental goals of the Internet protocols, including developing a effective technique for mulitplexed utilitzation of existing interconnected networks. The author then describes the other goals and how they were achieved, such as survivability, multiple types of service, multiple network types, distributed management, and cost-effectiveness. The paper describes in detail why TCP/IP was split into two seperate layers, and how UDP came into existence. The author also includes descriptions of some of the design decisions which shaped TCP which may not be clear from the RFCs.