End-to-End Issues

1. End-to-End Issues Al Harris CS 598ig 9/28/2005

2. Where is the Work Done? • In the network • Sensor fusion • Active networks • NAT • At the endpoints • Using acknowledgements for reliability • On the phone: “Can you repeat that?”

3. Outline • The End-to-End Argument • Saltzer, Reed, and Clark • ESRT: Event-to-Sink Reliable Transport in Wireless Sensor Networks • Sankarasubramaniam, Akan, and Akyildiz • Middleboxes: Taxonomy and Issues • RFC 3234 • Conclusions

4. End-to-End Argument “The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible.”

5. What it says: • Some functionality requires application level knowledge • Reliability (careful file transfer) • If it can’t be done correctly… Don’t do it at all!

6. Proviso “Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.” • Sometimes, the rule can be broken • 802.11 MAC retransmissions

7. 2 4 3 1 5 Example: Careful File Transfer • Copy/Move file from HD on Computer A to HD on Computer B

8. What Can Go Wrong? • Disk error • Software error (OS, File transfer program, Network driver) • Hardware error • Communication system • System crash

9. Step-by-Step Solution • Method • At each step use error detection and correction • Do local recovery at each step • Problems • Expensive • Application still has to check for errors • Constant checking even in steps unlikely to produce errors

10. End-to-End Solution • Method • Transfer entire file • Compute checksum and send to originator for comparison • Problems • If errors are encountered, file transfer must be started from the beginning

11. Performance • How much reliability to put in lower layers? • Do not need “perfect” reliability • Engineering Trade-off • Cost • Performance

12. Two Issues • Lower layer subsystems are shared • If reliability is higher than most apps need all have to pay • Aim for the “average” app? • Lower layer subsystems have less information about the data • May be more efficient means at the application

13. To What Ends? • Identifying the ends may not be trivial • Consider Voice over IP • Are the ends the computers? • May introduce delays waiting for retransmissions • Are the ends the people? • User interaction? “What did you say?” • The ends must be known to apply the argument

14. Composite Solution • Method • Use reliable transport protocol (TCP) • Still must compute file checksum to guard against file system errors • Is this better? • Does not avoid application level checks • May reduce frequency of starting over from the beginning

15. The “Ends” in Sensor Networks • Why focus on particular pieces of data? • EVENTS are what sensors are all about Leads to a different reliability scheme

16. Event-to-Sink Reliable Transport (ESRT) • Idea • Only care about event notification, not individual data packets • Define reliability with respect to number of data packets per event per time interval • Control the rate at which sensors send packets

17. ESRT: Controlling the frequency • If receiving more packets than needed • Have sensors reduce frequency • Reduces probability of congestion • Saves transmission energy in the network • If receiving too few packets • Have sensors increase sending frequency • Unless there is congestion

18. Retransmissions? • No need • Individual packets are not important • Only event notification • Might be stale anyway • Old sensor data possibly not useful • Increases congestion • If losses due to congestion, retransmission won’t help

19. Congestion Control • Sensor networks are usually idle… • …Until an event occurs • High probability of channel overload • Information must reach users • Solution: congestion control

20. ESRT: Overview • Places interest on events, not individual pieces of data • Application-driven • Application defines desired event reporting rate • Includes a congestion-control element • Runs mainly on the sink • Main goal: Adjust reporting rate of sources to achieve optimal reliability requirements

21. Problem Definition • Assumption: • Detection of an event is related to number of packets received during a specific interval • Observed event reliability ri: • # of packets received in decision interval I • Desired event reliability R: • # of packets required for reliable event detection • Application-specific • Goal: configure the reporting rate of nodes • Achieve required event detection • Minimize energy consumption

22. Reliability vs. Reporting Frequency • Initially, reliability increases linearly with reporting frequency • There is an optimal reporting frequency (fmax), after which congestion occurs • Fmax decreases when the # of nodes increases

23. Characteristic Regions • n: normalized reliability indicator • (NC,LR): No congestion, Low reliability • f < fmax, n < 1-e • (NC, HR): No congestion, High reliability • f <= fmax, n < 1+e • (C, HR): Congestion, High reliability • f > fmax, n > 1 • (C, LR): Congestion, Low reliability • f < fmax, n <= 1 • OOR: Optimal Operating Region • f < fmax, 1-e <= n <= 1+e

