1 / 15

End-To-End Arguments in System Design

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

drea
Download Presentation

End-To-End Arguments in System Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. End-To-End Arguments in System Design J. Saltzer, D. Reed, and D. Clark Presented by: Jerry Hom

  2. Introduction • Classic article (1981) • New idea? • … or stating the obvious about large system design?

  3. 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

  4. Large System Design • Examples and implicit assumptions … which may be faulty • Component stereo system • MIT’s old network AMP EQ CD

  5. Large System Design Taken from Prof Badri’s CS552 slides

  6. 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

  7. End-To-End Examples • ACK • Explicit? • Implicit? (RPC) • Security • Authentication • Trust

  8. End-To-End Examples • Duplicate suppression • Impossible to distinguish valid duplicates • Hence, application must suppress DUPs • FIFO delivery • Packets may take different routes

  9. 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)

  10. End-To-End Today? • How does the Argument change for today’s distributed systems? • Correctness • Reliability

  11. Timeless Example: FTP 1 5 3 2 4 Disk read FTP transmit Network carries packets FTP receive Disk write Host A Host B

  12. 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

  13. 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!

  14. 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

  15. 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

More Related