160 likes | 379 Views
End-To-End Arguments in System Design. J. Saltzer, D. Reed, and D. Clark Presented by: Jerry Hom. Introduction. Classic article (1981) New idea? … or stating the obvious about large system design?. Large System Design. Black box Many designers Each designer’s responsibility
E N D
End-To-End Arguments in System Design J. Saltzer, D. Reed, and D. Clark Presented by: Jerry Hom
Introduction • Classic article (1981) • New idea? • … or stating the obvious about large system design?
Large System Design • Black box • Many designers • Each designer’s responsibility • Modular interface (layered services) • What interface to export? (eg, ethernet) • Quality of interface? • Two key issues • Correctness (quality) • Reliability
Large System Design • Examples and implicit assumptions … which may be faulty • Component stereo system • MIT’s old network AMP EQ CD
Large System Design Taken from Prof Badri’s CS552 slides
End-To-End Argument • Guideline for infrastructure design • Interface requirements: • Correctness? ==> maybe • Reliability? ==> maybe • Knowledge of applications’ requirements! • RISC design • Focus on flexible, core infrastructure • Allow higher layers to add functionality
End-To-End Examples • ACK • Explicit? • Implicit? (RPC) • Security • Authentication • Trust
End-To-End Examples • Duplicate suppression • Impossible to distinguish valid duplicates • Hence, application must suppress DUPs • FIFO delivery • Packets may take different routes
End-To-End Examples • Transactions • Disk write ==> correctness unknown by network, ensured only by application • Disk read ==> result value is sufficient ACK • Multimedia • Both correctness/reliability unnecessary • Timely delivery (low latency or large buffer)
End-To-End Today? • How does the Argument change for today’s distributed systems? • Correctness • Reliability
Timeless Example: FTP 1 5 3 2 4 Disk read FTP transmit Network carries packets FTP receive Disk write Host A Host B
FTP Pathologies 4 4 2 2 4 4 4 1 3 3 Bad disk read FTP software bug Hardware glitch Dropped, duplicate, or mangled packets Host crash Host A Host B 5 5
FTP Fault Tolerance (old school) • Redundancy at each step • Extra effort by developers at every step • Overkill for low probability errors • End-To-End checksum • Useful if errors are indeed low probability • FTP must still handle high-level failures!
Conclusion, so far … • Where to place functionality? • In higher levels • Not that simple -- performance? • Can improve network reliability and correctness, though these must be judged by application • Performance trade-off by engineering
Final Conclusions • Not a strict rule, but guideline • Every system/application has varying demands • Argument reminds system designers to • Focus on core functionality • Be mindful of applications • … simpler is usually better