End to end arguments in system design (1981)

1. CS244 Winter 2014 Lecture 3 Architecture and Principles • End to end arguments in system design (1981) • Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Sachin Katti

2. Author’s conclusion in previous lecture • “Datagram” good for most important goals, but poor for the rest of the goals. • Processing packets in isolation, resource management, accountability all hard. • Anticipates flows and “soft-state”for the future.

3. End-to-End Arguments in System Design[Saltzer, Reed, Clark 1981] End-to-end in a nutshell “The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)”

4. Commonly used examples • Error handling in file transfer • End-to-end, versus in-network encryption • The partition between TCP and IP of error handling, flow control and congestion control.

5. What you said This paper is extremely relevant today. Although the end-to-end principle in many types of application's, it is especially useful in distributed applications, and those are becoming very common. With the rise of the cloud, most mobile and desktop apps spend significant amounts of time talking to remote servers and thus form a distributed system of sorts. Most mobile app developers do not spend much time worrying about errors: the underlying communication mechanism has become very reliable, and so it's easy to assume that it will catch all errors. The end-to-end principle reminds us that in many cases each endpoint will need to perform its own checks. The world is getting more distributed, not less, and so I believe this will be as important (if not more so) in 10 years.

6. Some consequences • In layered design, the E2E principle provides guidance on where functions belong. • “Dumb, minimal” network and “intelligent” end-points. • Many argue that: E2E principle allowed Internet to grow rapidly because innovation took place at the edge, in applications and services.

7. On the other hand… E2E principle appears to have been diluted: NATs, firewalls, VPN tunnel endpoints, … • Perhaps not surprising: E2E principle grew in an era of trust among users. Now network must protect itself. The network is no longer “dumb, minimal” • Now over 6,000 RFCs. • Router OS’s based on over 30M lines of source code. Q: Is this a problem?

8. What you said Wei Shi, "there is an interesting case nowadays that works against that principle. Specifically, routers are getting more and more features installed, e.g. time server, VPN server/client. By end-to-end principle, the router should be kept simple because they are mostly middle nodes in the network. “ Other similar comment: "However, in light of today’s networks, we see that the end-to-end argument is constantly being violated by technologies such as but not limited to NATs and security monitoring systems such as Firewalls or IDSs. However, the authors did state something interesting that I believe should have been included in the original argument, which is that, the “End-to-end arguments are often applied to error control and correctness in application systems”. This notion of error control and correctness does not conflict with the major goals of the mentioned violating technologies as many attempt to provide accountability, management, and security in the system"

9. What belongs in, what out? Questions: • Does routing belong in the “dumb, minimal” network? • How about multicast, mobility, QoS…? • Are NATs necessary, good, or evil? • Is the E2E principle constraining innovation of the infrastructure?

10. Additional references [rfc3724] “The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture”- Kempf et al. [Blumenthal] “Rethinking the design of the Internet: The end-to-end arguments vs. the brave new world”, ACM Transactions on Internet Technology, Vol. 1, No. 1, August 2001, pp 70-109.

11. Tussle in Cyberspace: Defining Tomorrow’s Internet • Actor-Network Theory (ANT) • Assumes equal treatment of humans and non-humans in an interacting network. • Distinction between ‘mediators’ and ‘intermediaries’: “silk and nylon”.

12. Context • Why did the authors write the paper? • What had changed since the Internet was invented?

13. Problem Statement “The Internet was created in simpler times. Its creators and early users shared a common goal —they wanted to build a network infrastructure to hook all the computers in the world together so that as yet unknown applications could be invented to run there. All the players, whether designers, users or operators, shared a consistent vision and a common sense of purpose.” “Perhaps the most important consequence of the Internet’s success is that the common purpose that launched and nurtured it no longer prevails.”

14. What you said • Lisa Yan: I am also happy that Clark points out that the evolution of the Internet is not solely due to engineers; rather, there are facets of law, companies, and malicious or benign users that shape the Internet due to their overlapping, adversarial conflicts of interest. I loved that Clark presents the paradox of designing policy and structured frameworks in order to support or direct innovation, which evolves as a result of unpredictable turmoil. • Robert Gasparyan: This was a very eye-opening read for me, because until now I considered the process of engineering an apolitical, asocial and an unemotional task that is separated from all social affairs in it’s magic bubble.

15. Types of Tussle • Economics • Trust • Openness

16. What you said • Chirag Sangani: Another issue is that it is difficult to correctly predict or identify tussle boundaries. … . It seems that predicting all relevant tussle boundaries seems to be a futile exercise. • Manikanta Kotaru: However, the paper does not mention how to foresee tussles. This is very important as there is an important need to recognize and move along new tussle boundaries. Tools to identify possible tussles would be helpful. • Stephen Barber: Many of the examples in the paper assume that in the customer vs ISP tussles, the customer can leave for another ISP. This is not the case at all, and it is questionable that designing for tussles would have been able to prevent this scenario from playing out.

17. Questioning sacred cows • End to end argument Q: How is it affected by “tussles”? • Separate policy from mechanism Q: What does it mean? If the goal is to hook computers together and let users run any application they want, then a simple transparent network enables “user empowerment”, choice and innovation.

18. What you said • Graham Roth: For most of the article, the authors talk about how they don't want to inform the tussle, they just want to design for choice -- design to allow tussle, whatever it is and whatever the outcome is. But then towards the end, they start endorsing a system that empowers end users. This violates their earlier statements by biasing the tussle. In doing so, it creates a new tussle, or informs the tussle in a certain direction, true, but they have broken their own rules. I suppose you can find a tussle anywhere, but who is to say which ones are important to let happen and which ones you can alter?

19. A lesson Hypothesis about QoS: Internet providers had no incentive to deploy. • There is a real cost to deploy • Users had no way to choose providers (local or remote). Q: How is this related to tussles?

20. Consequences • What do the authors recommend we do? • What are the concrete steps?

21. Parting comments • David Silver: It then describes principles that should be used to design systems, but only in extremely vague terms that aren't helpful in practice ("design for choice" - how?). • Henry Wang: Thus, it almost seems like the authors are not showing developers how to continue working in this environment so much as making them aware of the responsibilities they now hold. To maintain the delicate balances that exist between the various contenders of the Internet, the authors are pleading with the developers to do the right thing.