Congested Peering and Transit

While I was investigating potential congestion issues in the roaming backhaul link of mobile networks I noticed again once more that this is by far not the only place where network operators are not providing enough capacity during busy hours in the evening. Another unfortunate example are fixed line access networks. Here are two examples over which I trip frequently.

I have a couple of servers running in Paris connected to SFR’s consumer fiber access network. During the daytime I have no problem accessing these servers at the subscribed fiber speed of 250 Mbit/s in the downlink and 50 Mbit/s in the uplink direction. In the evening hours, there is heavy congestion however and between 8 pm and midnight it is not uncommon to get a high packet loss rate and data rates in the (very) few megabits/s. For this case I got a fix because the congestion appears on the transit or peering link of Telecom Italia that is used between my access network provider in Germany and SFR in Paris. No so sparkling… When I reroute my traffic via a server at a cloud provider that uses a different peering/transit link, I am back to full speed.

The other example I frequently encounter is accessing a server that is in the network of French fixed and mobile access provider Bouygues Telecom. Again, things are fine during the day, but in the evening, speed drops to single mbit/s levels in both directions. This makes me wonder a bit if both cases are just a matter of negligence or if there is actually a strategy behind it to force big content providers to double pay by making the default transit/peering congested during prime time so they are forced to pay for direct interconnect?

One thought on “Congested Peering and Transit”

  1. How much packet loss do you have? Depending on RTT TCP throughput may decrease siginificantly already at packet loss ratio 2%. Switching TCP Congestion Control, e.g. to BBR or westwood may also add more resilience.

Comments are closed.