dissecting the round trip time: issuewpage.unina.it/pietro.marchetta/pubs/bottapam14slide.pdf ·...

Dissecting Round Trip Time on the Slow

Path with a Single Packet

Pietro Marchetta, Alessio Botta, Ethan Katz-Bassett, Antonio Pescapè

University of Napoli Federico II, Napoli, ItalyUniversity of Southern California, Los Angeles, CA, USA

Passive and Active Measurements Conference, Marina del Rey, March 2014 2

Round Trip Time (RTT): time to send a data packet and receive its response

• Often used to infer the status of the network or of a network path (e.g. through ping)

• For deriving application performance, for detecting anomalies, etc.

Problem: RTT comprises all the delays experienced along the forward and reverse path!

Which part of the network is giving which contribution to the RTT?

Introduction


Example scenario 1

• You want to understand if the provider is responsible• To file a ticket

• To switch provider

• …

• You are in a corporate network, reaching the Internet through one or multiple providers

• You are experiencing bad performance


Example scenario 2

• You would like to know if the issue has to do with your home network (e.g. your son using bandwidth-hungry apps)

• You are at home and observe anomalous performance


• We want to dissect the RTT in its components in order to isolate the contributions of the different parts of the network

• Teasing apart the contributing factors of RTT values is hard!

How to evaluate the relative impact of each subpathon the total experienced RTT?

• Traceroute and Ping?

In general…


We may do a traceroute towards the destination and observe the

various RTT reported by the tool

Dissecting the Round Trip Time: traceroute

AS2907

AS7527

AS4675

Average

It is not uncommon to observe RTT of intermediatehops higher than the RTT of the destination


Dissecting the Round Trip Time: ping

Same problem here: the RTT to intermediate hops

may appear higher than the RTT to the destination

We may do a traceroute towards the destination and then ping an

intermediate hop and the destination, and compare the RTT

Destination RTT > Intermediate RTT

Destination RTT < Intermediate RTT


• The RTT to intermediate hops may appear higher than the RTT to the destination for several reasons

1. Different probes experiencing different network conditions

2. Intermediate hop not part of the reverse path

3. Intermediate hop very slow answering

4. Forward path toward the intermediate hop not part of the forward path toward the destination

• destination-based routing

5. …

What happens?


Goal: dissect the RTT into two chunks, at one router

• Approach: use a single IP Timestamp probe

• Setting

• dissects at a router that

• appears on both forward and reverse path

• honors the IP Timestamp option

Our proposal


• Lets the sender specify up to four IP to request

timestamp from

• The incoming option is replicated by the destination

inside the ICMP Echo Reply

• It has been used by several works recently for multiple

objectives (alias resolution, infer router CPU load, etc.)

IP timestamp option


S

D

W

Using a single packet equipped with the Timestamp option

Our proposal: how it works

Key Idea: the intermediate hop is requested to insert one Timestamp along the forward and reverse path

TS1

Forward Path Reverse Path

Local clock at S

Local clock at W

Local clock at D



S

D

W



TS1

TW1


Local clock at S

Local clock at W

Local clock at D


S

D

W

Our proposal: how it worksUsing a single packet equipped with the Timestamp option


TS1

TW1

TD1


Local clock at S

Local clock at W

Local clock at D


S

D

W



TS1

TW1

TD1


TD2

Local clock at S

Local clock at W

Local clock at D


S

D

W



TS1

TW1

TD1


TD2

TW2Local clock at S

Local clock at W

Local clock at D


S

D

W



TS1

TW1

TD1

TS2


TD2

TW2Local clock at S

Local clock at W

Local clock at D


S

D

W



TS1

TW1

TD1

TS2


RTT (S,D)

TD2

TW2Local clock at S

Local clock at W

Local clock at D


S

D

W



TS1

TW1

TD1

TS2


RTT(W,D)

RTT (S,D)

TD2

TW2Local clock at S

Local clock at W

Local clock at D


S

D

W




TS1

TW1

TD1

TS2


RTT(S,W)

RTT(W,D)

RTT (S,D)

TD2

TW2Local clock at S

Local clock at W

Local clock at D


• Simple approach• Single packet

• Collects 6 timestamps, 2 from source, 2 from intermediate hop and 2 from destination

• Standard ping tool

• Works on the slow path

• It needs a compliant router along path• Honors the timestamp option

• Appears on both forward and reverse path

Our proposal: summary


Evaluation

Applicability of the proposed approach• We evaluated how many nodes per path are available for

dissecting the RTT (i.e. are compliant with our approach)

• And where they are located along the path

Two use cases as proof of concept• Understanding if an anomalous behavior is caused by the ISP

(isolating the contribution of an entire AS)

• Understanding if an anomalous behavior is caused by the home network (isolating the contribution of this network)


Applicability: experiments performed

• We identified a set of compatible destinations

• Honor the timestamp option and are not extra-stampers

• 36% of 1.7M IP addresses probed are compliant

• We randomly selected one representative IP for each AS

• We have 3,133 distinct Ases

• We performed traceroute towards these destinations and probed all intermediate hops from 116 PlanetLab nodes

• Our next results are based on a dataset that comprises 223, 548 distinct paths


Applicability: results 1/2

• About 77.4% of the paths contain at least one compliant node

• And 27.3% contain more than four compliant nodes

• On average, we observed 2.5 compliant nodes per path

• On average, about 17% of the nodes in each scanned path are compliant


Applicability: results 2/2• We evaluated the hop distance

of the compliant nodes from the edges

• We evaluated number of compliant nodes on the path p appearing within vhops from the source or the destination

overall number of compliant nodes

• About 72% of all the compliant nodes are within 5 hops from the source or the destination, and about 15% within one hop

• Symmetry does not only happen toward the edges

Use cases


Assessing the contribution of an AS to the RTT

• We want to evaluate the contribution of our AS to the RTT toward some destination

• The experiment has been run from PlanetLab

• We show the results of an AS from Japan

AS2907

AS7527

AS4675


Results on AS contribution to the RTT

• Difference between RTT to destination and to intermediate hop is always > 0

• The average contribution of AS2907 is 76.8%• It is 106% according to ping!

Destination RTT > Intermediate RTT

Destination RTT < Intermediate RTT


Assessing the contribution of the home network

• Inside a home network

• We found compatible home routers• NETGEAR DGN2200v3

• We also found compatible second hops• Allowed to isolate the contribution of the last mile

• We evaluated the contribution of the home network and of the last mile

• We performed experiments during several days and we show the interesting results


Results on home network contribution 1/2

• During an overloaded period, the RTT grew in median by 356% (from 69.8 ms to 249 ms)

• The home network always played a marginal role (4.7% of RTT in unloaded and 2.6% in overloaded)


• Monitoring the RTT of the last mile and of the home network

• We artificially induced congestion toward some destinations

• Congestion did not affect the RTT of the home network but that of the last mile

Results on home network contribution 2/2


Conclusion• We presented an approach to dissect the RTT on the

slow path

• Other techniques based on ping and traceroute may provide misleading results

• Our approach uses a single packet with the IP Timestamp option and requires a compliant router along the path

• A large-scale measurement study from 116 vantage points comprising 223K paths showed that 2.5 router per path on average are compliant

• We reported two use cases to show the possible uses of this approach

Thanks!!

Any question?

[email protected]

dissecting the round trip time: issuewpage.unina.it/pietro.marchetta/pubs/bottapam14slide.pdf ·...

Documents