User-level Internet Path Diagnosis

1
User-level Internet Path Diagnosis

• Ratul Mahajan, Neil Spring, David Wetherall and
  Thomas Anderson

Designed by Yao Zhao
2
A distributed system is one in which the failure
of a computer you didnt even know existed can
render your own computer unusable.

• L. Lamport

3
Motivation

• Can end users, with no special privileges
  identify and pinpoint faults inside the network
  that degrade the performance of their
  applications?
• Why (unprivileged) end users?
• Operators do not share the users view of the
  network
• Operators may have no more insight than
  unprivileged users for problems inside other
  administrative domains
• user can directly contact the responsible ISP
  leading to faster problem resolution
• Many techniques are more effective and scalable
  with fault localization than blindly trying all
  possibilities

4
Outline

• Diagnosis architecture
• Diagnosis Tool Tulip
• Evaluation
• Recommendations
• Conclusion

5
Problem
6
An Ideal Trace-based Solution

• Routers log packet activity and make these traces
  available to users.
• The log at each router is recorded for both input
  and output interfaces.
• impractical for deployment

7
Packet-based Solutions

• Complete Embedding
• Each router along the path records information
  into each packet that it forwards.
• Barring two exceptions, the scheme above is
  equivalent to the path trace.
• Reduced Embedding
• Remove the step of embedding the complete input
  packet in the output packet
• Constant Space Embedding
• Sample TTL
• Real Clocks
• Unsynchronized clock
• Finite precision

8
New Fields of Packet Header in the Architecture
9
Outline

• Diagnosis architecture
• Diagnosis Tool Tulip
• Evaluation
• Recommendations
• Conclusion

10
Internet Approximations

• Out-of-band measurement probes
• ICMP timestamp requests to access time at the
  router
• IP identifiers instead of per-flow counters

11
Packet Reordering
12
Assumptions for Packet Loss

• IP-IDs are consecutive
• 80 of the time from over 90 of the routers
• Small size packets usually have low loss rate
• In over 60 of the cases when any packet in the
  triplet was lost, only the data packet was lost.
• ICMP rate-limiting will not be mistaken as packet
  loss
• 1 more check packet

13
Packet Loss
14
Packet Queuing

• Similar to cing
• Two practical problems
• ICMP generation time
• Cable modems and wireless links

15
Tulip

• Network Load
• BL/W
• Diagnosis time
• 10 30 min per path
• Parallel search vs Binary search
• Two or more faults?

16
Outline

• Diagnosis architecture
• Diagnosis Tool Tulip
• Evaluation
• Recommendations
• Conclusion

17
Methodology

• Evaluate applicability
• Diagnosis granularity
• Three sources MIT, U Washington and London
• Destinations from Skitter
• Validation

18
Diagnosis granularity (1)
19
Diagnosis granularity (2)
20
Validation

• IP-IDs and ICMP timestamp vs End-to-end
  measurement
• Tulip vs Sting
• Consistency of Tulips inferences
• Consistency between Tulip and Paths

21
Two facts

• Locating Loss and Delay in the Internet
• Persistence of Faults

22
(No Transcript)
23
Outline

• Diagnosis architecture
• Diagnosis Tool Tulip
• Evaluation
• Recommendations
• Conclusion

24
Limitations of Tulip

• Out-of-band measurements
• Stable routing path
• IP-ID counters
• Limitations of ICMP timestamps

25
In-band vs Out-of-band Diagnosis

• Priority of protocols
• Packet drop
• Packet size
• Loss rate
• Reordering

26
Other Recommendations

• Path Verification
• IP Identifiers
• Router Timestamps

27
Related Works

• Diagnosis Approaches
• Magpie
• SPIE
• NetFlow
• Measurement Primitives
• Overlay primitives
• IPMP
• Measurement Tools
• PING, Traceroute, pathchar, Sting

28
Conclusion

• Tulip
• Practical tool to diagnose packet reordering,
  loss and queuing
• Diagnosis architecture
• In-band
• Lightweight

29
Questions?