Service traceroute: Tracing Paths of Application Flows Ivan Morandi To cite this version: Ivan Morandi. Service traceroute: Tracing Paths of Application Flows. Networking and Internet Architecture [cs.NI]. 2018. hal-01888618 HAL Id: hal-01888618 https://hal.inria.fr/hal-01888618 Submitted on 5 Oct 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Service traceroute: Tracing Paths of Application Flows Ivan Morandi Supervisors: Renata Teixeira, Timur Friedman Advisor: Francesco Bronzino Inria / UPMC Sorbonne University, Paris ABSTRACT Luckie et al. [7] have shown that depending on the Traceroute is often used to help diagnose when users experi- traceroute probing method (ICMP, UDP, and TCP) the ence issues with Internet applications or services. Unfortu- set of reached destinations and discovered links differ. nately, probes issued by classic traceroute tools differ from The authors explain these differences by the presence application traffic and hence can be treated differently by of middleboxes in the path such as load balancers and middleboxes within the network. This paper proposes a new firewalls that make forwarding decisions based on flow traceroute tool, called Service traceroute. Service tracer- characteristics. These results imply that diagnosing is- oute leverages the idea from paratrace, which passively lis- sues on application flows must ensure that traceroute tens to application traffic to then issue traceroute probes that probes have the same characteristics as the application's pretend to be part of the application flow. We extend this idea packets. to work for modern Internet services with support for auto- This paper develops a traceroute tool, called Service matically identifying application flows, for tracing of multi- traceroute, to allow discovering the paths of individual ple concurrent flows as well as for UDP flows. We imple- application flows. Service traceroute passively listens ment command-line and library versions of Service tracer- to application traffic to then issue probes that pretend oute, which we release as open source. This paper also to be part of the application flow. Some traceroute presents a calibration and an evaluation of Service traceroute tools (for instance, paratrace [4], TCP sidecar [10], and when tracing paths traversed by Web downloads from the 0trace [3]) already enable probes to piggyback on TCP top-1000 Alexa websites and by video sessions from Twitch connections. These tools observe an active TCP con- and Youtube. The goal of the calibration is to find the best nection to then insert traceroute probes that resemble parameters of Service traceroute for each application. Our retransmitted packets. TCP sidecar was developed for evaluation shows that Service traceroute has no negative side topology mapping, whereas paratrace and 0trace for effect on the vast majority of downloads, but that in some tracing pass a firewall. As such, they lack of two im- rare cases it can cause application flows to abort or increase portant features in application debugging. The identi- flow completion times. In addition, the evaluation shows fication of the application flows to trace as they require that Service traceroute obtains different paths in at least 30% as input the destination IP address and the destination of paths when compared with a standard traceroute. Using port to detect the target application flow, and the sup- the same source and destination ports as the target applica- port for tracing paths of modern application sessions, tion flow to analyze for standard traceroute’s probes, Service which fetch content over multiple flows that change traceroute still obtains different paths in at least 7% of ana- dynamically over time. In addition, these tools lack lyzed paths. the support for tracing application flows using UDP as transport protocol, which are increasing thanks to the 1. INTRODUCTION adoption of QUIC protocol [5] in new services as well as in popular services like Youtube. Our work makes Internet services and applications rely on highly dis- the following contributions. First, we develop and im- tributed infrastructures to deliver content. When ap- plement Service traceroute (x2), which we will release plications stop working or when their performance de- as open source software. Service traceroute is capa- grades, service providers and more sophisticated users ble of identifying application flows to probe and trac- often resort to traceroute to narrow down the likely lo- ing the paths of multiple concurrent flows of both TCP cation of the problem. Traceroute issues probes with and UDP flows. For example, a user may simply spec- increasing TTL to force routers along the path towards ify trace `Youtube' and Service traceroute will identify a destination to issue an ICMP time exceeded message Youtube flows and then trace all of their paths. Ser- back to the source, which iteratively reveals the IP ad- vice traceroute is configurable to cover a large variety dresses of routers in the path [2]. of Internet services. Traceroute, however, may fail to reveal the exact path Our second contribution is the calibration of Service that a given application flow traverses. For example, 1 traceroute for two popular Internet services: video and 2.1 Observation of target application flow web pages, in particular, the top-1000 Alexa websites as Service traceroute passively observes traffic travers- well as Twitch and Youtube video streaming. The goal ing a network interface to search for packets with the of the calibration is to find the parameters of Service flow-id of the target application flows2. One novelty of traceroute with the best trade-off between the prob- Service traceroute is that it takes a set of target applica- ing network overhead and the amount of information tion flows as input, in contrast with previous tools which gathered. The problem of Service traceroute is that ap- can only trace the path traversed by one single applica- plication flows may close before Service traceroute ends tion flow. Users can either explicitly specify one or more the tracing, and hence middleboxes along the path may target application flows or they can simply specify a ser- discard Service traceroute's probes. vice. Service traceroute uses a database of signatures of We then use the configurations with the best trade- known services to inspect DNS packets in real-time and off for the third contribution: evaluate Service tracer- identify flows that match the target service. We release oute. We focus the evaluation on the same Internet ser- the DB as open source, so users can contribute to add or vices used during the calibration. One issue with piggy- update the signatures in the database. We define as sig- backing probes with application traffic is that we may nature the set of IP addresses and domains correspond- hurt application performance. Our evaluation shows ing to a specific service. For instance, `google.com' or that in the vast majority of cases, Service traceroute the corresponding IP addresses can be used in the sig- has no side-effect on the target application (x5). For a nature to detect Google services. Our current database few websites, however, application flows get reset when has signatures for popular video streaming services such running with Service traceroute. This result indicates as Netflix, Youtube, and Twitch. Web pages are not in- that piggybacking traceroute probes within application cluded in the database as Service traceroute can iden- flows requires careful calibration to avoid hurting user tify web flows simply from the domain or the host name experience. Finally, we compare Service traceroute with given as input. For additional flexibility, it is possible 0Trace, which also embeds probes within a target appli- to easily add ad-hoc domains and IP addresses via com- cation flow, and with Paris Traceroute, which launches mand line parameters or through the library API. a new flow for probing (x6). Our comparison with Paris traceroute shows differences in 37% of paths with 2.2 Path tracing Twitch, 9% with Youtube and 7% with web pages, even Only once it identifies a packet belonging to the tar- when running Paris traceroute with the same ports as get application flow, Service traceroute will start the the target application flow. We noticed that in some tracing phase. This phase works as classic traceroute paths with web pages and Youtube videos, middleboxes implementations sending probes with increasing TTL, discard UDP and TCP probes of Paris Traceroute be- but Service traceroute creates a probe that takes the fore they reach the destination. form of an empty TCP acknowledgement that copies the 5-tuple of the flow as well as its sequence number 2. TOOL DESIGN AND IMPLEMENTATION and acknowledgement number (similar to paratrace and Service traceroute follows the same high-level logic 0trace). We rely on the flow-id plus the IPID field to as paratrace or 0trace. Given a target application flow, match issued probes with the corresponding ICMP re- which we define as the application flow whose path sponses. We note this is sufficient to correctly identify we aim to trace, Service traceroute proceeds with two probes even when tracing multiple concurrent target ap- main phases. The first phase is the passive observa- plication flows. The maximum number of concurrent tion of a target application flow to define the content of target application flows varies based on the used con- the probes. Then, the active injection of TTL-limited figuration as the IPID field is dynamically sliced based probes within the application flow.