End-To-End Arguments in System Design J.H. Saltzer, D.P. Reed, and D. Clark Presented by: Ryan Huebsch CS294-4 P2P Systems – 9/29/03

Outline The Argument Examples Careful File Transfer Secure Transmission of Data Performance Identify the Ends End-To-End Argument Meets P2P

The Argument Define when it is applicable: “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…” Regardless of what happens in the communication systems, correct operation can only be verified by endpoints.

The Argument Define the consequence: “… Therefore, providing that questioned function as a feature of the communication system itself is not possible…” If you can’t do it properly, don’t do it at all.

The Argument Define the exception: “… (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)” Its not a hard and fast rule, there are special cases where the benefit outweighs the cost.

Careful File Transfer Copy/Move file from HD on Computer A to HD on Computer B

Careful File Transfer Possible threats to an accurate transfer: Disk error Software error (OS, File transfer program, Network driver) Hardware error Communication system System crash

Careful File Transfer Solution 1: Point-to-Point 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 Solution 2: End-to-End 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

Careful File Transfer Solution 3: Both Point-to-Point checks in communication system (such as link level, IP, and/or TCP) End-to-End checks must still be performed, since only one of the threats is handled Does not reduce the overall burden to the application, but may reduce the frequency of problems Lesson: Application must supply the guarantee in the end

Secure Transmission of Data Goal, move data from one machine to another such that the data on the wire is secure (encrypted)

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

Performance Remember the exception in the argument… What if communication system is very unreliable, file transfer could keep retrying for ever because one packet got lost! Providing more reliability at the lower layers is a tradeoff between cost & engineering effort vs. reliability Not a simple decision

Performance Even if it simple to implement at a lower level and doesn’t cost much Subsystem may be common to many applications, they all must pay Subsystem has less information, may not be able to do the best job Decision could be complicated if some of the packet-by-packet type checks can be emulated by application Send file in chunks, each chunk is checked for correctness

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, but a design tool

Not Just for Communication Encryption Two-Phase commit Banking (high level auditing) Reservations (agent retries till confirmed) Telephone (caller redials) Backup on magnetic tapes RISC (simple instructions) Open Operating System (replace low level functions)

End-To-End Argument Meets P2P Consider key-based-routing systems (which seem similar to SWALLOW?) : Function: route(key, msg) What are the ends? Requestor & Responsible Node Router-to-Router or Application-to-Application Structured vs. Unstructured Structured gives better reliability Unstructured gives less Iterative vs. Recursive?