"WiFi X"

[AVGresponding]

How would you adjust TCP to tolerate a higher packet loss?

Hit it with a hammer?

[madires]

Previous ISPs I have worked at also rate limited at the LNS/BRAS.

If a customer is the receiver of some "unwanted attention", then without rate limiting at the BRAS/LNS, you'll end up forwarding potentially many gigabits/sec into your access network. If you also rate limit the customer session to the same as their downstream rate, then the BRAS/LNS just drops excess traffic.

Doesnt really help the rest of your network, and is definitely more resource hungry, but saves your access network and the rest of the customers on it until you can blackhole the destination.

I don't see a real benefit. It might help to mitigate the impact of a tiny DoS, but with today's DDoS attacks there's so much traffic the access router's backhaul links will be totally congested and therefore impact all subscribers of that router anyway. However, DDoS attacks are handled at the edge of your network nowadays, and they can be huge. The largest ones are more than 1 Tbps.

[OwO]

How would you adjust TCP to tolerate a higher packet loss?

By not using TCP in the first place
The network connection from China to the rest of the world is horrific, packet loss averages 20% during the day and 50% in the evening (but much lower from 2am to 8am). TCP gives you about 20KB/s if you're lucky and completely unusable when you get into 50% packet loss. However, if you open many TCP connections you can get a few MB/s through, which just means file downloads (using a multithreaded downloader) get more bandwidth compared to interactive users.

I've designed a custom stream transport protocol for point to point tunneling over high packet loss networks: https://gitlab.com/bepissneks/udptun/-/blob/master/udp_stream_transport.hpp

It implements multiple streams in one connection, much like SCTP. There is no "sliding window" anymore, data chunks simply sit in a priority queue waiting to be sent, and a thread transmits packets from the queue at a constant rate (currently set at 100pkt/s or 150KB/s). Data chunks are individually ack'd so that only what is lost needs to be retransmitted (optimized for high packet loss conditions). A chunk that isn't ack'd after a timeout (determined by RTT) goes back onto the queue. A packet can contain many data chunks and many acks, so we don't have to send a new packet for every ack.

The use case is you open one udptun connection to the server, listen for local tcp connections, and forward all tcp streams onto the udptun connection. The server side will then create tcp connections to the actual destination as new streams are created, and forward udptun streams to tcp streams. The proxy client/server here implements that: https://gitlab.com/bepissneks/udptun/-/blob/master/examples/proxy_client.cpp

The send rate I'm using is 150KB/s, so it should not hog too much bandwidth, but in theory someone can turn it way up and get a big slice of the bandwidth pie, so I'm not going to document this software or release it in easily accessible form, (and you need to make deep code changes to change the send rate). That speed is good enough for web browsing and very low-fi youtube, but is still small compared to what a typical multithreaded downloader will use up.

[Haenk]

and a public print out from Estonia's company house leads to http://novads.co => https://igadget24.com with similar "superb" gadgets 

They really know what they are doing. If you are beginning to suffer from all that Wifi X radiation and too fast data streams from the interwebs, they also offer

https://igadget24.com/intl_4/order.php?prod=radiationstopperpro - too bad, 5G isn't mentioned (Or is it? I did only look at the Pictures and didn't bother to read the text…)
Honestly, if thsi does not support 5G blocking, this product is way outdated and should be offered at an massive discount. Greedy bastards.

[madires]

The network connection from China to the rest of the world is horrific, packet loss averages 20% during the day and 50% in the evening (but much lower from 2am to 8am). TCP gives you about 20KB/s if you're lucky and completely unusable when you get into 50% packet loss. However, if you open many TCP connections you can get a few MB/s through, which just means file downloads (using a multithreaded downloader) get more bandwidth compared to interactive users.

I see, you are trying to work around the special situation in your country. AFAIK, the problem with high packet losses in China is caused by congestion (let's make more profit by spending less on the network) and also by the tons of middleboxes mangling IP traffic. It's half a wonder it's still working somehow.

This might interest you:
NANOG 79 - Characterizing Transnational Internet Performance and the Great Bottleneck of China
https://storage.googleapis.com/site-media-prod/meetings/NANOG79/2192/20200601_Zhu_Characterizing_Transnational_Internet_v1.pdf

[MrMobodies]

And looking at their picture showing a speedtest and I knew it was going to be a generic stock photo taken from somewhere.



Taken from here:
http://m.baoventd.org/soc-voi-nhung-quoc-gia-co-mang-di-dong-nhanh-hon-ca-wi-fi-80824.html

https://translate.google.co.uk/translate?hl=en&sl=vi&u=http://m.baoventd.org/soc-voi-nhung-quoc-gia-co-mang-di-dong-nhanh-hon-ca-wi-fi-80824.html&prev=search

Reviews have got to be fake.

Look at this review:

Nick Best device I’ve ever bought. Great value and my internet speed has doubled. Also, shipping was superfast! Thank you WIFI UltraBoost team!

Picture taken from a listing on Olx:
https://www.olx.ua/obyavlenie/wi-fi-usilitel-signala-retranslyator-ripiter-IDHZRNh.html?sd=1#dcc8721e5c;promoted