Data-Plane Accountability with In-Band Path Diagnosis

1. Data-Plane Accountability with In-Band Path Diagnosis Murtaza Motiwala, Nick FeamsterGeorgia Tech Andy BavierPrinceton University

2. Internet Routing Lacks Accountability • Control Plane: Messages can be falsified • Misconfiguration: AS 7007, ConEdison route leak • Malice: Spammers stealing address space • Data Plane:Data traffic is not guaranteed to travel where the routing protocol indicates • Paths may not perform well • Even if a faulty path cold be located, no recourse This talk: Detecting and isolating faulty elements and nodes.Some discussion about recourse.

3. What is Data-Plane Accountability? • Mechanisms to detect and locate sources (and causes of bad behavior) • Causes may be benign or malicious • Congestion • Faulty links • Denial of service attack • Recourse to avoid faulty or malicious elements • Scalable network support for path diversity

4. Possible Mechanism: Out-of-Band • Approach: Send additional probe traffic to capture network conditions • Ping, traceroute, pathchar, etc. • Problem: Measured performance may not reflect conditions experienced by data traffic • May not capture transient faults • Probes may be treated differently • Introduces additional probe traffic, which may affect observed performance

5. “The research agenda in measurement must change to consider measurement solutions which enlist the cooperation of routers. The need is so urgent that the deployment...can be finessed by cooperation between a few key ISPs. There is a rich vein of technical problems, hitherto considered only from an active measurement perspective, for which there can be new and effective...solutions.” —Varghese and Estan, The Measurement Manifesto

6. Alternative: In-Band Path Diagnosis • Store information about network diagnostics in the packet itself. • Advantage:Diagnostic information reflects information actually experienced by data traffic. • Challenges • Lost data packets mean lost diagnostics • Distinguishing loss and reordering • Recovering diagnostic information (from the receiver) • Packet marking and storage requirements

7. Design Considerations • Localization granularity: With what precision should a fault be located? • From within a few ASes to actual network element • Statistics granularity: With what precision should statistics be captured? • From coarse, per-flow statistics to per-packet statistics • Storage:How much state should be stored, and where should it be stored? • In the router vs. in the packet

8. Design Considerations (cont.) • Modifications to packet format: Modify packet format, or squeeze data into existing headers? • Robustness to malice: Should the scheme be robust in the face of malice? • Off-path: Hosts or routers off of the data path try to disrupt communication • On-path: Malicious hosts or routers on-path may lie

9. Problem:Network elements drop packets, fail, and otherwise give rise to poor performance One Solution: In-Band Path Diagnosis Routers keep track of number of packets seen per flow Each router stamps each packet with current flow counter value If current counter value does not equal router’s expected packet count for that flow, router marks packet New Shim Header IP Header Data-Plane Accountability High-level Overview Transport header

10. Detailed Operation • Suppose R2 and R3 have each lost one packet • Next packet: R2 sees “gap” in counter value • Marks packet with its ID, updates flow counter value • Subsequent packets contain marks for packets further downstream

11. Analysis of Accuracy • Partially accurate: Faulty element identified, but not the correct number of lost packets • Example: Counter overflow • Misleading:Network fault is attributed to the incorrect network element • Example: Packets containing information about packet loss are also lost • No information:No information reported

12. Implementation and Evaluation • Implementation in Click • Two main elements: ModifyIng, ModifyPkt • Deployment on PL-VINI • Evaluation under direct packet drops and induced routing instability

13. Coping: Scalable Path Diversity • Problem:Hosts need mechanisms for recourse when a path does not perform as expected • For example, routing around faulty elements • Solution:Additional bits in the packet header • End host sets bits to indicate • Question: How to scalably provide this function?

14. Coping Mechanism: Multi-Path • Deflection: Bits indicate to routers that the path should change (but not how) • Advantage: Simple • Disadvantage: Limited path diversity without introducing possibility for loops • Path splicing: Bits indicate, at each hop, whether a router should use an alternative path • Challenge: Scalable dissemination and storage of information about alternate paths

15. Conclusion • Routing protocols require better accountability, both in the control plane and the data plane • Data-plane accountability requires complementary in-band mechanisms • Orchid: In-band path diagnosis scheme based on packet marking and counters at routers • Implementation and deployment on PL-VINI • Accurate detection and location of packet loss • Extensible to other properties • Next step: Coping mechanisms