End-to-End Issues - PowerPoint PPT Presentation

1 / 43
About This Presentation
Title:

End-to-End Issues

Description:

End-to-End Issues Al Harris CS 598ig 9/28/2005 Where is the Work Done? In the network Sensor fusion Active networks NAT At the endpoints Using acknowledgements for ... – PowerPoint PPT presentation

Number of Views:192
Avg rating:3.0/5.0
Slides: 44
Provided by: Unkn312
Category:
Tags: end | issues | life

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com