Category Archives: Community feedback

[Community Feedback] Thoughts and Recommendations from the ACM SIGCOMM 2017 Reproducibility Workshop

This paper has been submitted to CCR. This is a draft version of the paper that has not been peer-reviewed. Comments on the paper are encouraged through the comment facility at the bottom of this page before December 15th, 2017.
Damien Saucez, Luigi Iannone

Abstract

Ensuring the reproducibility of results is an essential part of experimental sciences, including computer networking. Unfortunately, as highlighted recently, a large portion of research results are hardly, if not at all, reproducible, raising reasonable lack of conviction on the research carried out around the world.

Recent years have shown an increasing awareness about reproducibility of results as an essential part of research car- ried out by members of the ACM SIGCOMM community. To address this important issue, ACM has introduced a new policy on result and artifact review and badging. The policy defines the terminology to be used to assess results and artifacts but does not specify the review process or how to make research reproducible.

During SIGCOMM’17 a side workshop has been organized with the specific purpose to tackle the issue. The objective being to trigger discussion and activity in order to craft recommendations on how to introduce incentives for authors to share their artifacts, and the details on how to use them, as well as defining the process to be used.

This editorial overviews the workshop activity and summarizes the main discussions and outcomes.

Draft article

[Community Feedback] A Scalable VPN Gateway for Multi-Tenant Cloud Services

This paper has been submitted to CCR. This is a draft version of the paper that has not been peer-reviewed. Comments on the paper or the supplementary material are encouraged through the comment facility at the bottom of this page.
M. Arashloo, P. Shirshov, R. Gandhi, G. Lu, L. Yuan, J. Rexford
Abstract

Major cloud providers offer networks of virtual machines with private IP addresses as a service on the cloud. To isolate the address space of different customers, customers are required to tunnel their traffic to a Virtual Private Network (VPN) gateway, which is typically a middlebox inside the cloud that internally tunnels each packet to the correct destination. To improve performance, an increasing number of enterprises connect directly to the cloud provider’s network at the edge, to a device that we call the provider’s edge (PE). PE is a chokepoint for customer’s traffic to the cloud, and therefore a natural candidate for implementing network functions concerning customers’ virtual networks, including the VPN gateway, to avoid a detour to middleboxes inside the cloud.

At the scale of today’s cloud providers, VPN gateways need to maintain information for around a million internal tunnels. We argue that no single commodity device can handle these many tunnels while providing a high enough port density to connect to hundreds of cloud customers at the edge. Thus, in this paper, we propose a hybrid architecture for the PE, consisting of a commodity switch, connected to a commodity server which uses Data-Plane Development Kit (DPDK) for fast packet processing. This architecture enables a variety of network functions at the edge by offering the benefits of both hardware and software data planes. We implement a scalable VPN gateway on our proposed PE and show that it matches the scale requirements of today’s cloud providers while processing packets close to line rate.

Draft article

 

[Community Feedback] A Longitudinal Study of Utilization at Internet Interconnection Points

This paper has been submitted to CCR. This is a draft version of the paper that has not been peer-reviewed. Comments on the paper or the supplementary material are encouraged through the comment facility at the bottom of this page.
N. Feamster
Abstract

The increase in high-volume traffic flows due to applications such as video streaming draw new attention on utilization at the interconnections between the Internet’s independently operated networks. This paper surveys the findings from nearly two years of Internet utilization data provided by seven participating ISPs—Bright House Networks, Comcast, Cox, Mediacom, Midco, Suddenlink, and Time Warner Cable—whose access networks represent about 50% of all U.S. broadband subscribers. The dataset spans 18 months and includes about 97% of the paid peering, settlement-free peering, and ISP- paid transit links of each of the participating ISPs. Analysis of the data—which comprises more than 1,000 link groups, representing the diverse and substitutable available routes— suggests that many interconnects have significant spare capacity, that this spare capacity exists both across ISPs in each region and in aggregate for any individual ISP, and that the aggregate utilization across interconnects is roughly 50% during peak periods.

