venture, or perhaps redundantly, each doing its own version. In reasoning about this choice, requirements of the application provide the basis for a class of arguments, which go as follows 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. We call this line of reasoning against low-level function implementation the " end-to-end argument " The following sections examine the end-to-end argument in detail, first with a case tudy of a typical example in which it is used -the function in question is reliable data transmission-and then by exhibiting the range of functions to which the same argument can be applied For the case of the data communication system, this range includes encryption, duplicate message detection, message sequencing, guaranteed message delivery, detecting host crashes, and delivery receipts In a broader context the argument seems to apply to many other functions of a computer operating system, including its file system. Examination of this broader context will be easier if we first consider the more specific data communication context, however End-to-end caretaking Consider the problem of"careful file transfer. a file is stored by a file system, in the disk storage of computer A Computer a is linked by a data communication network with computer B, which also has a file system and a disk store. The object is to move the file from computer A's storage to computer B's storage without damage, in the face of knowledge that failures can occur at various points along the way. The application program in this case is the file transfer program, part of which runs at host A and part at host B In order to discuss the possible threats to the file's integrity in this transaction, let us assume that the following specific steps are involved 1. At host a the file transfer program calls upon the file system to read the file from the disk, where it resides on several tracks, and the file system passes it to the file transfer program in fixed-size blocks chosen to be disk-format independent 2. Also at host a the file transfer program asks the data communication system to transmit the file using some communication protocol that involves splitting the data into packets. The packet size is typically different from the file block size and the disk track size 3. The data communication network moves the packets from computer A to computer B 4. At host b a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B 5. At host b, the file transfer program asks the file system to write the received data on the disk of host b With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host a or host 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host a or host B The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than onceSALTZER ET AL. End-to-End Arguments in System Design 2 venture, or perhaps redundantly, each doing its own version. In reasoning about this choice, the requirements of the application provide the basis for a class of arguments, which go as follows: 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.) We call this line of reasoning against low-level function implementation the "end-to-end argument." The following sections examine the end-to-end argument in detail, first with a case study of a typical example in which it is used – the function in question is reliable data transmission – and then by exhibiting the range of functions to which the same argument can be applied. For the case of the data communication system, this range includes encryption, duplicate message detection, message sequencing, guaranteed message delivery, detecting host crashes, and delivery receipts. In a broader context the argument seems to apply to many other functions of a computer operating system, including its file system. Examination of this broader context will be easier if we first consider the more specific data communication context, however. End-to-end caretaking Consider the problem of "careful file transfer." A file is stored by a file system, in the disk storage of computer A. Computer A is linked by a data communication network with computer B, which also has a file system and a disk store. The object is to move the file from computer A's storage to computer B's storage without damage, in the face of knowledge that failures can occur at various points along the way. The application program in this case is the file transfer program, part of which runs at host A and part at host B. In order to discuss the possible threats to the file's integrity in this transaction, let us assume that the following specific steps are involved: 1. At host A the file transfer program calls upon the file system to read the file from the disk, where it resides on several tracks, and the file system passes it to the file transfer program in fixed-size blocks chosen to be disk-format independent. 2. Also at host A the file transfer program asks the data communication system to transmit the file using some communication protocol that involves splitting the data into packets. The packet size is typically different from the file block size and the disk track size. 3. The data communication network moves the packets from computer A to computer B. 4. At host B a data communication program removes the packets from the data communication protocol and hands the contained data on to a second part of the file transfer application, the part that operates within host B. 5. At host B, the file transfer program asks the file system to write the received data on the disk of host B. With this model of the steps involved, the following are some of the threats to the transaction that a careful designer might be concerned about: 1. The file, though originally written correctly onto the disk at host A, if read now may contain incorrect data, perhaps because of hardware faults in the disk storage system. 2. The software of the file system, the file transfer program, or the data communication system might make a mistake in buffering and copying the data of the file, either at host A or host B. 3. The hardware processor or its local memory might have a transient error while doing the buffering and copying, either at host A or host B. 4. The communication system might drop or change the bits in a packet, or lose a packet or deliver a packet more than once