Does the Internet Route Around Damage? - Baltic Sea Cable Cuts

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 as we write this. 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:

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 an example of latencies between RIPE Atlas anchors in Lithuania towards a single target anchor in Stockholm, Sweden. For this (and other latency graphs) we subtract the minimum latency for a 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 an example from our graphs in which we see don't see latency increases around the time of the incident. In this case these are latencies between anchors in Lithuania and a RIPE Atlas anchor in Stockholm in a network different from one used for figure 2.

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.

In addition to looking at latency effects, we can use the RIPE Atlas anchor mesh to look at packet loss. 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 distribution 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. Overall these latency increases seem modest.

Finally, looking at possible packet loss effects due to this cable cut, we followed the methodology in footnote 2 to create 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. The most prominent feature of this graph is the increased packet loss in the last 2 hours of this graph. It is unclear what caused this jump, but the fact that it is not correlated in time with the reported cable cut makes it unlikely that this is an immediate effect of the cut.

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 suggests 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

1. For each path (i.e., anchor mesh pair) 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 (pre-event) and 08:15 to 09:15 (post-event) as our time intervals for this, ie we take 15 minutes before and after 08:00 as a buffer around the event. For the second event we took 00:45 to 01:45 (pre-event) and 2:15 to 2:45 (post-event). We then subtract pre-event minimum latency from post-event minimum latency to get a latency differential 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.
2. After removing path that have 100% loss during our observation interval we look at each RIPE Atlas 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.