1. Architecture and Principles
CS244 Lecture 3
Architecture and Principles
End to end arguments in system design (1981)
Conclusion from previous paper
Misgivings
Datagram is a pretty good abstraction, a stateless self-contained unit for internetworking
Build a variety of services on top of it
Anticipated the conflict between datagram and the fact that often decisions need to be made on collections of datagrams called flows
e.G firewalls,multipath routing. So lots of complexity has grown in the network
Flows imply soft state
Which they were trying very hard to avoid due to the first requirement
This leads us to this paper
Sachin Katti & Keith Winstein

2. Conclusion (Internet Design Principles)
“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.)”
What is the end to end argument?
Three components:
What is the function? Doesn’t state that, its merely trying to say where you should place it
Its guidance, not law
What is the end? Depends on the function and the context needed for that function. Also depends on who owns responsibility for that function
What is it really? Common sense: if you want a job done right, you have to do it yourself. All the examples are about that.
But a bit more. If you have to do it yourself anyway, then no point adding complexity in the network to do it, its redundanrt. So its also about performance management.

4. 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 the Internet to grow rapidly because innovation took place at the edge, in applications and services.
Ex. WWW, Skype, BitTorrent, Bitcoin
The biggest consequence; dumb minimal network
What has been the biggest impact of this: www
Explosion of growth
Other examples

5. Case studies Error handling in file transfer
Encryption and authentication
The partition between TCP, IP, and the link layer of error handling, flow control and congestion control.
Fairness in resource allocation

6. What you said
“Performance matters, and we should strive to make the network provide the desired behaviors most of the time, and make the failures rare in which case the (maybe) costly recovery at the higher level can kick in” - Peiqian Li
James Hong, keep it private

7. What you said
“The application function is necessary to ensure encryption between the application endpoints, while the network implementation serves the role of preventing leaking of information that the network operator does not wish to be exposed. I felt this area of non-overlapping functionality could have been explored further in regards to other types of functions.” - Jayden Navarro

8. On the other hand…
E2E principle appears to have become 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 7,000 RFCs.
Router OS’s based on 100M lines of source code.
Q: Is this a problem?

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