Pietro Marchetta

Topology Discovery at the Router Level: A New Hybrid Tool Targeting ISP Networks

For a long time, traceroute measurements combined with alias resolution methods have been the sole way to collect Internet router level maps. Recently, a new approach has been introduced with the use of a multicast management tool, mrinfo, and a recursive probing scheme. In this paper, after analyzing advantages and drawbacks of probing approaches based on traceroute and mrinfo, we propose a hybrid discovery tool, Merlin (MEasure the Router Level of the INternet), mixing mrinfo and traceroute probes. Using a central server controlling a set of distributed vantage points in order to increase the exploration coverage while limiting the probing redundancy, the purpose of Merlin is to provide an accurate router level map inside a targeted Autonomous System (AS). Merlin also takes advantage of alias resolution methods to reconnect scattered multicast components. To evaluate the performance of Merlin, we report experimental results describing its efficiency in topology exploration and reconstruction of several ASes.

Measuring network throughput in the cloud

Cloud providers employ sophisticated virtualization techniques and strategies for sharing resources among a large number of largely uncoordinated and mutually untrusted customers. The shared networking environment, in particular, dictates the need for mechanisms to partition network resources among virtual machines. At the same time, the performance of applications deployed over these virtual machines may be heavily impacted by the performance of the underlying network, and therefore by such mechanisms. Nevertheless, due to security and commercial reasons, providers rarely provide detailed information on network organization, performance, and mechanisms employed to regulate it. In addition, the scientific literature only provides a blurred image of the network performance inside the cloud. The few available pioneer works marginally focus on this aspect, use different methodologies, operate in few limited scenarios, or report conflicting results.In this paper, we present a detailed analysis of the performance of the internal network of Amazon EC2, performed by adopting a non-cooperative experimental evaluation approach (i.e.?not relying on provider support). Our aim is to provide a quantitative assessment of the networking performance as a function of the several variables available, such as geographic region, resource price or size. We propose a detailed methodology to perform this kind of analysis, which we believe is essential in a such complex and dynamic environment. During this analysis we have discovered and analyzed the limitations enforced by Amazon over customer traffic in terms of maximum throughput allowed. Thanks to our work it is possible to understand how the complex mechanisms enforced by the provider in order to manage its infrastructure impact the performance perceived by the cloud customers and potentially tamper with monitoring and controlling approaches previously proposed in literature. Leveraging our knowledge of the bandwidth-limiting mechanisms, we then present a clear picture of the maximum throughput achievable in Amazon EC2 network, shedding light on when and how such maximum throughput can be achieved and at which cost.

Don't trust traceroute (completely)

In this work, we propose a methodology based on the alias resolution process to demonstrate that the IP level view of the route provided by traceroute may be a poor representation of the real router-level route followed by the traffic. More precisely, we show how the traceroute output can lead one to (i) inaccurately reconstruct the route by overestimating the load balancers along the paths toward the destination and (ii) erroneously infer routing changes.

Detecting third-party addresses in traceroute traces with IP timestamp option

Traceroute is one of the most famous and widely adopted diagnostic tool for computer networks. Although traceroute is often used to infer links between Autonomous Systems (ASes), the presence of the so-called third-party (TP) addresses may induce the inference of false AS-level links. In this paper, we propose a novel active probing technique based on the IP timestamp option able to identify TP addresses. For evaluating both the applicability and the utility of the proposed technique, we perform a large-scale measurement campaign targeting --- from multiple vantage points --- more than 327K destinations belonging to about 14K ASes. The results show how TP addresses are very common and affect about 17% of AS-level links extracted from traceroute traces. Compared to a previously proposed heuristic method, our technique allows to identify many more TP addresses and to re-interpret part of its results.

On Network Throughput Variability in Microsoft Azure Cloud

The dependence of the industry on cloud-based infrastructures has grown much faster than our understanding of the performance limits and dynamics of these environments. An aspect only marginally analyzed in the past is related to the performance of the intra-cloud network connecting the virtual machines (VMs) deployed in the same data center. The few available works either do not exhaustively describe the adopted methodology or employed different approaches causing the analyses to be hard to replicate, and the results to be hard to compare. In addition, cloud customers can today highly customize their cloud environments while previous works considered only a few of the scenarios in which a customer may operate. In this paper, we provide an intra-cloud network performance characterization of Microsoft (MS) Azure, a leading provider only preliminary investigated from this angle. We first propose and thoroughly detail a methodology to carry out similar analyses, thus encouraging its replication also in other contexts; then we apply this methodology to characterize the intra-cloud network performance in terms of maximum network throughput. More specifically, we investigate whether and how the achievable throughput between two VMs varies (i) over time; (ii) when the customer operates different decisions on VM size, network configuration, geographic region, and transport protocol; and (iii) when the customer operates the same decisions on these factors. Our analysis aims at addressing the gap existing in the literature by providing the most exhaustive and detailed results about the intra-cloud network performance for MS Azure today available.

