1. The Design Philosophy of the DARPA Internet Protocols D. D. Clark

2. Main Issue The design philosophy: Why was the Internet Service designed this way? –Connectionless –Packet switching –TCP (or other transports) over IP Why should we care?

3. Fundamental Goal Ability to interconnect/integrate different types of existing networks –Packet switching technique for multiplexing –Interconnecting networks by Internet packet switches, i.e. gateways  Packet switched communication networks that is an interconnection of a group of separate networks

4. Ordered list of 2 nd level Goals Survivability despite loss of network of gateways Support for multiple types of services Accommodate variety of networks Support for distributed management Cost effective Low effort for host attachment Accountability  Why ordering of these goals matters?

5. Survivability Un-interrupted service even when networks or gateways are failing –Network should reconfigure and re-establish connectivity after a failure. exception?  State information should be protected, Why? How?  Where should the state be kept?  Replicating state in the net, or keep it at end points?  Fate Sharing: keep the state at end points  State will be lost when end host is lost

6. Fate Sharing Benefits –robust against any number of failure. How about replication? –Easier to engineer than replication Consequences –Intermediate switches are stateless –Trust/functionality is placed on the end systems Ability to interconnect is more important than survivability –Otherwise, failure reporting func could have been added to net to improve survivability

7. Type of Service Variety of services should be supported –Service => specific speed, latency, reliability –One solution (e.g. TCP) does not fit all Reliability, complexity is not always needed Several transport services are required and should co-exist  Separate TCP from IP  TCP (reliability) is a service on top of IP  IP: basic block to build various services  The datagram => Best-effort

8. Where should diff. services be implemented? In the network or at end points? –e.g. network QoS Goal: to support various (transport) services at end hosts on top of IP This is difficult w/o explicit net support. –Example? Placing min func in the net (i.e. IP)  Flexibility

9. Supporting Net Heterogeneity Making min/basic assumptions about the network – network can deliver pkts with decent size Why pkt size matters? –Reasonable reliability (1%) and addressing No assumption about speeds, delays, reliability, in-order delivery, etc.  Flexibility to interconnect different net tech.

10. Other Goals Distributed management was met –Different networks own/managed by diff org –It was (and still is) a hard task to do this right e.g. routing policies Efficiency (cost effectiveness) is not always achieved –Overhead of headers for small pkts, retx Overhead of attaching a host could be high since end hosts are more complex Accountability was considered but no supported

11. Architecture & Implementation The network arch should not constrain the range of provided services  Properties of provided services depend on capabilities of a particular “realization” (end-hosts and a network).  e.g. observed bw in 1200 bps line vs 1 Mbps link  Realization => Performance of provided services Design often focuses on correctness rather than performance Relationship between net performance & arch is hard because: –Hard to formalize performance –Goal was to accommodate variability, not performance