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 didn’t 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 Tulip’s inferences • Consistency between Tulip and Paths

21. Two facts • Locating Loss and Delay in the Internet • Persistence of Faults

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?