Towards a General Solution for Detecting Traffic Differentiation At

the Internet Access

Riccardo Ravaioli, I3S, FranceGuillaume Urvoy-Keller, I3S, France

Chadi Barakat, INRIA, France

ISPs degrade the performance of selected traffic

• [2007] Comcast interrupts P2P upload transfers

• [2011, 2012] Free throttles bandwidth allocated to YouTube during evening hours

• [2014] Comcast slows down traffic on OpenVPNdefault port

• [2014] Verizon deteriorates connections to Netflix

2

These actions are never advertised

Network Neutrality

• A network is neutral if it treats all traffic flows equally

• No discrimination on– header information (IP src, IP dest, port)

– payload (reveals application)

• Differentiation techniques– Blocking, deprioritizing, packet dropping,

modification of TCP advertised window size,application-level mechanisms

3

Existing Work

4

user serverControl flow(randomized payload, different port)

Application flow (Skype, BitTorrent)

• Compare- Max throughput- Delay and loss distribution at original and high rate- Received rate to infer token bucket parameters

Does not scale to all user applications

Key Ideas in ChkDiff• Goal: be agnostic to

– Targeted applications

– Differentiation mechanisms at layer 3 (IP)

• How?– Consider real user traffic, not synthetic traces

– Replay outgoing traffic to routers at hops close to the user [today’s presentation]

– Replay incoming traffic from a measurement server

– Analyse per-flow delay distribution and losses

5

Any shaping at layers 3 and 7 will result in higher delays and losses We check for differentiation on the exact set of applications run by

the user

ChkDiff: outline

6

user hop h

1. Dump user traffic2. Arrange into 5-tuple flows3. Set same size to all packets

• Same transmission time when replayed

4. Shuffle packets according to flow sizes• PASTA property holds• Each flow sees the same network conditions

5. Replay upstream traffic6. Replay downstream traffic (current/future work)7. Run per-flow statistical analysis on delay distribution and losses

server

ChkDiff: upstream

7

for each hop h ∈ {1,2…k} dofor each run r ∈ {1,2,3} do

replay trace with TTL:=h at a constant rate > original ratecollect ICMP time-exceeded packets

detect shaped flows at hop h

• Compare delay distribution (Kolmogorov-Smirnov test)of each flow to that of all other trace delays

• Check if losses of each flow are consistent with overall losses of the trace (binomial approximation)

➡ Flow is differentiated if rejected in all 3 runs

user hop h server

Responsiveness to TTL-limited probes

• At any given probing rate, routers are

– Unresponsive

– Rate-limited

– Fully responsive

• ICMP rate-limitation appears as:

8

burst

inter-burst time

Large-scale campaign to characterize routers- Probed 850 routers

at hops 1-5 from PL nodes

( 3.9 % )

( 65.9% )

( 30.2 % )

Characterizing ICMP Rate Limitation on Routers, ICC ‘15

ICMP rate limitation: delays• Are RTTs biased by our probing rate?

9

• No correlation between probing rate and resulting RTT

• Not hitting any capacity limits of routers

ChkDiff: validation in neutral set-up

• Why packets with the same size?- For routers at hops 1,2 the delay

variability is comparable to the variability of transmission delays

- Flows with large packets would appear as shaped

10

user shaper router

• Why 3 runs?- False positives disappear with

2 runs- Safer margin of error

ChkDiff: validation in non-neutral set-up

• Throttled bandwidth- applied to selected flows

(fraction 𝑓𝑟 of the trace) - 𝑏𝑤 as a function of overall

sending rate 𝑟 of flows to differentiate (𝑏𝑤 = 𝑘𝑏𝑤 ∗ 𝑟)

11

• Throttled bandwidth + ICMP rate limitation- router responds at 20 pps max- user replays at 30, 50, 80, 100 pps

- When up to 60% of traffic is shaped, no flow is incorrectly flagged

- 80% is too much for baseline to work

- Similar results as in the first case- ICMP rate limitation affects losses, delays

are not altered

ChkDiff: validation in non-neutral set-up• Losses

- uniform drops at rate 𝑙𝑟 on each flow to differentiate

- uniform drops at rate 𝑙𝑟𝑎𝑙𝑙 on the whole trace

12

• Losses + ICMP rate limitation- router responds at 20 pps max- user replays at 30, 50, 80, 100 pps

- Replaying at 5x the ICMP rate limitation

- Results are not significantly altered

ChkDiff: download it!

• Code available on: https://riccardoravaioli.wordpress.com/chkdiff

• Runs on Linux, requires tcpdump & tcpreplay

• Sample output:

13

hop h

[current work] ChkDiff: downstream

14

user server

1. Server replays shuffled trace at a constant rate to user• Depending on the NAT type the user is behind

- We spoof packets (keeping original IP header and contents)

- Or we rewrite the IP src (keeping original src port and contents)

2. Measure one-way delays from server to user3. Run delay and loss analysis as before

Current and future work

• Validation of downstream experiment in a controlled environment

• Measurement campaign in the wild to detect differentiation on French ISPs

15

Thank you!

Towards a General Solution for Detecting Traffic Differentiation At the

Internet Access

Riccardo Ravaioli

ravaioli@i3s.unice.fr