1. Pong: Diagnosing Spatio-Temporal Internet Congestion Properties
Leiwen Deng and Aleksandar Kuzmanovic, Northwestern University
Northwestern Networks Group (
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
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