* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download End-to-End Argument
Survey
Document related concepts
Asynchronous Transfer Mode wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Wireless security wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Distributed firewall wikipedia , lookup
Internet protocol suite wikipedia , lookup
Computer network wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Network tap wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Airborne Networking wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Transcript
The End-to-End Principle Anthony D. Joseph Joe Hellerstein CS262a November 28, 2001 Outline • • • • End-to-End principle Design / control from endpoints Advantages Limitations November 28, 2001 CS 262a 2 The End-to-End Argument • Saltzer, Reed, and Clark, 1984 – “End-to-End Arguments in System Design” • Key idea: – A function can only be completely and correctly implemented with the knowledge and help of the applications standing at the communication endpoints – Argument can be applied in many areas: • Delivery guarantees, secure transmission of data, duplicate message suppression, and rational principles for organizing layered systems November 28, 2001 CS 262a 3 Motivation: Simplicity • Same argument as for RISC – Occam’s razor • If there’s a problem, the simplest explanation is likely the correct one – Argues against low-level function implementation • “What is a layer?” • E2E allows for simpler layers – Avoid complex operations that can be handled with simpler logic at app layer November 28, 2001 CS 262a 4 Layering: Building Complex Functionality into a Network • Implicitly optimizes the network for one set of uses • Substantially increases the cost of potentially valuable uses that may be unknown/unpredictable at design time • May preclude these uses entirely November 28, 2001 CS 262a 5 Examples of Layering Pitfalls • If original Internet design was optimized for telephony-style virtual circuits (like SNA and TYMNET) • Wouldn’t have experimentation / protocols – DNS, Web, a million ISPs, Napster/Gnutella,… November 28, 2001 CS 262a 6 Careful File Transfer • Transient failures at many levels – Disk errors – Incorrect software • FS, FTP, network, … – Hardware errors • CPU, memory, network, disk, system crash, … • Choices: – Brute force countermeasures, End-toEnd checks, Reliable network layer November 28, 2001 CS 262a 7 Brute Force Countermeasures • Make each step/level ultra-resilient to faults • Overkill when threats are low probability • Uneconomical (e.g., send each byte four times) • Not all layers are under FTP designer’s control November 28, 2001 CS 262a 8 End-to-End approach • Application provides file-transfer specific, end-to-end reliability guarantees – E2E check and retry – Receiver sends checksum of received data to sender for validation • Reduces complexity for low probability failures November 28, 2001 CS 262a 9 Reliable Network Layer • Provide very high probablistic guarantee of correct, in order data xmission at network layer – Use network layer ACKs from receiver to sender • Is this sufficient? • No, hosts may crash, FTP failure, etc. – Hop-by-hop reliability or host-to-host reliability? – Reality: Requires app-specific, app-level protocol • Is this necessary? • Maybe, depends on link’s error rate • Performance, not correctness – Tradeoff: how good is good enough for a given level? November 28, 2001 CS 262a 10 Tradeoff Example: Wireless • Perfect wireless link-layer retransmission versus end-to-end retransmission • Advantages: – Local retransmission can be faster – Avoids loss on wired portion of link • Disadvantages – Real-time apps: more variable delay (jitter) – What about unreliable datagrams? • Tradeoff: less than perfect transmission November 28, 2001 CS 262a 11 Network Layer ACKs • Is it useful to expose them to the sender app? – Not really, sender app wants to know if receiver acted on the message • What if receiver network layer guarantees handling of msg when ACK’ing? – May still need E2E ack if receiver app could reject message – Requires 2PC if coordinating actions across multiple hosts November 28, 2001 CS 262a 12 Challenges to the End-to-End Model • Slippery slope: “Ends Justify Means?” • Example: ISP access control box – “Exon box” (CDA enforcement) • Content restriction at network level – Restricts access to “indecent sites” or unrated sites unless an “adult” enters an authorization code when opening a session (enables router to transmit packets to the site) • Good or bad idea? – Alternatives? November 28, 2001 CS 262a 13 Performance Justifications? • Transparent network caching • Advantages: – Potential for significant performance improvement • Disadvantages: – Loss of network transparency: target doesn’t get information • Access patterns / information, pay-per-view – Copyright issues? November 28, 2001 CS 262a 14 More limits? • Transparent network redirection • Advantages: – Load balancing – Fault tolerance • Disadvantages: – Network transparency • Explicit handling of persistent sessions required November 28, 2001 CS 262a 15 More limits? • Kerberos version 5 • Msg token replay protection – Version 4 relied upon application-level – Programmers usually got it wrong • Version 5 supports replay protection • Good idea or bad idea? November 28, 2001 CS 262a 16 More limits? • What happens when you can’t apply E2E? • One way communication channels – Pager networks – Voice store and forward • Must be willing to tradeoff delays / extra processing for more robustness – ECC, FEC, etc • But, still may need E2E check – Ex: you call the person who paged you November 28, 2001 CS 262a 17 Summary • Where do we find E2E? – Encryption – 2PC: doesn’t depend on reliability, ordering, etc. – Banking: auditing – Cellular: human retry • Have to take it case-by case November 28, 2001 CS 262a 18