Pythia: yet another active probing technique for alias resolution

An accurate and exhaustive knowledge of the Internet topology is essential for a deep understanding of such a complex and ever-evolving ecosystem. In this context, a well-known key challenge is represented by alias resolution, i.e. the process of grouping under a unique identifier the addresses owned by the same network layer device. While several techniques exist, each solution shows specific limitations such that the alias resolution problem appears far from being definitively solved. In this work, inspired by a previous technique and the lessons learned by experimenting with IP options, we present, evaluate and release Pythia, a novel active probing-based alias resolution technique. Pythia exploits a combination of (i) UDP packet probes and (ii) the IP Prespecified Timestamp option and it is purposely designed to reconstruct a specific category of routers. By using the reliable topological information provided by IGMP probing as a reference, we experimentally evaluate Pythia and compare it to previously proposed techniques according to multiple performance metrics. Experimental results show how Pythia reaches higher performance in terms of applicability and trustworthiness.

Dissecting Round Trip Time on the Slow Path with a Single Packet

Researchers and operators often measure Round Trip Time when monitoring, troubleshooting, or otherwise assessing network paths. However, because it combines all hops traversed along both the forward and reverse path, it can be difficult to interpret or to attribute delay to particular path segments. In this work, we present an approach using a single packet to dissect the RTT in chunks mapped to specific portions of the path. Using the IP Prespecified Timestamp option directed at intermediate routers, it provides RTT estimations along portions of the slow path. Using multiple vantage points (116 PlanetLab nodes), we show that the proposed approach can be applied on more than 77% of the considered paths. Finally, we present preliminary results for two use cases (home network contribution to the RTT and per-Autonomous System RTT contribution) to demonstrate its potential in practical scenarios.

DRAGO: Detecting, quantifying and locating hidden routers in Traceroute IP paths

Traceroute is probably the most famous networking tool widely adopted in both industry and research. Despite its long life, however, measurements based on Traceroute are potentially inaccurate, misleading or incomplete due to several unresolved issues. In this paper, we face the limitation represented by hidden routers - devices that do not decrement the TTL, being thus totally invisible to Traceroute. We present, evaluate and release DRAGO, a novel active probing technique composed of three main steps. First, a novel Traceroute enhanced by the IP Timestamp option is launched toward a destination. Second, a procedure is applied to quantify the hidden routers contained in the path, if any. Third, a last procedure is performed to identify the exact position in the path of the detected hidden routers. Experimental results demonstrate that the phenomenon is not uncommon: DRAGO detects the presence of hidden routers in at least 6% of the considered Traceroute IP paths and limits the affected area to one fifth of the trace containing these devices.

A hands-on look at active probing using the IP prespecified timestamp option

In the last years, network measurements have shown a growing interest in active probing techniques. Recent works propose approaches based on the IP prespecified timestamp option and consider its support to be enough for their purposes. On the other hand, other works found that IP options are usually filtered, poorly implemented, or not widely supported. In this paper, to shed light on this controversial topic, we investigate the responsiveness obtained targeting more than 1.7M IPs using several probes (ICMP, UDP, TCP, and SKIP ), with and without the IP prespecified timestamp option. Our results show that: (i) the option has a significant impact on the responsiveness to the probes; (ii) a not−negligible amount of targeted addresses return several categories of non RFC−compliant replies; (iii) by considering only the RFC−compliant replies which preserve the option, the probes ranking by responsiveness considerably changes. Finally, we discuss the large−scale applicability of two proposed techniques based on the IP prespecified timestamp option.

On the performance of the wide-area networks interconnecting public-cloud datacenters around the globe

According to current usage patterns, research trends, and latest reports, the performance of the wide-area networks interconnecting geographically distributed cloud nodes (i.e. inter-datacenter networks) is gaining more and more interest. In this paper we leverage only active approachesthus we do not rely on information restricted to providersand propose a deep analysis of these infrastructures for the two public-cloud leading providers: Amazon Web Services and Microsoft Azure. Our study provides an assessment of the performance of these networks as a function of the several configuration factors under the control of the customer and evidences specific cases of particular interest. The analysis of these cases and of their root causes, also related with service fees, provides insights on their impact on both the Quality of Service perceived by cloud customers and the outcomes of studies neglecting them.Our results show that Azure inter-datacenter infrastructure performs better than Amazons in terms of throughput (+56%, on average). On the other hand, the performance of the two providers is comparable in terms of latency, with the exception of limited specific cases. Moreover, some of the configuration factors cloud customers can leverage (such as larger more expensive VM sizes, advertised to have better network performance) may have no effect on the inter-datacenter network performance actually perceived. Counterintuitively, lower performance may even be related to higher costs for the customer. Experimental evidences show that public-cloud providers also rely on external network providers for some geographical regions, which is the cause of lower performance and higher costs. A comparison with previous works show that TCP throughput has not been improved recently, while evidences of higher link capacities have been found.