Re: [Maprg] [EToSat] [IETF112] Recommendations on using VPN over SATCOM

[Nicolas Kuhn <[e-mail]>]

Hello everyone,

Thanks for the pointer, Joerg !

More inline.

On Wed, Nov 10, 2021 at 10:06 PM Joerg Deutschmann <[e-mail]>
wrote:

> 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?
>
[NK] Yes

> - 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)?
>
[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.

> - 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.
>
[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.

>
> 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.
> >
> > We have published a short technical report on the topic :
> > https://arxiv.org/pdf/2111.04586.pdf <
> https://arxiv.org/pdf/2111.04586.pdf>
> >
> > See you later,
> > Kind regards,
> >
> > Nicolas - on the behalf of my co-authors
>