Download End-to-End Argument

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