Currently KCPTUN uses a fixed recv/send window for UDP which is fine for ensuring maximum traffic but actually results in a Denial-Of-Service attack on the ISP side for UDP traffic if the discrepancy between the Server's and Client's connection is great, in this case server handles 500mbit/s + very easily but the client is barely capable of 49Mbit/s which means that the additional packets are basically just a UDP denial of service flood.
Statistics using nload:
Instead of using a fixed size if KCPTun could start with a default size and then negotiate a larger or lower size (on an interval) as is needed based off of incoming traffic statistics, less packets would be wasted.
I'm thinking this is a priority because my VPS provider actually suspended my service due to this unintended effect of KCPTun.
Currently KCPTUN uses a fixed recv/send window for UDP which is fine for ensuring maximum traffic but actually results in a Denial-Of-Service attack on the ISP side for UDP traffic if the discrepancy between the Server's and Client's connection is great, in this case server handles 500mbit/s + very easily but the client is barely capable of 49Mbit/s which means that the additional packets are basically just a UDP denial of service flood.
Statistics using nload:
Instead of using a fixed size if KCPTun could start with a default size and then negotiate a larger or lower size (on an interval) as is needed based off of incoming traffic statistics, less packets would be wasted.
I'm thinking this is a priority because my VPS provider actually suspended my service due to this unintended effect of KCPTun.
Thanks for consideration.