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?