END to END arguments in System Design by
END to END arguments in System Design by JH Saltzer, DP Reed, and DD Clark MIT
The Problem • Suppose that we have a layered system (such as the Internet) • Suppose that we would like to place some functionality in it: e. g. • Encryption (e. g. for security) • Compression (e. g. to conserve bandwidth) • Reliable transmission (e. g. to make sure that all data arrive at their destination) • Where shall we place this functionality? • At the lowest level? E. g. physical level • At the highest level? E. g. in the user library? • Somewhere in between? E. g. at the TCP/IP level?
The problem • Suppose we would like to add encryption to the Internet • Where shall we place this functionality? • • • At the Ethernet level? i. e. to have a Secure Ethernet? At the IP level? i. e. to have a Secure IP? At the UDP level? i. e. to have a secure UDP? At the TCP level? i. e. to have a secure TCP? At the application level? i. e. to have a secure SSH? • All of the above? None of the above?
Solution: the end-to-end argument • The function in question can be • completely and correctly implemented • only with the knowledge and help • of the application standing at the • end points of the communication system. • Rule of thumb: OVER and OUT
A Simple example: Compression • Suppose that we would like to implement compression on the Internet • To reduce the network bandwidth required • Question: Where should this compression be implemented? • • At the modem level? At the IP level? At the TCP level? At the application level?
Solution for Compression • E 2 E argument: Compression should be implemented at the application level • Why not at the IP level? Or at the TCP level? • Most of the data on the Internet are already compressed • IP packets do not have enough redundancy (size) to enable good compression • All packets need to “pay” the compression overhead • Even the compressed ones! • Same for TCP packets • Anything else? • YES! Applications know the nature of the data (e. g. text, web, etc. ) • and know which compression algorithms are more appropriate The function in question can be completely and correctly implemented only with the knowledge and help of the application standing at the end points of the communication system.
How about Security? • E 2 E Argument: Security should be implemented at the socket level • Why not at the IP level? • IP starts at the first ISP router and ends at the last ISP router. • How to you check that the message was not changed • BEFORE the first router, or AFTER the last router? • How do you verify that the message was not copied • • • BEFORE the first router, or AFTER the last router? What if you do not trust your ISP? The ISP will receive your packets clear text. Would you like that? Which cypher (encryption method) will you use? What if the downstream ISP router tells you that they only support one and only one cypher which is weak? • What are you going to do? Not send them the IP packets? • Encryption at the TCP (socket) layer seems to be the solution The function in question can be completely and correctly implemented only with the knowledge and help of the application standing at the end points of the communication system.
How about FIFO message delivery? • What is FIFO delivery? • If a sender sends message A and then sends message B, the receiver will FIRST receive A and THEN receive B • Question: Where shall we implement FIFO message delivery? • E 2 E Argument: Security should be implemented at the socket level • Why not at the link level? • Packet in a single link will follow FIFO delivery, but we do not know what will happen at the next link • Why not at the path level? • IP delivery allows multiple paths: messages A and B may follow different paths to their destination • Why not at the end levels (i. e. between the sender and the receiver) • Well, … this the E 2 E argument! • • FIFO delivery should be implemented end to end The function in question can be completely and correctly implemented only with the knowledge and help of the application standing at the end points of the communication system.
How about guaranteed message delivery? • What is guaranteed delivery? • If a sender sends message to a receiver the message is guaranteed to arrive • Question: Where shall we implement guaranteed message delivery? • E 2 E Argument: Guaranteed message delivery should be implemented at the socket level • Why not at the link level? • What is the packet is lost at the memory of the router? • Why not at the PATH level? • What if the message gets corrupted in the receiver’s memory? • Why not at the IP level? • Not all applications want guaranteed message delivery – (consider voice transfers) • Guaranteed message delivery should be implemented end to end The function in question can be completely and correctly implemented only with the knowledge and help of the application standing at the end points of the communication system.
Is E 2 E only applied to the Internet? • NO!! • Consider hardware: • • RISC vs CISC Question: Where shall we implement complex commands? CISC Answer: in the hardware RISC Answer: the hardware should be simple – implement them at a higher level • The RISC answer is the E 2 E argument!
What do all these mean? • Encryption: • You could implement encryption at the IP level, but you would have to implement it again at the socket layer. • Compression: • You could implemented encryption at the IP level, but you would have to implement it again at the application layer • FIFO Message Delivery • You could implemented FIFO delivery at the IP level, but you would have to implement it again at the socket layer • Guaranteed Message Delivery • You could implemented it at the IP level, but you would have to implement it again at the socket layer
The end-to-end argument • The function in question can be • completely and correctly implemented • only with the knowledge and help • of the application standing at the • end points of the communication system. • Rule of thumb: OVER and OUT
- Slides: 12