Hello all, Have been following this. Particularly I was...

Hello all,

Have been following this. Particularly I was interested in their claim to a new compression algorithm.
For those in the know - check out the de-dexed Tunnel.java.

Their process client side seems to be:
> Construct 64k buffers for incoming and outgoing
> Aggregate arbitrary packets into the relevant buffer
> Transmit/recieve to Wangle server via UDP with TCP ACKs replicated with a custom "MicroACK"
> If outbound, compress using Facebook's OSS zstd on the phone-side
> If inbound, decompress using Facebook's OSS zstd on the phone-side

There are a few major benefits but also problems with this approach depending on -
a) The latency sensitivity of the applications being used over the link due to the buffering
b) The possibility of many packets being dropped and requiring resend as the buffer rather than individually can present a problem on unreliable internet services
c) From a data reduction standpoint, the compressibility of the data. Encrypted data which is now very prevalent (the HTTPS everywhere movement is growing every day especially with some of the HTTP2 requirements) is inherently difficult to compress or deduplicate due to the randomness of the data stream. Given Wangle is not highjacking/MITM the connection (and thank Zeus for that, privacy nightmare), it is very likely encrypted data will see little benefit from the compression side. Will still be helped under those circumstances that benefit any packet via the buffering.

However, the major conclusion to be drawn - the compression on the client side and the server edge is standard zstd java library use. So far there is no evidence of a novel Wangle-originated compression algorithm in use anywhere in the chain. What are people's thoughts on this?

Given this is a technical thread, please avoid posting Oookla or other speedtests in here. They are unrepresentative of everyday usage. Thanks.

p.s. zstd library - https://github.com/facebook/zstd