Download ppt

User-level Internet Path Diagnosis
R. Mahajan, N. Spring, D. Wetherall and T. Anderson
The network is a black box…
...so what can I do
1. We want the users to
be able to diagnose
their paths
2. Communicate
information to ISP or
NOC to improve the
network
TULIP: User-level path diagnosis
Objectives:
Detect performance faults that affect a user’s
flows. This involves a measure of the magnitude
of the fault (queuing delay, loss) and the
localization of the faulty link.
How TULIP does it

Ideal Architecture – Packet based solutions
Each router the packet traverses adds a certain number of
information to the packet: timestamp, global address of the
router’s input interface.
Issue: Packet size increases at each hop. A packet loss involves a
loss of all the information. Corruption of a packet might yield
to incorrect diagnosis data (allthough most corruption are
treated as losses)
Because things are never ideal

Basic architecture sufficient for data collection
Assets: Fixed packet size and sufficient information…
Assuming : stationarity of paths (paths between source and
destination don’t change too often)
Diagnosis tools in use in TULIP

Out-of-band measurement probes (or TTL
based search)


ICMP


obtain the Sample TTL and Interface ID
Router timestamp
IP identifiers

Approximation of the per-flow counter
How to detect path loss/reordering
Sending two probes to determine
the behavior of the remote router
Packet queuing
An ICMP timestamp is used to determine the
queuing delays within a router (median)
The TULIP methods

To perform the measurement, TULIP uses two
“scanning” methods.
Binary search (reduces diagnostic traffic but at a cost
of diagnosis time)
 Parrallel search (interleaves measurements to
different routers by cycling through them in nodes)

Network Load and Diagnosis Time


Because of the relative stationary behavior of a
router, with an approximative diagnosis time of
10/30 min, TULIP can provide accurate results.
The load for Binary search is B/W and for
parrallel LB/W (lower bound)
L: # of measurable routers
B: Bandwitdth cost of the probes
W: Wait time (usually 1s)
Diagnosing granularity

The granularity is the weighted average of the
lengths of its diagnosable segments.
1 1 0
G

1 0 1 
Rank(G)=2
1
1’
2’
2
3

1
2
Various granularity for different
measurements
•50 % of the paths have a granularity less than 3 hops (75% <4)
•TULIP matches ideal tomography implementation
Validation


Compared results with Planet Lab coupled with
a tomography system
Use a measure “rate delta” that computes the
difference between the rate at the far end minus
that at the near end of a segment.
Negative values implies a lack of consistency
(values spawn a range too large)
Reordering Results
85 % of the results are consistent for forward path
75 % for round trip (due to the asymmetric nature of some paths)
Loss results
•85% again of non negative deltas
•Round trip counterpart less affected by asymmetry than the Reordering
diagnosis (because loss usually occurs close to the destination)
Queuing Results
•ICMP message generation has a poor timestamp resolution (the two median within
2ms of each other – One from TCPDump on planet lab and one from TULIP).
•Forward path shows that queuing delay is consistent (very few negative values)
•Round trip reflects the variability in the return path
The last mile…

First hops from user is the bottleneck
Persistance of a fault
•We check for how many iterations, TULIP yields similar results
•80% of the path show faults persisting long enough for TULIP to
diagnose them (typical time a binary search takes to locate a fault : 6
runs)
Conclusions


Network Operators would be able to diagnose
links efficiently
And a user too … if the world was populated
entirely by Computer nerds.
Issues…


Multiple TULIP users could reduce the accuracy
of the probing method, the per flow counter
An application doesn’t experience the network
the same way an active measurement does. (TCP,
application dependant as well as flags)
…and possible improvements



Per flow counter at the router level (unrealistic)
Hash source address and IPID (for flow)
ICMP timestamp have reception time as well as
transmission time (allows the calculation of the
delay the packet is processed at the router)