eebssk1
commented
2 months ago Since the internet is intended to be a low-loss system, before adding something like FEC, we should investigate what is causing these packet losses, and how to flexibly handle that.
This feature might be interested to mobile users, ISPs that do random drop for udp packets/lossy backbone interconnect.
Currently the two widely used tunnel are both based on packet redundancy and busrting. How KCP works is clearly described in its readme. While Hysteria is just bursting more packet on loss(up to bandwidth limit) to battle against ISPs, which does not suit for n2n obviously. See (Chinese) https://v2.hysteria.network/zh/docs/misc/Hysteria-Brutal/ or https://github.com/apernet/tcp-brutal.
FEC (Forward Error Correction) is a way to increase reliability when some data is lost.
If n3n users are experiencing packet loss, the addition of FEC could assist with that. However, FEC is not a simple cure-all - it has a cost of increased complexity and increased packet sizes (or increased number of packets - or probably both) and increased memory use (for caching the all the packets in a bundle before reassembly) and increased latency (often, a FEC algo cannot return the original packets until all the packets in the bundle have arrived). All this has meant that in most expected internet protocol situations, a simple packet retransmit is more reliable than the total overhead of adding FEC.
Since the internet is intended to be a low-loss system, before adding something like FEC, we should investigate what is causing these packet losses, and how to flexibly handle that.
For instance, the FEC convolution algorithm used is tuned to the expected percentage data loss - so either a flexible suite of algos is needed, or an acceptable failure rate determined.