Pong: Diagnosing Spatio-Temporal Internet Congestion Properties Leiwen Deng and Aleksandar Kuzmanovic, Northwestern University Northwestern Networks Group (http://networks.cs.northwestern.edu) Supported by Cisco Collaborative Research 1. Motivation and Approach Motivation. The ability to accurately detect congestion events in the Internet and reveal their spatial (where they happen) and temporal (how long they last) properties would significantly improve our understanding of how the Internet operates. Recent 30 seconds (updated every 10 seconds) 4.8 2.4 1 2 3 4 5 6 7 8 9 Recent 10 seconds (updated every 10 seconds) 1.6 0.8 Recent 1 minute (updated every 10 seconds) 10.4 5.2 Recent 10 minutes (updated every 1 minute) Recent 3 minutes (updated every 1 minute) Recent 30 minutes (updated every 10 minutes) Recent 3 hours (updated every 1 hour) 581.9 290.9 Recent 1 hour (updated every 10 minutes) 473.4 236.7 Recent 6 hours (updated every 1 hour) 242.2 121.1 112.7 56.4 35.2 17.6 Congestion points located by Pong Graph: Congestion count vs. link # Locating congestion points. Pong is a tool that detects congestion on a unidirectional path with high resolution and high accuracy. It locates congestion on granularity of a single link. It performs well in detecting multiple congested links on the forward path and in decoupling congested links on the backward path. Monitoring congestion points. Once a congested link is detected, Pong traces congestion status on that link. The light-weight nature of Pong makes Pong also a competent network monitoring tool rather than only an on-demand probing tool. The web front end and command line interface (CLI) provided by Pong facilitate measurement and monitoring jobs. 2 3 4 5 6 7 8 9 1 Sender Receiver probe Congestion Link # ~ Link 7 Link 1 Link 2 Link 5 Link 8 Link 3 Link 4 Link 9 Link 6 Congestion status traced by Pong Graph: Congestion intensity vs. time An example scenario: There is congestion on link 1, 5 and 8. We probe the path from the sender and the receiver with Pong. We quantify congestion properties on each link with two measures – congestion count and congestion intensity. 2. Methodology f s b d Pairing Complementary d probe Congestion D S Pair up an s probe with a d probe 3. Implementation Source code and sample measurement outputs of Pong are available at http://networks.cs.northwestern.edu/pong Promote Demote Coordinated Probing Highlights Tested on Fedora Core 4/5 Linux. Use libpcap to retrieve kernel level timestamps. Single path measurement or monitoring; large-scale Internet measurement. Extensive log information for error diagnosing. S D f s d b Probe A Symmetric Path Scenario pong_snd pong pong_daemon Web front end Statistic kits File Control pong_rcv Control channel Collect data Control & monitor Internet pongc General Scenario Four probing packets in a coordinated way: Use f, s, d probe only f s b d Pairing Complementary d probe D S Observed by b probe only Use, f, s, b probe only No complementary d probe available Two Minor Scenarios f probe: end-to-end, from source b probe: end-to-end, from destination s probe: to an intermediate node, from source d probe: to an intermediate node, from destination Components Illustration of Pong Locating Congestion Points pong_snd The sender side of Pong. pong_rcv The receiver side of Pong. The sender side and receiver side communicate with each other through a TCP control channel and measure congestion by sending UDP probes. pong An interactive command tool that allows users to remotely control and monitor pong_snd and pong_rcv. pong_daemon A daemon process that supervises pong_snd and pong_rcv. It facilitates automated measurements. pongc A tool that allows users to remotely control or query pong_daemon. It is essential to perform centralized control in large-scale Internet measurements. S D Probe Switch Point Approach Correlate probes to neighboring nodes Detect Switch Point Update Congestion Count Congestion Point Detected Congestion Count > Threshold Tracing Congestion Status S D Probe Reuse probes to all intermediate nodes Tracing Congestion Status of Detected Congestion Points 4. Evaluation Simulation-based Evaluation using ns2 Self-consistency Validation through Large-scale Internet Experiments Emulation Experiments on Emulab Testbed 5. Measurement Per Cong. Event Per Path Segment Duration (minutes) Cong. Intensity Cong. Time Frequency Density All 1.93 0.063 0.0033 0.032 0.105 Intra-AS Inter-AS 2.03 1.54 0.070 0.043 0.0046 0.0011 0.041 0.019 0.113 0.059 Edge Core 2.31 1.50 0.081 0.044 0.0058 0.0013 0.047 0.020 0.124 0.068 Intra-AS (edge) Inter-AS (edge) 2.37 1.53 0.084 0.0068 0.054 0.018 0.060 Intra-AS (core) Inter-AS (core) 1.49 0.045 0.0016 0.021 0.074 0.057 Congestion Measure Spatial Taxonomy Experimental Setup A large-scale Internet experiment using 334 PlanetLab hosts (167 senders and 167 receivers). Measured 21,861 paths within 10 days. Measure each path for 100 minutes. An Emulab Experiment Example 12 nodes, 11 links (100Mbps, 2ms). Use TCP on/off traffic to build congestion on links. 1 2 3 4 5 6 7 8 0.37s on/off 0.71s on/off 0.53s on/off 0.47s on/off 0.83s on/off 12 11 10 9 Measurement Results The network edge is 4.5 times more congested than the core on average. However, once the congestion happens, per event congestion intensity at the edge is only 1.84 times larger than that in the core on average. The phenomenon of “heavily” congested edges is actually dominated by congestion on intra-AS links. Inter-AS links behave almost the same at edges and in the core. Congestion events at edges are relatively clustered in time, while dispersed in the core. Approximately 17% of path segments we measured experience congestion; but only 1% of path segments experience congestion more than 10% of time. Almost 52% of end-to-end paths experience non-trivial congestion and 7.3% of them experience considerable congestion. The probability to observe multiple congested points on an end-to-end path over a given time interval grows as a power function of the interval length, and decays exponentially with the number of congested points. Initially, there are three congestion points (link 1, 6 and 9). Spatio-Temporal Congestion Properties (Average Values of Congestion Measures) After adding two additional congestion points (link 5 and link 9) on backward direction. After adding two additional congestion points (link 5 and link 11) on forward direction. 1 2 3 4 5 6 7 8 0.37s on/off 0.71s on/off 0.53s on/off 12 11 10 9 0.29s on/off 0.63s on/off