END-TO-END Arguments in System Design

1. END-TO-END Arguments in System Design J. Saltzer D. Reed D. Clark M.I.T. Laboratory, 1981 Presented ByMohammad MalliPhD student (2nd year) Planete Project

2. Review communication networks switchednetworks broadcastnetworks circuit-switchednetworks(e.g. telephone) packet-switched networks E2E arguments (keep the network ‘best effort’ and move the functionalities to the ends) datagram networks(e.g. TCP/IP Internet) July 11, 2005

3. Special dates • 1969 : Arpanet is founded by connecting four computers, each one is located in four US universities • 1972 : many countries have been participated to a communication conference in Wash. and they were agreeing to the necessity to define a common com. protocol for connecting the different emerging networks • 1981 : Saltzer et al have published the E2E arguments • 1984 : all the emerging networks have been connected to each other and after a short time these networks have communicated with a ‘same language’ TCP/IP and the whole becomes the INTERNET July 11, 2005

4. Layering model Dealing with complex systems: • Explicit structure allows identification of the relationship among a complex system’s pieces • Modularization eases maintenance, updating of system • change of implementation of a layer’s service transparent to rest of system, e.g., changes in routing protocol doesn’t affect rest of system Key design issue: How do you distribute functionalities among the layers? July 11, 2005

5. The E2E Arguments • “...The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible...” • E2E arguments is a reasonning against implementing the functions at a low-level • to avoid redundancy among the system functionalites • to avoid or reduce the cost that can be occured from providing them at that low level • some applications do not need the function • low-level subsystem may not have as much information as the higher levels July 11, 2005

6. The E2E Arguments • Define the exception : • “… (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)” • No strict rule, but think twice before implementing the function at a low-level • there are some special cases where the benefit may outweigh the cost July 11, 2005

7. Careful File Transfer • Copy/Move file from HD on Computer A to HD on Computer B • Goal is to move file without damage • Specific steps of transaction : • File transfer application on host A reads file • Application asks com. system for transmission • Com. network transmits file from A to B • Com. system on host B reads packets and delivers them to file transfer application on host B • File transfer application on host B writes file July 11, 2005

8. Careful File Transfer : Threats • Possible threats to an accurate transfer: • Disk error • Software error (file system, file transfer program, Network driver) • Hardware error during the buffering and copying • Error can be occured in the com. system (drops, change bits, packet loss, …) • Host crash during the transaction July 11, 2005

9. Careful File Transfer • Point2Point solution • Reinforce each step of process (timeout, retry, etc.) • Goal: Reduce probability of each threat to an acceptably small value • Could be hard to do, each step must be full-proof • Could be inefficient, extra checking • E2E solution • Store file with a checksum, transfer file, read transferred file back from disk, compute checksum, send checksum to originator to compare the two checksums. • If check fails, redo from beginning • Lesson: • Application must supply the guarantee in the end July 11, 2005

10. Identifying the ends • Maybe not so easy… • Consider voice over IP • Are the ends the computers? • Could introduce long delays • Are the ends the people? • Retry = “repeat that” • End-to-End argument is not an absolute rule, but a design tool July 11, 2005

11. Conclusions • E2E arguments was the reason behind moving the complexity from the network to the enpoints • Higher-level layers, more specific to an application, are free to organize lower-level network resources to achieve application-specific design goals • application autonomy • Lower-level layers, which support many independant applications, while providing to applications usable means for effective sharing of resources and resolution of resource conflicts • network transparency July 11, 2005

12. Reflections • E2E argument (SWALLOW) meets P2P file sharing • Multimedia applications seem to be missed when defining the design rules • these app. require more than ‘best effort network’ • skype is a success for voice over IP, but is it E2E ? No, a conversation between two hosts passes by a tier July 11, 2005

13. Q. & A. THANK YOU July 11, 2005

14. BACKUP July 11, 2005

15. Secure Transmission of Data • Let the communication system encrypt on entry, decrypt on exit • Problems: • Communication system needs the key • Data is in the clear when entering/exiting • Authenticity must still be checked by application • End-To-End argument wins here July 11, 2005

16. Delivery Guarantees • Acknowledgement of Delivery of a message • Knowing that a message was delivered is not very important for an application • Knowing that the other host acted on the message is more important • This can be done in an end-to-end way which can be originated by the target application July 11, 2005

17. Duplicate message suppression • Some network designs allow(ed) a message to be delivered twice • The application might do that, too • Thus, suppression must be accomplished by the application anyway • Function can be omitted from lower levels July 11, 2005

18. Guaranteeing FIFO message delivery • Ensuring that msgs arrive at the receiver in the same order they are sent • this task is usually assigned to the com. system • there is no guarantee since msgs may cross different paths before arriving to the receiver • Thus, an independant mechanism at a higher level than the com. sys. must be responsible on the reordering July 11, 2005

19. Transaction management • Distributed data repositories for storing and retrieving data (SWALLOW) • Accessing data via identifier, version, type of access (read/write) • Network is simplified and does not suppress duplicate messages • Identifier plus version suffices to detect duplicate writes • Duplicate read only leads to duplicate response • Acknowledgement for write requests aim to store data safely • Can only be provided by the higher levels • Acknowledgement for read requests is redundant since data itself is an ack. sign July 11, 2005

20. Pkt switching vs Circuit switching • Advantages of packet switching over circuit switching • most important advantage of packet-switching over circuit switching is statistical multiplexing, and therefore efficient bandwidth usage • no call setup (for datagram switching only) • no per-flow state information (for datagram switching only) • simple to implement • Disadvantages of packet switching • potential congestion: packet delay and high loss • protocols needed for reliable data transfer, congestion control • packet header overhead • per packet processing overhead July 11, 2005