This week's Internet cable cuts in the Baltic sea have been widely reported, even as attempts to understand their cause and impact are ongoing. We turn to RIPE Atlas to provide a preliminary analysis of these events and examine to what extent the Internet in the region is resilient to them.
On Sunday 17 November, the BSC East-West Interlink Internet cable connection between Sweden and Lithuania stopped working. The following day, the C-Lion1 Internet cable connecting Finland with Germany was also cut. Investigation into what could have caused these two cables - which literally cross one another in their paths across the Baltic sea - to have been severed within such a short interval is still ongoing. But as we turn to RIPE Atlas to measure the impact these events had on the Internet, the question we really want to ask here is whether the Internet managed to route around the damage done.
Analysis
Our analysis of these events is, at this point, ongoing and the measurement results and graphs shared here are preliminary. That said, what we have observed so far does give us an initial grasp of the impact of the cable cuts.
Our analysis is built on RIPE Atlas measurement data for paths between the countries that used to be connected by the affected cables. More specifically, we use data collected from RIPE Atlas anchors, which provide a particularly stable view of the Internet. One of the measurements performed by these devices is the 'ping mesh', where each anchor performs ongoing measurements at four-minute intervals towards all other anchors. The resulting mesh give us insights into the state of paths between anchors in terms of latency and loss over time.
Before we dive into our analysis, it is worth emphasising that we don't have anchors everywhere. As a result, we don’t measure Internet paths between all IPv4 and IPv6 addresses in the country pairs we analyse, and we don’t know if/how the data from RIPE Atlas anchors can be extrapolated to the wider country. So strictly speaking, this is an analysis of the RIPE Atlas anchor mesh between the target countries.
For those who don't have time to read the full analysis, here's a quick summary of our initial findings:
| Event name | Countries | RIPE Atlas anchor mesh paths with significant latency changes | Significant packet loss detected in RIPE Atlas anchor mesh |
|---|---|---|---|
| BCS cut | Sweden - Lithuania | 20% | no |
| C-Lion1 cut | Finland - Germany | 30% | no |
BCS cut
According to reports, this Internet cable got cut in the early hours of 17 November. As a starting point for our analysis, we looked at measurements in the anchor mesh for paths between Sweden and Lithuania. In the mesh, we have 15 RIPE Atlas anchors in Sweden and 5 for Lithuania with latency data.
After initial data exploration, we see latency shifts a little before 08:00 UTC, which coincides with the some of the reported times for the incident. Taking that time as our point of focus, we look at the time interval from 12 hours before up until 12 hours after.
Figure 2 (one of a variety of similar graphs we generated) shows latencies between RIPE Atlas anchors in Lithuania for measurements towards a single target anchor in Stockholm, Sweden. For this (and other latency graphs) we subtract the minimum latency for that path during our observation period, to make the latency jumps comparable. Some paths here show a step up in latency around 08:00 UTC while others don't.
Figure 3 is just one example from a range of graphs in which we see don't see latency increases around the time of the incident. Again these are latencies between anchors in Lithuania and another RIPE Atlas anchor in Stockholm.
To see what percentage of paths were affected by latency increases, we compared latency in the hour before and the hour after the cut (see details in footnote 1).
Figure 4 shows the distribution of these latency effects. Without going into too much detail, here we see that 80% of the paths (0.8 on the y axis) have no significant latency difference, while the other 20% of paths have had an increased latency. The 10% of paths with the most latency difference see an increase of between 10 and 20 ms.
We can also summarise packet loss seen in the anchor mesh. Figure 5 shows a packet loss metric (see footnote 2) for all of the paths we measured in the ping mesh between Swedish and Lithuanian anchors over time. Overall, we see a baseline of 0% packet loss with occasional spikes. But the striking observation here is that there is no increase in packet loss coinciding with the time of the cable cut (shortly after 02:00 UTC).
C-Lion1 cut
This Internet cable got cut in the early hours of 18 November. Again, as a starting point for our analysis, we looked at measurements in the anchor mesh for paths between Germany and Finland. This time, in the mesh, we have 100 anchors in Germany and 12 anchors in Finland that provide us useful data for this analysis.
After initial data exploration, we see latency shifts a little after 02:00 UTC, again coinciding with some reports. Once again, taking that time as our point of focus, we look at the time interval from 12 hours before up until 12 hours after.
Figure 6 is one of a set of latency increase graphs we generated for the relevant interval. The graph shows latencies from all RIPE Atlas anchors in Finland towards an anchor in Germany. Again we see a mix of latency affected and non-affected paths.
Using the same approach as above for finding the percentage of latency affected paths (footnote 1), we get the CDF in figure 7:
In this case we see roughly 70% of paths don’t have any latency differences (the part of the graph that is vertical), meaning that roughly 30% do. 20% of paths see latency increases of 5ms or more. So overall these latency increases seem modest.
Finally, looking at packet loss for this cut, we get the following timeline as shown here in figure 8:
Here we see a baseline of between 0.5% and 1.0% packet loss during most of this time. It's quite striking, again, that the event time (02:00 UTC) is not particularly prominent in the graph. This is an indication that the event didn’t cause additional packet loss, at least not for this metric that we can extract.
Conclusion
This preliminary report contains our analysis of how the RIPE Atlas anchor mesh was affected by the two cable cuts that were reported to have taken place in the Baltic sea on 17 and 18 November 2024. As we have seen, the data indicates that a significant minority (20-30%) of paths measured had latency increases. But also of note, in the data we have, we didn't find indications of higher packet loss.
This result indicates the resiliency of the Internet in as far as we measure it with RIPE Atlas anchors. We cannot directly infer which of the paths between the anchors traversed the damaged cables. But we do see indirect evidence of the cuts: 20-30% of paths had an increase in latency after the reported cable cuts. This could point at alternative routes being taken. The longer the detour, the higher the latency.
This suggest that, in the Baltic region, the Internet managed to route around the damage that occurred - for each of the physical links cut, we see relatively minor latency consequences and no visible packet loss. This hints at enough backup capacity to handle this event. If this wasn't the case, we would expect our data to have looked quite different: the packet loss should have gone up; and/or the shape of the latency increases would have been gradual, as opposed to the stepwise changes we saw for the latency-affected paths.
If we take a look at cable maps (ITU, submarine cable map from TeleGeography) there is plenty of redundancy at the physical level around the Baltic Sea, but I’m unaware of comprehensive public data sources that reveal what parts of these cables are used, by whom, and under what conditions. Is it naive to assume redundancy at the physical level will automatically result in redundancy in end-to-end connectivity? I don’t know.
The scarier part is that, while we don’t see capacity issues, we are blind on what would happen if another link would be severed, or worse, if many are severed. On the measurement side, we can only see, after the fact, if the Internet was resilient enough. In this case we see good resilience (no discernible loss, some increased latencies), but we don’t know what the future holds if other events like this happen.
Footnotes
- We took the minimum latency we saw in a sample before the cut and compared it to the minimum latency seen within an hour after the cut. For the first event we took 06:45 to 07:45 and 08:15 to 09:15 as our time intervals for this. For the second event we took 00:45 to 01:45 and 2:15 to 2:45. We now get a latency increase for every RIPE Atlas anchor pair, and we can use this to get an idea of how many of the measured paths were affected, and the size of the latency effects.
- After removing path that have 100% loss during our observation interval we look at each ping result and define a loss-event as any of the 3 packets being lost. If all 3 packets are replied to it is defined as a no-loss-event. The graphs show the fraction of loss-events relative to all events.