END-TO-END Arguments in System Design END-TO-END Arguments in System Design J. SaltzerD. Reed D. Clark M.I.T. Laboratory, 1981 Presented By Mohammad Malli PhD student (2nd year) Planete Project

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

July 11, 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, 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, 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, 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, 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, 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, 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, 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, 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, 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, THANK YOU Q. & A.

July 11, BACKUP

July 11, 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 Secure Transmission of Data

July 11, 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, 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 Duplicate message suppression

July 11, 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, 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, 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 Pkt switching vs Circuit switching