OpenVPN Support Forum

I've done a search of the forums and can't find if an openvpn implementation is in the works that is good over lossy links.

Generally, in lossy networks over TCP, packet loss and corruption are mistakenly taken as an indication of congestion and TCP slows its rate to accommodate the non-existent congestion. While over UDP, sheer packet loss and errors are the issue.

A good example for application is when one is connecting to the VPN via a lossy wifi network. Perhaps it is lossy because of weather, distance, or other poor signal cause. Forward error correction would use redundancy to correct the losses. In OpenVPN, this would be done over UDP to avoid the TCP collapse scenario altogether. A solution would allow use of a VPN in conditions where OpenVPN would typically fail to sustain a connection either via TCP because of faux-congestion related collapse or failure by UDP because of raw packet loss and corruption.

I'm interested in getting involved in any push to implement something like FEC (forward error correction) into OpenVPN, possibly leveraging other open code like this: http://feclib.sourceforge.net/

So what is going on in this area?

Thanks,
Marty

Hey..
I'm interested in working on this project. Are you still interested?

Typical FEC implementations are not really helpful here, as packets do not get typically get corrupted in ways that FEC could help with, read "some bits get changed, but the packet still arrives, and FEC can be used to recover the original packet" - but if bits change, the underlying protocol (like "Ethernet") detect a broken checksum and drop the whole packet.

So what you could do is send the packet multiple times, in the hope that at least one of them gets through - but that would kill your bandwidth, and on a wireless link, might kill the rest of the usefulness for good...

Other products do something like that if you have multiple available paths, that is, if you have 5 paths, packets are sent in 4 fragments + 1 parity fragment over the 5 links, and the receiver can reconstruct the packet as long as 4 out of 5 arrive. But this needs "multiple links" to start with...

cron2 wrote: Typical FEC implementations are not really helpful here, as packets do not get typically get corrupted in ways that FEC could help with, read "some bits get changed, but the packet still arrives, and FEC can be used to recover the original packet" - but if bits change, the underlying protocol (like "Ethernet") detect a broken checksum and drop the whole packet.

You didnt really understand what FEC is.Op's method is 100% workable.Try to google "erasure code" and "packet erasure channel" to make sure you understand what op talks about.

cron2 wrote: So what you could do is send the packet multiple times, in the hope that at least one of them gets through - but that would kill your bandwidth, and on a wireless link, might kill the rest of the usefulness for good...

You dont need to send packet multiple times,you can use reed solomon code,it adds m redundancy packet for every n original packets.If at least n of the m+n packets arrives,you can reconstruct the n packets. For examples,n can be 10 and m can be 3. It can significantly reduce packet loss(if packet loss isnt seriously so high that you cant get 10 out of 10+3) while the overhead is only 30%.

This is just what op meant by FEC.

Note:to use reed solomon,you may introduce a slight deplay if packets have to be reconstruct.But generally its not a big deal.

cron2 wrote: Other products do something like that if you have multiple available paths, that is, if you have 5 paths, packets are sent in 4 fragments + 1 parity fragment over the 5 links, and the receiver can reconstruct the packet as long as 4 out of 5 arrive. But this needs "multiple links" to start with...

To send redundancy data,"multiple links" is completely not necessary. In you example, 4 fragments + 1 parity can be transfer on a single channel.

There is a ticket for this feature:

https://community.openvpn.net/openvpn/ticket/949