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 cant be done correctly
• Dont 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
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 wont
  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 lt fmax, n lt 1-e
• (NC, HR) No congestion, High reliability
• f lt fmax, n lt 1e
• (C, HR) Congestion, High reliability
• f gt fmax, n gt 1
• (C, LR) Congestion, Low reliability
• f lt fmax, n lt 1
• OOR Optimal Operating Region
• f lt fmax, 1-e lt n lt 1e

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 gt 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 (contd)

• 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 (contd)

• 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
Middlebox Taxonomy

• 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

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

• Dont forget the end-to-end argument
• However consider the existence of middleboxes
  during the design of new end-to-end protocols