CS 740: Advanced Computer Networks Aditya Akella Lecture 3: Design Principles Outline: - Layering and Protocols - IP Hour-glass design - End-to-end principle - Best Effort delivery - Fate Sharing - Soft State vs Hard state - Other design principles: Decentralized Management/Conservativeness - IP design weaknesses: Tussel in Cyberspace We will talk about some key design principles in the Internet, how they came about and their relevance in today's context. We will discuss ideas and principles from three papers: # [SRC84] J. Saltzer, D. Reed, and D. Clark, End-to-end Arguments in System Design, ACM Transactions on Computer Systems, Vol. 2, No. 4, pp. 195-206, 1984. # [Cla88] D. Clark, Design Philosophy of the DARPA Internet Protocols, In Proc. of ACM SIGCOMM '88. # [CW02] David Clark, John Wroclawski, Tussle in Cyberspace: Defining Tomorrow's Internet, ACM Sigcomm 2002. The first paper was the assigned reading for the class today. A. Layering and Protocols If you don't know what these mean, you should probably go sit in Cristi's CS 640. The Internet is a large communication system that provides and supports a variety of functions: transmission of bits, naming, addressing, flow control, routing... Layering is a way of thinking about how to implement these. Everyone is probably familiar with the TCP/IP layering: Applications, transport layer, IP, data link layer and the physical layer. Each layer is composed of modules called protocols which implement the functionality in a layer. The protocols offer interfaces: to higher layers, and to peers. Key protocols in the TCP/IP layering: you know what these are. B. IP Hour glass design Squint at the composition of the TCP/IP stack.. it has an hour glass design. With a thin waist --> IP. IP implements a minimal set of carefully chosen functions. IP is the glue that holds networks together and that allows different applications to work seemelessly on the Internet. Key to the interoperability and rapid evolution of the Internet. Some background on how IP came about: Internet in its early days was a collection of tiny groups of computers. The groups of computers, called a network, implemented their own protocols and mechanisms for communication. Made several design optimizations about packet size, reliability assumptions... IP was the way to get these to talk to each other. IP defines a common framing format that all communication must adhere to. So there, the choice to use a common network layer protocol is a key and perhaps the most important Internet design principle. The IP glue, and the underlying networks provide a basic communication substrate that is capable of carrying application bits from one point in the network to the other. But to work properly, Internet applications need a lot more functionality: reliable delivery, inorder sequencing, error recovery, real time constraints, encryption, a minimum amount of bandwidth. Should the network provide support for all these? C. End-to-End principle The end-to-end principle argues: No. This is a design guideline, not a rule. It can be broken, and it often is. Question: where to implement functions? End host vs network? We know that everything can be done at end-hosts. The question is should the network do some part of these as well? Lets go back to the functions we listed above and ask, what might go wrong if the network implemented them? Take encryption as an example: what is stupid about the network infrastructure providing support for encryption? Many problems: key management, trusting the network, data is insecure after the network is done carrying it. Most importantly, to the authenticity of the message needs to be checked before accepting it. This can only be done with input from the sending side application. So might as well have the application do it. Another example: reliable file transfer. Even if network provided reliable delivery guarantee a lot of things could go wrong which require the host or application to intervene (e.g. network card malfunction). Alternative to network providing reliable delivery guarantee is end-to-end check and retry. End-to-end principle: there are functions that can be correctly implemented only by the end points. Do not try to implement these fully within the network. So one of the arguments for implementing functionality in full at lower layers is that end-hosts need to do it anyway. Another argument is that it can make the network unusable for many applications. Reliability requirements could make network useless for real time applications such as voice and debugging. In such cases, not providing the functionality by default will force app designers to innovate if they want the function. But some times a part of the functionality could be implemented by the network as a performance optimization. E.g. reliability. End-to-end check and retry works best when probability of failure is low. Technique will work on first try. But if error rate is high, end-to-end check may be expensive and inefficient. So its useful for the network to put some effort into reliable data delivery. But the point is that the network need not be perfect. The key is that whatever part of the functionality the network implements is useful for performance, but cannot guarantee correctness. For correctness, we need full implementation at the end host. So what should be done at the network vs edge? - Reliable/sequenced delivery? - Addressing/routing? - Security? - Accounting? - Deep packet inspection? - Multicast? - Real-time guarantees? What is the definition of the "edge"? Does being liberal about the definition, and including edge networks, NAT boxes etc, make the e2e argument more powerful? D. Best Effort delivery A direct consequence of the end-to-end principle is the Internet's delivery model. The Internet provides a best effort delivery service: the network will do its best to deliver a packet with no guarantee of performance or even of eventual delivery. This is what the network layer implements. Most of the other functionality is at applications. Except one key function which is implemented above the network layer, but below the app layer - as part of the transport layer. This is reliable data delivery. No real reason to do it this way. Just that many applications need reliable delivery. So providing at the lower layer is an optimization. Note that TCP only guarantees reliability between kernels, not disks. So may still need some higher level checks (e.g. MD5 checksums). Consequences of best effort delivery: 1. all packets treated the same by default 2. the core of the network is very simple 3. all the smarts are at the edges, inside the end hosts. "Dumb network - smart edges": This is key to scalability of the network. But: 1. Is this really true today? 2. Does this pose hurdles for innovation? E. Fate Sharing The principle of fate sharing says that all crucial state should reside on the end-points. This is a crucial augment to the end-to-end principle: while e2e states who should do what, the fate sharing principle whether the network should do anything more than forward packets at all. So what can the network do apart from carrying info in a dumb way? It can track who is talking to who. It can remember how talkative some hosts are. It can store state about the conversations. Its possible that this may help make application design easier. But, whats bad about this? One of the key motivating factors behind the Internet's coming into being was the ability to keep communication going even in the event of major infrastructure failures. This means that end-points must be able to talk so long as there is a way for the network to carry their traffic. But if network keeps state and applications rely on it, then network foobars will affect end-host connectivity. This in turn impacts survivability. How about NATs or stateful firewalls? F. Soft state vs hard state So should the network store no state at all? Clearly, if the network stored state, then we can do a lot of cool things with this. For example, provide QoS, do accounting, policing etc. But as we saw earlier storing state is bad. But what if n/w stored state for short periods of time and flushed it afterward? Applications re-install state after the time out, or prevent getting flushed out by periodically refreshing. This is called "soft state", as opposed to "hard state" where the network holds long term information for all flows. This is a powerful tool to implement strong QoS guarantees as we will see. But it is not really used. G. Other design principles Be conservative in what you send and liberal in what you expect. Be a good social citizen. e.g. TCP congestion control; TCP receiver will receive and ignore bogus acknowledgements. This is an unwritten rule, and today's stacks implement it by default. Decentralization. Key to scalability. One instantantiation is in ownership and operation of the Internet. Each network in the Internet is owned and operated independently. Will see this with BGP routing. All of these principles make a lot of sense. And have contributed to the Internet's success. H. Weaknesses of the design - No accounting/policing - Poor management tools - Adding changes difficult (mainly due to decentralized ownership and management) - Greed or individual interest is not handled well Lets talk about the last issue for a bit. The early Internet came about in an innocent time - common goals, common vision, consistent thinking. But with success came multiple goals. Multiple parties interested in furthering their own cause. Creates "tussles": 1. ISPs must cooperate with each other to provide connectivity, but are also fierce competitors. 2. Users desire privacy and government feels the need to sniff and monitor. 3. Hosts desire to exchange files vs copyright owners. These tussles have come to stay in the network today. Why is this an issue? In the context of the current architecture, these tussles mean that it is unclear whose interests are being met, to what extent, whether we are being fair. A good architectural design must provide a way to manage and resolve evolving conflicts. Accept that tussles happen - but espouse it and accommodate it into the design. This strengthens the architecture, makes it more flexible and general. How to design to deal with and accommodate tussles? 1. Design for variation in outcome. This will ensure that the outcome can be different in different places and that the tussle happens inside the design, not by distorting it. 2. Recognize, modularize and isolate tussles when possible. QoS uses TOS bits to determine quality of service independent of the application properties. Decouples network QoS from application design and allows both to grow independently and organically. 3. Allow all parties to make choices on interactions. E.g choosing between mail servers. Choosing between ISPs. Creates competition. Next class: We will talk about High speed routers. We will discuss two papers: [D+97] Mikael Degermark, Andrej Brodnik, Svante Carlsson and Stephen Pink, Small Forwarding Tables for Fast Routing Lookups, ACM SIGCOMM 97. [MIM+97] N. McKeown, M. Izzard, A. Mekkittikul, W. Ellersick, M. Horowitz The Tiny Tera: A Packet Switch Core, IEEE Micro, 1997. There is no assigned reading. We will also spend some time discussing ideas for class projects.