dissecting round trip time on the slow path with a single ... · dissecting round trip time on the...

Dissecting Round Trip Time on the

Slow Path with a Single Packet

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

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

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.

Introduction

Italian Networking Workshop 2015 2

• 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?

Example scenario 1• You are in a corporate network, reaching the Internet through one

or multiple providers

• You are experiencing bad performance


• You want to understand if the provider is responsible

• To file a ticket

• To switch provider

• …

Example scenario 2

• You are at home and observe anomalous performance


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

• 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!

In general…


hard!

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

• Traceroute and Ping?

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 intermediate

hops higher than the RTT of the destination

Dissecting the Round Trip Time: ping

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


Same problem here: the RTT to intermediate hops

may appear higher than the RTT to the destination

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

What happens?


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. …

Goal: dissect the RTT into two chunks, at one

router

• Approach: use a single IP Timestamp probe

• Setting

Our proposal


• Setting

• dissects at a router that

• appears on both forward and reverse path

• honors the IP Timestamp option

• 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

IP timestamp option


• It has been used by several works recently for multiple

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

D

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


S

W

TS1

Forward Path Reverse Path

Local clock at S

Local clock at W

Local clock at D


D






S

W

TS1

TW1


Local clock at S

Local clock at W

Local clock at D

D

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





S

W

TS1

TW1

TD1


Local clock at S

Local clock at W

Local clock at D

D






S

W

TS1

TW1

TD1


TD2

Local clock at S

Local clock at W

Local clock at D

D






S

W

TS1

TW1

TD1


TD2

TW2Local clock at S

Local clock at W

Local clock at D

D






S

W

TS1

TW1

TD1

TS2


TD2

TW2Local clock at S

Local clock at W

Local clock at D

D






S

W

TS1

TW1

TD1

TS2


RTT (S,D)

TD2

TW2Local clock at S

Local clock at W

Local clock at D

D





RTT(W,D)


S

W

TS1

TW1

TD1

TS2


RTT (S,D)

TD2

TW2Local clock at S

Local clock at W

Local clock at D

D






RTT(W,D)


S

W

TS1

TW1

TD1

TS2


RTT(S,W)

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

Our proposal: summary


• 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

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


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 LAN)

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 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


• 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 v

hops 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 casesUse 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

Destination RTT > Intermediate 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

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

Results on home network contribution 2/2


destinations

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

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


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?Any question?

[email protected]

dissecting round trip time on the slow path with a single ... · dissecting round trip time on the...

Documents