Can we have an 'Uzbekistan' group inside 'Internet Censorship around the World'? category?

I rechecked my packet captures. I set aside my notices about blocking inside Teredo tunnels (I’m not sure I interpreted these network flows right) and updated the information. Below is my draft, beware of my English!
Ugly shaping, false FINs, and annoying RSTs. Notes on World Wide Web filtering in Uzbekistan
My observations on how local authorities censor the World Wide Web are very limited. From time to time I have to start a network sniffer to investigate some seemingly absurd network problems. Later these appear to be our new Internet restrictions according to an ‘Uzbekistan’ page of the annual ‘Freedom on the Net’ report by Freedom House. I can summarize what I stumble upon as follows.
1. Shaping the traffic for Internet censorship First noted around 2018 as a Facebook problem, traffic shaping is trending as a filtering technology here. Some connections, which where interrupted or routed to nowhere previously, are now rate limited to turn useless.
Bandwidth limiting is aggressive. It starts from the very first packets. Curl’ing a blocked resource with an -m option often ends just immediately, as no TCP connection could be established at all. Segments are being lost in both directions. A TCP flow diagram, if any, looks really horrible. Twitter, Viber, Skype, and mobile devices’ power supply units are among the affected.
2. Blocking TLS connections by injection of TCP segments with the FIN flag set in reply to the ‘Client Hello’ messages It’s still a popular filtering technique, entirely SNI-based. TLS 1.0, 1.2 SNI-less connections to banned resources are not interrupted and do work as needed.
FIN segments inserted have right syn and ask values, but are still distinguishable by their weird timing (they come too fast to originate from a server abroad), ‘random’ IP IDs, and non-empty data (proudly reporting some ‘Middlebox v 1.0’ usage as a plain text string).
Dropping these SYNs with nftables causes them to be reinserted several times with one second delay, followed by the final RST segment. The later comes with right syn and ask values and no data, albeit again it has a ‘random’ IP ID and follows the same single second temporal pattern.
No data from the remote server appear in between these injected segments. That points to the next level of filtering equipment installed in-path.
Some times ago I also noticed forceful setting of FIN flags in what looked like genuine remote server replies to the ‘Client Hello’ messages. No in-path blocking equipment was seen in such cases. I don’t know, whether such blocking method is being employed now.
3. RSTing TCP connections It’s used, probably, for non-TLS TCP connections our state censors want to interrupt. Injected segments again have proper syn and ask values and no data. They come too fast to originate from a remote server and possess ‘random’ IP IDs.
As of what is being blocked in Uzbekistan one could look at country’s OONI (OONI forever!) profile. To put the things into context I’d recommend the already mentioned collection of ‘Freedom on the Net’ reports on Uzbekistan (by The Freedom House).