Subject: [EToSat] Re QUIC performance and SATCOM

From: "[email-masked]" <[email-masked]>
Date: Mon, 11 Feb 2019 00:41:39 +0000 (UTC)

(Belatedly catching up with the list and archives)

An interesting paper, but it's effectively comparing the last gasp of text HTTP going to binary (HTTP/2.0 over TLS/TCP, called HTT in the paper, originally Google's SPDY) with binary QUIC (UDP) - another Google-sourced protocol. I think it's safe to presume that geostationary satellites aren't Google's core market.

That QUIC performs slightly worse than SPDY over geo does not surprise. I would think that this is the latest in a long line of PEP satellite accelerators gradually losing ground and levels of enhancement as the endpoints change/improve/add security - PEPping HTTP/0.9 to 1.1 unencrypted allowed e.g. HTTP 'object' (what RFC1945 calls files) caching and selective filtering and prefetch with parsing and advance requesting of objects (even in Javascript through PEP onboard parsers), and provides a large boost for e.g. Windows XP machines with poor TCP stacks, where RFC1323 and large windows aren't handled well in the endpoints. The endpoints have gotten better, but the PEP acceleration gains have gotten less.

There's probably scope for a longer paper overviewing the history of accelerators, showing what used to provide bang for the buck and speedups (intermediate caching, filtering, prefect) has gradually gone away in stages. (Whether no longer running the code adds to PEP reliability is an open question.) There's probably also an argument for blocking QUIC to drop back to SPDY over satellite links just to get the TCP windowing under TLS so that windows can be manipulated. Should PEPs be striving to be a full man-in-the middle attacker with more delegation, or is that approach more trouble than it's worth? Don't know.

Lloyd Wood [email-masked] http://about.me/lloydwood

Nicolas Kuhn wrote:
> We have recently posted on ArXiv an article on QUIC and its performance over a GEO SATCOM link.

https://arxiv.org/pdf/1810.04970.pdf

> This paper has been presented at IETF 103 @MAPRG

https://datatracker.ietf.org/meeting/103/materials/agenda-103-maprg-00

>The code used to run these experiments is available, so do not hesitate to contact us if you want to reproduce our experiments.