Very poor performance over real geostationary satellite link

[bizzbyster]

This is so far off from expectation (my link is ~40 Mbps / 5 Mbps without QPEP) I wonder if there is something dumb that I'm not doing. Any ideas?

[pavja2]

Thanks for raising the issue! We've also encountered mixed performance in real-world networks depending on which provider we use QPEP on. Never seen anything quite as drastic as that though! It's not completely clear what the causes are, but there are a few things that might be worth looking into:

• We've found that some satellite ISPs employ QoS rules which are really hostile to UDP traffic. If you play around with port numbers (maybe port 53 or 1194) you might be able to circumvent this - but it depends on the specific ISP and how they treat UDP connections.
• QPEP isn't very performance optimized in its current state and a lot of its performance will hinge on the single-thread speed of your processor. This isn't an issue with reasonably modern home computers, but if you're hosting it on a slower cloud box or something like a raspberry pi, that could be contributing.
• Your path to the QPEP server may be a bottleneck, depending on how much bandwidth you have for that link. It may be worth using iperf to see what the link between your home network and the QPEP server box is like.

Hope that helps!

[bizzbyster]

Hi @pavja2,

Thanks for responding.

Using iperf, running on the same server and listening on the same port (443) to eliminate any port-specific issues in the handling of traffic by the ISP, I'm able to transfer udp at 40 Mbps over the satellite connection.

I will try downloading a file from Caddy Server, which runs quic-go, running on that same machine to eliminate more possible issues.

Thanks!

[bizzbyster]

You can find a test Caddy Server with QUIC enabled here. I was able to download this large file (https://fasternet.org/76MBCompressedFile.tar.gz) at an average rate of 16 Mbps over the satellite connection using Chrome -- use of QUIC confirmed via inspection of Wireshark capture. That's not the 40 Mbps I am able to get with TCP (plus the in network PEP) but its doing more like what I would expect QUIC might be able to do over geostationary satellite Internet.

So I'm still stumped why QPEP wouldn't be seeing these same gains, especially since both QPEP and Caddy Server are based on the same quic-go implementation. Next I will retry QPEP with the same quik-go version and see if that explains it. Let me know if you have any other thoughts.

[bizzbyster]

• https://drive.google.com/uc?id=1ZaCeyubyj7Qy2jL-IW4Z_lkbt_5QBuzH&export=download uses Google QUIC
• https://fasternet.org/73MBCompressed.tar.gz uses quic-go

With Google QUIC i’m seeing the file downloading at about 20 Mbps over Viasat and with quic-go (the version used Caddy Server) i’m seeing the file downloading at about 1.3 Mbps over Viasat.

So this appears to be a problem in quic-go that I will report there.

[masorx]

@bizzbyster Did you ever report this and did they get back to you?

[bizzbyster]

Yes but nothing happened. My team has started working on this fork of qpep that includes a Windows (and soon a Mac) client -- https://github.com/Project-Faster/qpep. We are starting performance testing soon and will be looking to document and fix the issue. Feel free to join the collaboration there.

[rst0git]

@bizzbyster The following recent paper discusses some of the performance issues of QUIC over satellite networks: Performance of QUIC Implementations Over Geostationary Satellite Links