adaptive compression including time to (de)compress data

[gavinmc]

Hi,

I've been mulling over a problem I have with OpenVPN compression and wondered
if an idea I had might make sense or if (more likely) it is just the ramblings
of a beginner. If you bear with me I'll describe it briefly and someone might
say why it's a bad idea.

As I understand it, if the compression ratio is R (ie R=0.9 means a 10%
reduction in data size), then you'll get data compression if R<1, but not if
R>1. Is that right? The docs seem to say that's roughly it.

As far as I can see, there are two criteria which determine whether compressing
data is a good idea:

1. The data, when compressed, is smaller than the original.
2. The time taken to compress is less than the time saved by the compression.

#1 is really a subset of #2 -- if the data doesn't compress, it won't
save time to compress it. So, an ideal adaptive compression might determine
whether to compress or not based on criteria #2.

Suppose openvpn can monitor the average Bitrate of data sent across the link,
B (this should be independent of whether compression is in use). The time
taken to forward a frame of size M across the link should be roughly:

Time = M / B seconds

If the observed compression ratio is R as above, the transfer time saved by
compressing the data should be about:

dTime = (1-R) * M / B seconds

One could in principal monitor cTime, the average time taken to compress the
data and possibly even xTime, the average time taken to expand the data. Then
use a criteria like:

if(dTime > (cTime + xTime)) {
enable_compression;
}

xTime might be awkward to determine, as it's only available at the far end, but
you could ignore it if need be and just use cTime. I would imagine compressing
is probably more costly than decompressing.

The reason I suggest this is that I've noticed that a busy CPU on a slow laptop
appears to kill OpenVPN performance if compression is enabled. My guess is
that the compression or decompression time is slowing things down. I would
prefer that the adaptive compression would realise that the compression is not
a benefit in this case and disable it.

Maybe this is overly simplistic, pure nonsense or maybe OpenVPN already does
this (the man page doesn't seem to suggest it, but I might have misread).

Thanks in advance for any opinions, corrections or criticisms,

Gavin

[hannuko]

Sounds a good idea to me.

Instead of turning compression on/off, the system could also move to a simpler compression algoritm, or use faster compressing parameters.

[Mimiko]

There is no need to adapt the compression ratio, as it is though like a file compression by some software: use the maximum computing power to reduce maximally the size. Either you use compression or not based on needs and computing power. Usually, the speed thru the tunnel is not at full line speed, so a compression is needed to push more data. This compression consumes computing power, so in case of production server, where only OpenVPN is running and/or a gateway, with current computiong speeds, compression does not increase significally the latency. Even a pentium III with 630MHz with other software running, can handle a speed of 2-3 MB/s without much latency.

[janjust]

this is exactly what

Code: Select all

comp-lzo adaptive

does : it watches the compression stream and turns compression on or off.