Telegram Latency in Belarus

November 5, 2020

In the end of October 2020, Qurium received reports from users in Belarus that Telegram service was not working properly. Although the service was reachable, an increased latency was noted among the users. In order to confirm if it was introduced by operators, Qurium has been monitoring the behavior of the Telegram service from different Belarus providers. An increased latency to Telegram network from the Belarus provider Beltelecom has been detected.

Abnormal latency behavior

In order to better understand the problem, Qurium started to monitor the prefix and discovered abnormal network latency behaviors.

descr: Telegram Messenger Amsterdam Network
origin: AS62041
created: 2014-05-14T18:59:01Z
last-modified: 2014-05-14T18:59:01Z
source: RIPE

Inconsistent round trip times

During protests in Belarus in August/September 2020, Qurium detected that some IP addresses inside of Telegram network had a latency of 300-450ms while other IP addresses had 50 ms latency.

Effect of traffic shaping during a day of protests in Belarus

When looking into the raw (high definition) values of Sunday November 1st 2020 between 23:30 and 23:59 PM we can see a sudden change of latency at 23:34 PM.

Change of latency to Telegram network in Amsterdam due to traffic shaping

The increase of latency seems to respond to some kind of traffic shaping strategy. These network traffic control strategies limit the output rate of certain types of traffic, in this case Telegram traffic.

Classification and rating

Once the traffic is classified as “Telegram traffic”, the operator assigns the traffic to a specific network queue. This queue is limited/shaped by a maximum output rate (R). The buffer (B) of this queue determines how much latency will be introduced before the traffic is dropped.

A good metaphor to understand how traffic shaping works is to think in “leaky bucket“. You can keep adding water until the bucket overflows and the water flows at a constant rate through the holes.

When there is little traffic activity, there is no delay (latency) introduced as traffic (water) flows without delay out of the bucket. As water is added, the new water is delayed in its way out, if too much water is added the bucket overflows and the water/traffic is dropped.

The Leaky Bucket Buffer Model (Microsoft Media Foundation) - Win32 apps |  Microsoft Docs
Differentiate between leaky bucket and token bucket methods of traffic  shaping - The Technical Talk

When looking into the delays present in each of the IPs of network of Telegram in Amsterdam, we could see that only certain IP addresses were delayed. This fact suggests that there is a mechanism capable of identifying (fingerprinting) Telegram App traffic that is later on associated to a certain traffic shaping policy.

Alternatively, the traffic policy is individually applied to each of the IPs in the Telegram network so addresses with less traffic experience less latency. In another words, the traffic policy has a “leaky bucket” per individual IP address instead of a bucket for the whole /22 network.

Confirming traffic shaping in the upstream provider

In order to confirm where the traffic shaping is taking place, we measure the latency from different providers using RIPE Atlas probes. The measurements show the latency from AS6697 (Beltelecom) during Sunday protests (Nov 1, 2020).

The latency is not present from other providers in the country that show a 59-62ms consistent latency.

Traffic towards Telegram from Belpak (AS6697) is delivered via the routers asbr2 and where DataIX transit peers with Belarus.

12ms to (DE) via asbr9

44ms to (NL) via asbr9

An analysis of latency during four days reveals the periodical congestion issues during peak Telegram usage during lunch time and in the evenings.