Subject: [Maprg] [IETF112] Recommendations on using VPN over SATCOM

From: Nicolas Kuhn <[email-masked]>
Date: Tue, 9 Nov 2021 09:56:11 +0100

Dear MAPRG, ETOSAT,

Later today, we will present some results on exploring the mixed usage of
VPN and congestion controls over emulated SATCOM systems.

We have published a short technical report on the topic :
https://arxiv.org/pdf/2111.04586.pdf

See you later,
Kind regards,

Nicolas - on the behalf of my co-authors

---

From: Joerg Deutschmann <[email-masked]>
Date: Wed, 10 Nov 2021 22:06:23 +0100

Dear Nicolas,

thanks a lot! We did similar measurements earlier this year considering
- no VPN, OpenVPN (UDP only), Wireguard
- single/multiple TCP flows
- different applications
- different access technologies and operators (4x GEO, LEO Starlink, 
LTE, DSL)

The results are available here:
https://www.cs7.tf.fau.eu/research/quality-of-service/qos-research-projects/sat-internet-performance/
Executive summary and presentation is available in English language; 
unfortunately the full report is only available in German language right 
now, but I'll translate it upon request.

One comment and a few questions:
- In order to see how close the performance comes to the bottleneck link 
rate, I've calculated corresponding goodput values in this spreadsheet: 
https://docs.google.com/spreadsheets/d/12OUg6B60X9OA3WS8XvWrdFj5Ln6CJAV38k6DWviIg6k/edit?usp=sharing
- Which PEP did you use, was it PEPsal?
- What is the motivation of testing different CCs on the end hosts and 
on the PEP (Section IV-A)? Unless there are delays and/or packet losses 
on the local network and/or Enterprise network, I'd assume that the 
performance is determined by the satellite link (and the 
local/enterprise network has negligible performance impact)?
- The poor performance of "Loss LEO" with CUBIC is a bit surprising to 
me. Which loss rate and which "variable RTT" was used? In our VPN 
measurements, the Starlink LEO megaconstellation performed quite well 
despite some packet loss.

Thanks and best regards,
Joerg

On 09.11.21 09:56, Nicolas Kuhn wrote:
> Dear MAPRG, ETOSAT,
> 
> Later today, we will present some results on exploring the mixed usage 
> of VPN and congestion controls over emulated SATCOM systems.
> 
> https://arxiv.org/pdf/2111.04586.pdf <https://arxiv.org/pdf/2111.04586.pdf>
> 
> See you later,
> Kind regards,
>

---

From: Michael Welzl <[email-masked]>
Date: Fri, 12 Nov 2021 10:26:14 +0100

Hi everyone,

I wanted to follow up on a particular point here, in the question from Joerg to Nicolas - with a shameless plug  :-)

> - Which PEP did you use, was it PEPsal?

For our own research (on something completely different) we looked for an open source split-connection PEP, and PEPsal was indeed the fastest - and, it seems, the most common - open source PEP that we found.
However, we needed something slightly different: translating not only TCP-TCP but TCP-whatever (truly “whatever”: TCP-RINA, TCP-ICN, … but also TCP-TCP), and we needed it to work in the kernel.
So, we made that - and it’s generally faster than PEPsal. For one, because it’s in the kernel - but also because, being in the kernel, it doesn’t need a SYN handshake to complete before it can start establishing its own connection.

It’s open source, and it’s here:
https://github.com/kr1stj0n/pep-dna <https://github.com/kr1stj0n/pep-dna>

I said “we” above but this should be “he”: this was all done by my Ph.D. student Kristjon Ciko.

Cheers,
Michael

---

From: Nicolas Kuhn <[email-masked]>
Date: Sun, 14 Nov 2021 16:38:23 +0100

Hello everyone,

Thanks for the pointer, Joerg !

More inline.

> - Which PEP did you use, was it PEPsal?
[NK] Yes

> local/enterprise network has negligible performance impact)?
[NK] There are some cases of deployments where the operator / box provider
can tune the CC.
As a result, there were discussions on whether using BBR was performing
better than CUBIC.
This is the main motivation.

> despite some packet loss.
[NK] The RTT was around 60ms but most importantly the loss rate was 1%.
This huge packet loss may be the reason for the poor performance of CUBIC.