|
Co-authored by CAIDA’s Roderick Fanou, Postdoctoral Scholar, Ricky Mok, Assistant Research Scientist, Bradley Huffaker, Technical Manager, and kc claffy, Founder and Director.
The network layer of the Internet routes packets regardless of the underlying communication media (Wifi, cellular telephony, satellites, or optical fiber). The underlying physical infrastructure of the Internet includes a mesh of submarine cables, generally shared by network operators who purchase capacity from the cable owners2, 11. As of late 2020, over 400 submarine cables interconnect continents worldwide and constitute the oceanic backbone of the Internet. Although they carry more than 99% of international traffic, little academic research has occurred to isolate end-to-end performance changes induced by their launch.
In mid-September 2018, Angola Cables (AC, AS37468) activated the SACS cable, the first trans-Atlantic cable traversing the Southern hemisphere[A1]1. SACS connects Angola in Africa to Brazil in South America. Most assume that the deployment of undersea cables between continents improves Internet performance between the two continents. In our paper, “Unintended consequences: Effects of submarine cable deployment on Internet routing”, we shed empirical light on this hypothesis, by investigating the operational impact of SACS on Internet routing. We presented our results at the Passive and Active Measurement Conference (PAM) 2020, where the work received the best paper award.11, 7, 8 We summarize the contributions of our study, including our methodology, data collection and key findings.
[A1] Note that in the same year, Camtel (CM, AS15964), the incumbent operator of Cameroon, and China Unicom (CH, AS9800) deployed the 5,900km South Atlantic Inter Link (SAIL), which links Fortaleza to Kribi (Cameroon)17, but this cable was not yet lit as of March 2020.
Our methodology quantifies the end-to-end communication performance induced by a new submarine cable deployment on Internet paths. Our approach relies on existing subsea maps/databases17 and public measurement infrastructures.3, 13 Our method has four steps:
Consider a newly deployed subsea cable C of length l. To accurately identify IPs on both sides of C, we need samples of IP paths crossing the cable in both directions. Our first step involves executing (post-cable launch) traceroutes between monitors located within two networks, denoted AS1 and AS2, that are topologically close to the respective sides of C. The output of these measurements is a set of candidate IP paths containing IP addresses of routers traversed by packets from AS1 to AS2 or vice-versa via C as well as the round-trip times (RTTs) from the respective source IP addresses to each of them. We selected the networks hosting vantage points—VPs—(i.e. AS1, AS2) as well as the functional VPs within those networks using existing measurement platforms3, 13 and publicly available sea cable databases/maps.17
Our second step involves determining the IP interfaces on respective sides of C within the collected candidate IP paths. Using the speed of light constraint and the known length of C, we deduced the minimum RTT to cross the considered cable by computing RTTmin using equation (a): RTTmin=(2×l)/((2?3)×c) where c is the speed of light in a vacuum [W1]. Further, we singled out from the candidate IP paths any pair of IP addresses IPA-IPB for which the difference between the respective round trips to the source IP address of the considered traceroute is greater or equal than the threshold RTTmin. We looked for cases where the countries of those IP interfaces, according to geolocation databases12 (such as Netacuity10 and Maxmind9, match the countries linked by the new subsea cable. Then, we inferred IPA and IPB from the potential IPs on each side of C. We looked for the router aliases of those IPs.
Third, we fetched from existing measurement platforms RIPE Atlas [R1] and CAIDA Ark [C1], historical traceroutes containing any pairs IPA-IPB or IPB-IPA, which we grouped into a set T’<s,d>. We then identified the source IP and the destination network (<s,d>) for which we collected available historical traceroutes T<s,d>. We annotated these IP paths with hostnames, Autonomous Systems (ASes), country, and RTT difference between consecutive hops.
Finally, we used three metrics to evaluate end-to-end performance and AS paths pre and post-cable launch:
We used CAIDA’s Ark (100+ monitors)3 and RIPE Atlas (11,000+ monitors)13 measurement platforms as the sources of historical traceroutes. We extracted router aliases information from CAIDA’s Macroscopic Internet Topology Dataset Kit (ITDK), IXP information from CAIDA’s Internet eXchange Point Dataset3, and translated IPs to hostnames with qr and zdns. We used IP geolocation databases Netacuity10 and Maxmind9 combined with hostname geolocation to map IPs to countries.
We started our analysis by comparing RTTs before and after SACS deployment. For the same source VP and destination prefix, we built the set of common IP hops in the traces before and after SACS, and selected the IP closest to the destination IPc as a point of comparison. Using the RTTs from VPs toward IP hop IPc from the traces pre- and post-SACS, we plotted the boxplots of Figure 3, clustering RTTs by continent and measurement platform.
Overall, our results show that SACS had little impact on latencies from all vantage points (VPs) to all destination prefixes. Interestingly, paths from South America experienced a median decrease of 38%, which was quite significant compared to paths from Oceania—Australia (8% decrease), and to paths from Africa (3%). At the country-level, we found predictable performance improvements (RTT decrease) for paths going from Africa to Brazil, or from South America to Angola. However, we found an asymmetrical RTT reduction: the decrease of the median RTT from Africa to Brazil (73ms) was a third of that from South America to Angola (226ms). We also noted some unpredicted and unreported performance degradations e.g., we saw packets suboptimally routed through SACS for paths going from North America to Brazil or Africa/Europe to Angola, leading to latency increases.
We computed per AS the percentage of observed <s,d> pairs for which the AS path with the minimum observed RTT contained the considered AS.
BEFORE | AFTER | |
---|---|---|
AS-centrality (AS37468) | 46% | 100% |
Median RTT of IP paths via AS37468 | 346ms | 159ms |
Min RTT of IP paths via AS37468 | 353ms | 108ms |
Figure 4 depicts the impact of SACS deployment on transit ASes serving observed paths from South America to Angola (RTT improvement). The ovals inside Angola Cables are part of traceroutes post-SACS that we manually geolocated using hints in hostnames. Before SACS, 46% of observed <s,d> pairs crossed Europe and then Angola via AC’s network. SACS provided a more direct path between these two continents and improved performance. As a consequence, the median RTT between VPs and IPs on IP paths via AS37468 decreased from 346ms to 159ms.
BEFORE | AFTER | |
---|---|---|
AS-centrality (AS37468) | 74% | 100% |
Median RTT of IP paths via AS37468 | 156ms | 259ms |
Min RTT of IP paths via AS37468 | 128ms | 180ms |
We then considered partial paths between Europe and Angola, cases in which we observed an RTT degradation from the collected traceroutes. Note that AC was the major transit provider for traffic from Europe to Angola throughout the entire period of the study. However, the use of SACS within AC significantly lengthened the physical path and thus the latency on the forward path. As a consequence, the median RTT on IP paths crossing AS37468 increased from 156ms to 259ms.
We provide more detail on our in-depth inspection of the paths pre and post-SACS in the paper.7
The key contributions of this study can be listed as follows:
Sponsored byRadix
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byCSC