Draft article

Supplementary material

[Community Feedback] Towards a Rigorous Methodology for Measuring Adoption of RPKI Route Validation and Filtering

This paper has been submitted to CCR. This is a draft version of the paper that has not been peer-reviewed. Comments on the paper or the supplementary material are encouraged through the comment facility at the bottom of this page.
A. Reuter, R. Bush, I. Cunha, E. Katz-Bassett, T. Schmidt, M. Wählisch
Abstract

A proposal to improve routing security – Route Origin Authorization (ROA) – has been standardized. A ROA specifies which network is allowed to announce a set of Internet destinations. While some networks now specify ROAs, little is known about whether other networks check routes they receive against these ROAs, a process known as Route Origin Validation (ROV). Which networks blindly accept invalid routes? Which reject them outright? Which de-preference them if alternatives exist? Recent analysis attempts to use uncontrolled experiments to characterize ROV adoption by comparing valid routes and invalid routes. However, we argue that gaining a solid understanding of ROV adoption is impossible using currently available data sets and techniques. Our measurements suggest that, although some ISPs are not observed using invalid routes in uncontrolled experiments, they are actually using different routes for (non-security) traffic engineering purposes, without performing ROV. We conclude with a description of a controlled, verifiable methodology for measuring ROV and present three ASes that do implement ROV, confirmed by operators.

Draft article

 

[Community Feedback] A Hypergiant’s View of the Internet

This paper has been submitted to CCR. This is a draft version of the paper that has not been peer-reviewed. Comments on the paper or the supplementary material are encouraged through the comment facility at the bottom of this page.
T. Better, F. Cuadrado, G. Tyson, I. Castro, S. Uhlig
Abstract

The importance of IXPs to interconnect different networks and exchange traffic locally has been well studied over the last few years. However, far less is known about the role IXPs play as a platform to enable large-scale content delivery and to reach a world-wide customer base. In this paper, we study the infrastructure deployment of a content hypergiant, Netflix, and show that the combined worldwide IXP substrate is the major corner stone of its Content Delivery Network. This highlights the additional role that IXPs play in the Internet ecosystem, not just in terms of interconnection, but also allowing players such as Netflix to deliver significant amounts of traffic.

Draft article

 

[Community Feedback] A longitudinal study of IP Anycast

This paper has been submitted to CCR. This is a draft version of the paper that has not been peer-reviewed. Comments on the paper or the supplementary material are encouraged through the comment facility at the bottom of this page.
D. Cicalese, D. Rossi
Abstract

IP anycast is a commonly used technique to share the load of a variety of global services. For more than one year, leveraging a lightweight technique for IP anycast detection, enumeration and geolocation, we perform regular IP monthly censuses. While this paper provides a brief longitudinal study of the anycast ecosystem, we make all our datasets (raw measurement from PlanetLab and RIPE Atlas), results (monthly geolocated anycast replicas for all IP/24) and code available to the community.

Draft article

[Community Feedback] Looking for Hypergiants in PeeringDB

This paper has been submitted to CCR. This is a draft version of the paper that has not been peer-reviewed. Comments on the paper or the supplementary material are encouraged through the comment facility at the bottom of this page.
T. Bottger, F. Cuadrado, S. Uhlig
Abstract

Hypergiants, such as Google or Netflix, are important organ- isations in the Internet ecosystem, due to their sheer impact in terms of traffic volume exchanged. However, the research community still lacks a sufficiently crisp definition for them, beyond naming specific instances of them. In this paper we analyse PeeringDB data and derive a set of defining char- acteristics for hypergiants. To this end, we first character- ise the organisations present in PeeringDB, allowing us to identify discriminating properties of the these organisations. We then show that these properties differentiate hypergiants well from other organisations. We conclude this paper by investigating how hypergiants exploit the IXP ecosystem to reach the global IPv4 space.

Draft article

Supplementary material