Hello,
I found UDPspeeder on https://github.com/wangyu-/UDPspeeder: “A Tunnel which Improves your Network Quality on a High-latency Lossy Link by using Forward Error Correction.”
I would like to suggest a similar feature for EoIP tunnels. What about an addon which you can simply activate/deactivate Forward Error Correction for a connection? Is there anything on the roadmap?
What do you think?
Regards
+1
With abandoned Metarouter this seems to be a nice feature request.
Try filling feature request: https://mikrotik.com/support
FEC is common on networks such as satellite comm’s.
That said, it will be CPU intensive, especially over EoIP.
Noting that TCP knows when frames have not been received and windowing of the frame. I would image that using a smaller TCP window size is the better option.
As for UDP( Voip / Gaming packet ), by the time FEC gets around to it, its probably not worth the processing time!
Shameless push 
+1 … While not in context of EoIP, some FEC-enabled tunnels have been discussed here before:
FEATURE REQUEST: FEC tunnel type
http://forum.mikrotik.com/t/feature-request-fec-tunnel-type/167119/1
Request: FEC tunnel types
http://forum.mikrotik.com/t/request-fec-tunnel-types/122710/1
Generally FEC would report corrected errors, so you’d be able to see if it’s providing a value (e.g. actually correcting anything vs added latency/CPU load).
Idea with FEC might correct something to prevent the TCP re-transmission dance. On a low latency fiber line, this would NOT help that much. But at moderate or high latency (& where latency is NOT due congestion)… any saving of TCP roundtrips dramatically lowers average latency, as the error-free latency on link goes up.
Agree, gaming may not be a good use case. And for PBX-style VoIP/video trunks, you can sometimes enable FEC on the RTP, which seems like a better place to enable FEC than a Mikrotik. But that is if the IP PBX support it…
It the UDP-based VPNs where overlying FEC may still be a good idea. Since more sophisticated UDP protocols still need roundtrips correct errors errors. And UDP protocols that’s have no reliability, like SNMP… might also benefit to increase chance of a packet arrives intact and prevent gaps in SNMP data.
Not saying FEC is a panacea to lossy lines, but at minimum it give some data (e.g. are there FEC-correctable errors on a line?).
sounds like a useful feature
I’d envision it working like /ip/packing where you define the interface to apply FEC to & other end also have to define it. But essentially operate like UDPspeeder and the like.
I don’t think it be that hard, but yeah increased CPU. But there is research out there backing FEC helping in other case between fiber and GEO sats. More importantly, competitors allow FEC. Pepwave has made a whole business around putting a “multi-WAN friendly” UI over OpenVPN with FEC tunnels, at 3x (or more) cost of Mikrotik
Shameless push again 