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 22.214.171.124/22 and discovered abnormal network latency behaviors.
descr: Telegram Messenger Amsterdam Network
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.
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.
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.
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 asbr9.net.belpak.by where DataIX transit peers with Belarus.
12ms to 126.96.36.199.ix.dataix.ru (DE) via asbr9
44ms to 188.8.131.52.ix.dataix.ru (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.