[GLLUG] Openvpn overhead?

[Tim Woodall]

On Thu, 5 Apr 2018, James Courtier-Dutton wrote:

> On 4 April 2018 at 19:58, Tim Woodall via GLLUG
> <gllug at mailman.lug.org.uk> wrote:
>> Hi all,
>>
>> I have a wifi link between two (debian) firewalls that are in separate
>> premises. I'd like to put a wired link in but that requires getting some
>> permissions so it won't be quick (although it's simple to do)
>>
>> Over the wifi link I can scp data at at least 1MB/s which isn't great
>> but it's not too bad. iwconfig says the connection is at 150Mb/s so in
>> theory I should be able to do 10x that. (One end is an access point into
>> a 100Mb ethernet link while the other end is a USB wifi dongle so I'm
>> not expecting 15MB/s)
>>
>
> The problems you are likely to run into are the different link speeds.
> Whenever data travels between links of different speeds, packets get lost.
> Approximately, and 100Mbits/second Ethernet link can transfer data at
> about 10Mbytes/second.
> TCP does its best to backoff, and thus reduce packet loss to a minimum
> but each time a packet is lost, a TCP transfer slows.

Many thanks for pointing out the obvious that I should have realised.

Changing to using tcp for the VPN link has greatly improved things!

I would have liked to use the shaper option but it appears that this is
only available on the client - you can't use it in to ratelimit the
server on the link (AFAICT).

If I had lots of free time, I might try seeing if I could add some sort
of FEC algorithm to openvpn. My guess (from no data) is that packet loss
is bursty so, when packets are queuing (due to rate limiting which would
also need to be implemented for the server end too) then an encoding
similar to the CIRS code on CDs would be a place to start.

When the channel is not busy, just duplicating packets would help with
no added latency.

But I don't have lots of free time (roll on retirement - I will be SO
busy ;-) )