[PATCH 0/5] ZSTD compression support for OpenSSH

[Sebastian Andrzej Siewior]

On 2020-09-08 15:06:31 [+0200], Steffen Nurpmeso wrote:
> Sebastian Andrzej Siewior wrote in
>  <20200908073415.ymmao6fcemn5hqns at flow>:
>  |A key stroke is here 10 bytes of raw data which zstd compresses usually
>  |into 10 bytes while zlib manages to squeeze it into 5 bytes. This leads
>  |to better compression ratio for zlib in ssh's accounting (visible in
>  |verbose mode after connection terminates). The data length, that will be
>  |transferred over the wire, is the same for 5 and 10 bytes data after the
>  |crypto part (with padding and so on). 
> 
> Then something must be wrong on the configuration side for sure.
> I personally have switched all possible private use cases to zstd
> years ago, in can be configured to be tremendously fast, faster
> even than lz4, no?, or compress almost as good as xz, it depends
> on the data, xz can surely outperform it in size.
> On the decompression side zstd is just tremendously fast.
> And all in one algorithm.

I don't follow. A key stroke is one ssh packet which has 10 bytes.
This packet must be compressed in a way that it can be fully
decompressed once received on the remote side (ZSTD_e_flush in zstd
terms which finishes the current block). Due to the way framing works in
zstd we end up with a 10 bytes block. Higher compression levels can
achieve 9 bytes but as I stated it does not make sense due to padding of
the compressed data. The zlib framing is smaller here but then zstd
knows exactly how many bytes it will decompress and when the block/frame
ends.

Do note that this is not simple file compression where you end up with
one frame and blocks created on demand.

> --steffen

Sebastian