24. Characteristic Regions

25. Congestion Detection and Reliability Level • Both done at the sink • Congestion: • Nodes monitor their buffer queues and inform the sink if overflow occurs • Reliability Level • Calculated by the sink at the end of each interval based on packets received

26. Congestion Detection • Each sensor watches buffer • Assumption • Incoming traffic to a node in consecutive reporting intervals is constant • If current buffer + last buffer change > maximum buffer  set congestion notification bit

27. ESRT Protocol Operation • (NC, LR): • (NC, HR): • (C, HR): • (C, LR):

28. ESRT: Conclusion • Reliability notion is application-based • No delivery guarantees for individual packets • Reliability and congestion control achieved by changing the reporting rate of nodes • Pushes all complexity to the sink • Single-hop operation only

29. Middleboxes • A challenge to the End-to-End argument • They exist! We do break the argument “A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host.”

30. Why Worry? • New middleboxes challenge old protocols • Old protocols may fail, or perform unpredictably • Middleboxes introduce new failure modes • Routing around failed routers not the only problem • Configuration no longer restricted to the ends • Middleboxes require some configuration • Diagnosing failure more complex • Middlebox configurations could be at fault

31. Classifications for Middleboxes • Protocol layer • Which protocols layers does the middlebox operate in? • Explicit vs. implicit • Was the middlebox anticipated in the design of the protocol, or is the middlebox an add-on • Single-hop vs. multi-hop • How many boxes can be in the path

32. Classifications (cont’d) • In-line vs. call-out • Does the middlebox operate in-line on the data path? • Functional vs. optimizing • Can the application run without the middlebox? • Routing vs. processing • Does the middlebox process the packets in some way?

33. Classifications (cont’d) • Soft state vs. hard state • If a middlebox loses its state, does the session fail? • Failover vs. restart • Does a failed session get moved to another middlebox, or does it have to restart?

34. NAT NAT-PT SOCKS gateway IP Tunnel Endpoints Packet classifiers Transport relay TCP performance enhancing proxies Load balancers IP Firewalls Application Firewalls Application-level gateways Gatekeepers Transcoders Proxies Caches Modified DNS servers Content and applications distribution boxes Load balancers for URLs Application-level interceptors Application-level multicast Involuntary packet redirection Anonymisers Middlebox Taxonomy

35. NAT – Network Address Translator • Often built into routers • Dynamically assign globally unique IP address to host without one • Incompatible with applications with IP address dependencies • Classifications: IP layer, implicit, multihop, inline, functional, processing, hard, restart

36. IP Firewalls • Often built into routers • Rejects or accepts packets based on higher layer header information • Cause connectivity problems that can be hard to diagnose • Classifications: IP layer, implicit, multihop, in-line, functional, routing, hard, restart

37. Proxies • An intermediary program that acts as a client and server • Makes requests on behalf of a client and then serves the result • Often associated with a firewall • Classifications: Application layer, explicit (HTTP), multihop, in-line, functional, processing, soft, restart

38. Summary of Classifications of 22 types of Middleboxes • 17 are application or multi-layer • 16 are implicit • 17 are multi-hop • 21 are in-line • 18 are functional • 16 have hard state • 21 must restart

39. What does this imply? • Most require restart • Most are in-line • Most are implicit and application or cross-layer This is a real challenge to the End-to-End argument

40. End-to-End and Middleboxes • Many middleboxes act as a final destination • But does this mean they do not violate the End-to-End argument? “Although the rise of middleboxes has negative impact on the end to end principle at the packet level, it does not nullify it as a useful or desirable principle of application protocol design.”

41. Is there a middle-ground when considering middleboxes? • Can we just design protocols ignoring middleboxes? “However, future application protocols should be designed in recognition of the likely presence of network address translation, packet diversion, and packet level firewalls, along the data path.”

42. Conclusion • The End-to-End argument • Old standby • Life gets complicated when it is broken • ESRT: Events not nodes are the ends • Allows a new way to control reliability • Middleboxes • We DO break the end-to-end argument

43. Future • Don’t forget the end-to-end argument • However: consider the existence of middleboxes during the design of new end-to-end protocols