End-To-End Arguments in System Design
Download
Report
Transcript End-To-End Arguments in System Design
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
2
1
4
3
5
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?
Are the ends the people?
Could introduce long delays
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?
Structured vs. Unstructured
Requestor & Responsible Node
Router-to-Router or Application-to-Application
Structured gives better reliability
Unstructured gives less
Iterative vs. Recursive?