Dear MAPRG, ETOSAT,

Lat= er 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 :=C2=A0

See you later,

Kind regards,

Nicolas= - on the behalf of my co-authors

--00000000000090c39305d0574801-- From nobody Wed Nov 10 13:06:46 2021 Return-Path: X-Original-To: etosat@ietfa.amsl.com Delivered-To: etosat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7B53A13C9 for ; Wed, 10 Nov 2021 13:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.45 X-Spam-Level: X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fau.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooqyuHSEa_OZ for ; Wed, 10 Nov 2021 13:06:35 -0800 (PST) Received: from mx-rz-3.rrze.uni-erlangen.de (mx-rz-3.rrze.uni-erlangen.de [131.188.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3AC3A13CB for ; Wed, 10 Nov 2021 13:06:34 -0800 (PST) Received: from mx-rz-smart.rrze.uni-erlangen.de (mx-rz-smart.rrze.uni-erlangen.de [IPv6:2001:638:a000:1025::1e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mx-rz-3.rrze.uni-erlangen.de (Postfix) with ESMTPS id 4HqHTK4VSrz20Zq; Wed, 10 Nov 2021 22:06:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fau.de; s=fau-2021; t=1636578389; bh=tk9/05LdkdMWkQdFDfBBeDYnr9G6Om87PlJL7qXSsiI=; h=Subject:To:References:From:Date:In-Reply-To:From:To:CC:Subject; b=St23H6E+ixWcFpYPeI5QZxSuk2xZ+YHseKU18s2cIBbQ7hAY1dTrkBtvWPVSXrDcG f/TdmGrqlSKtB5U/7XFaBiTRhXWMyRkfZ77PEqSFNSQnf7DToMyg1KdNhH/KqSRQrC ZAPd1Y3DbCLVGkCdZx57c/tx89UfCj3O0U/aa2qF/IB5ukDJLSwj5Gv1I/rCEeHIX6 +3Y13fKvVh9tXZ3FP+cuqh3xhtWGlKddJxzD86/D8d8eeKR694cAN2KH2gIV/JcfHa 7tIm9uofg8UuOwxclH7UZK+inPHCjp+zp3JY3JSm/Yg2xTP+qxjm62SL680RG/+4vz eD816rdsNul5w== X-Virus-Scanned: amavisd-new at boeck2.rrze.uni-erlangen.de (RRZE) X-RRZE-Flag: Not-Spam X-RRZE-Submit-IP: 131.188.37.210 Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) by mailhub.rrze.uni-erlangen.de (Postfix) with ESMTP id 4HqHTG6Bx8z20HZ; Wed, 10 Nov 2021 22:06:26 +0100 (CET) Received: from [192.168.178.35] (dynamic-077-009-122-084.77.9.pool.telefonica.de [77.9.122.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTPSA id B4BCB40F2449; Wed, 10 Nov 2021 22:06:26 +0100 (CET) To: Nicolas Kuhn , maprg@irtf.org, etosat@ietf.org References: From: Joerg Deutschmann Message-ID: Date: Wed, 10 Nov 2021 22:06:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [EToSat] [IETF112] Recommendations on using VPN over SATCOM X-BeenThere: etosat@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 21:06:41 -0000 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. > > 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 nobody Fri Nov 12 01:26:46 2021 Return-Path: X-Original-To: etosat@ietfa.amsl.com Delivered-To: etosat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63E73A096E for ; Fri, 12 Nov 2021 01:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCQ5Mlc7IbLr for ; Fri, 12 Nov 2021 01:26:35 -0800 (PST) Received: from mail-out04.uio.no (mail-out04.uio.no [IPv6:2001:700:100:8210::76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20CDE3A0877 for ; Fri, 12 Nov 2021 01:26:34 -0800 (PST) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out04.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mlSp7-00BfuT-50; Fri, 12 Nov 2021 10:26:17 +0100 Received: from ti0182q160-6712.bb.online.no ([95.34.115.135] helo=[192.168.1.7]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.94.2) (envelope-from ) id 1mlSp6-0005zE-Gb; Fri, 12 Nov 2021 10:26:17 +0100 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_734A584B-F30F-4C93-A6D4-4ED0C7E37409" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 12 Nov 2021 10:26:14 +0100 In-Reply-To: Cc: Nicolas Kuhn , maprg@irtf.org, etosat@ietf.org, Kristjon Ciko To: Joerg Deutschmann References:

X-Mailer: Apple Mail (2.3608.120.23.2.7) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 95.34.115.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=95.34.115.135; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.7]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 77F5BC73E7C52E3BC0D44992C7092E39A484270E Archived-At: Subject: Re: [EToSat] [Maprg] [IETF112] Recommendations on using VPN over SATCOM X-BeenThere: etosat@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2021 09:26:44 -0000 --Apple-Mail=_734A584B-F30F-4C93-A6D4-4ED0C7E37409 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 =E2=80=9Cwhatever=E2=80=9D: TCP-RINA, = TCP-ICN, =E2=80=A6 but also TCP-TCP), and we needed it to work in the = kernel. So, we made that - and it=E2=80=99s generally faster than PEPsal. For = one, because it=E2=80=99s in the kernel - but also because, being in the = kernel, it doesn=E2=80=99t need a SYN handshake to complete before it = can start establishing its own connection. It=E2=80=99s open source, and it=E2=80=99s here: https://github.com/kr1stj0n/pep-dna = I said =E2=80=9Cwe=E2=80=9D above but this should be =E2=80=9Che=E2=80=9D:= this was all done by my Ph.D. student Kristjon Ciko. Cheers, Michael --Apple-Mail=_734A584B-F30F-4C93-A6D4-4ED0C7E37409 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 =E2=80=9Cwhatever=E2=80=9D: = TCP-RINA, TCP-ICN, =E2=80=A6 but also TCP-TCP), and we needed it to work = in the kernel.

So, we made that - and it=E2=80=99s = generally faster than PEPsal. For one, because it=E2=80=99s in the = kernel - but also because, being in the kernel, it doesn=E2=80=99t need = a SYN handshake to complete before it can start establishing its own = connection.

It=E2=80=99s open source, and it=E2=80=99s here:

https://github.com/kr1stj0n/pep-dna

I said =E2=80=9Cwe=E2=80=9D= above but this should be =E2=80=9Che=E2=80=9D: this was all done by my = Ph.D. student Kristjon Ciko.

Cheers,

Michael

= --Apple-Mail=_734A584B-F30F-4C93-A6D4-4ED0C7E37409-- From nobody Sun Nov 14 07:38:43 2021 Return-Path: X-Original-To: etosat@ietfa.amsl.com Delivered-To: etosat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DA03A0C53 for ; Sun, 14 Nov 2021 07:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mskbiORQzJVl for ; Sun, 14 Nov 2021 07:38:36 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA9A3A0C4E for ; Sun, 14 Nov 2021 07:38:35 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id t83so11794692qke.8 for ; Sun, 14 Nov 2021 07:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/tD7Q1Lkp4nSRfZPnYvTK4krLkNNA758B9nFH91CSsI=; b=cQq9WF/GhmlSkCsn+Umwt1G/zIA7yx7PbxtiJlPbD4jnYTEWDLpV/YZ/iP/QSPdLWi 7ONMBlXnFUKAcZkKgxXU2Vb/9FEZpGe0JjXC1apABPUNmgiT6Cio19hs9WAd0iVzKhrm k4hGccc1MNH6yq3QFUx4l/kXsEOReBF9/WqIQPrORzrznUOm7arxhnlWdhug9cHeQ3IM mJCE2g4pVe9dZLVlzhcFflGQj22nSKndIaB9wjgxSqJPze2CJN80LLKOstAF4CxvHYf1 nd0NlHVaQCiDyfBk6G8avHNfrXa8OX8BPRjpKKH3FN6xaRzMKzbtVqh+VJGeX2WaWBuk byWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/tD7Q1Lkp4nSRfZPnYvTK4krLkNNA758B9nFH91CSsI=; b=pEXwBwLhRibCSvbjgls4LZgU0F/l4Kh3wT9uQrtBD7T6rap0pOhqA9cAO/y/amMpyJ 9bfmsUnC6E3DeGgdzwziyv9qLLRPncCEC3JWvCHqJj5zimnTE0NFXdAqNcSSQKg8oX2M gAkflTz0DQtkAXS63WrBhsNzQZ4dnKIjBcHzJwDTDh36+acevvvBninix6cnARAZRsr1 ba9BhEdVutCu4dO0wJAH1g+fS5PBDB9aDj2uJ3nNV9HRMWdEep/ufS7TNJeC5hRoctty ZDv7G0APIYnbh5aL1VBl6/nEzd0+qqtWcb2G8fOjttB0SjX4Y6tnn8SpklIAooHSuqts Fqqg== X-Gm-Message-State: AOAM530J02kxa9RUzBM3LIfhFAMbZtMbP1Je6EXzC+Msxl/gRjwnt8fB uGflNod0A8PUShRXrG65LYnCvC3tE78KE5Dw9S9UgmNb X-Google-Smtp-Source: ABdhPJwH7Ph9IVJP7qItx2YPMISt7EvvObFza8N2J5ENsQrOUA0vl77NrVxCYngtVv+2Nok3dE9YjeR0cUFdAc/ev5w= X-Received: by 2002:a37:a617:: with SMTP id p23mr25085341qke.466.1636904314555; Sun, 14 Nov 2021 07:38:34 -0800 (PST) MIME-Version: 1.0 References:

In-Reply-To: From: Nicolas Kuhn Date: Sun, 14 Nov 2021 16:38:23 +0100 Message-ID: To: Joerg Deutschmann Cc: maprg@irtf.org, etosat@ietf.org Content-Type: multipart/alternative; boundary="0000000000003350d205d0c17c3f" Archived-At: Subject: Re: [EToSat] [IETF112] Recommendations on using VPN over SATCOM X-BeenThere: etosat@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2021 15:38:41 -0000 --0000000000003350d205d0c17c3f Content-Type: text/plain; charset="UTF-8" Hello everyone, Thanks for the pointer, Joerg ! More inline. On Wed, Nov 10, 2021 at 10:06 PM Joerg Deutschmann 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 > --0000000000003350d205d0c17c3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello everyone,

<= /div>

Thanks for the pointer, Joerg !

Mor= e inline.

On Wed, Nov 10, 2021 at 10:06 PM Joerg Deutschmann <= joerg.deutschmann@fau.de>= ; wrote:

Dear Ni= colas,

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-project= s/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/12OUg6B60X9OA3WS8XvWrdFj5Ln6CJAV38= k6DWviIg6k/edit?usp=3Dsharing
- Which PEP did you use, was it PEPsal?

[NK] Yes
<= /div>

- 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 pr= ovider 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 surprisi= ng 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 <htt= ps://arxiv.org/pdf/2111.04586.pdf>
>
> See you later,
> Kind regards,
>
> Nicolas - on the behalf of my co-authors

--0000000000003350d205d0c17c3f-- From nobody Fri Nov 19 06:31:35 2021 Return-Path: X-Original-To: etosat@ietfa.amsl.com Delivered-To: etosat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC573A00D4 for ; Fri, 19 Nov 2021 06:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvSe7s59AHn2 for ; Fri, 19 Nov 2021 06:31:29 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 533173A00CF for ; Fri, 19 Nov 2021 06:31:29 -0800 (PST) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 047321B0009C for ; Fri, 19 Nov 2021 14:30:44 +0000 (GMT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id A134427C0054 for ; Fri, 19 Nov 2021 09:30:40 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 19 Nov 2021 09:30:40 -0500 X-ME-Sender:

X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrfeekgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggugfesthekredttd dtjeenucfhrhhomhepvfhomhculfhonhgvshcuoehtohhmsegvrhhgrdgrsggunhdrrggt rdhukheqnecuggftrfgrthhtvghrnhepvdfgleevkeegkefgueffkeevgeehfffhvddvvd evudetvdekledvvddtkeekveeunecuffhomhgrihhnpehtihdrthhopdgvshgrrdhinhht pdhirhhtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehsohhmvgdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqgeeh geehtddujedtqdduheehgedvgeehkedqthhomheppegvrhhgrdgrsggunhdrrggtrdhukh esfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy:

Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 19 Nov 2021 09:30:39 -0500 (EST) Date: Fri, 19 Nov 2021 14:33:28 +0000 From: Tom Jones To: etosat@ietf.org Message-ID: <20211119143328.GB24511@tom-desk.erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: Subject: [EToSat] 2nd QUIC and Satellite Open Stakeholder Meeting X-BeenThere: etosat@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2021 14:31:34 -0000 Hello ETOSat, https://ti.to/uoaerg/2nd-quic-and-satellite-open-stakeholder-meeting The Artes Mtails project is hosting a second QUIC and satellite open stakeholder meeting on the 2nd of December 2021. We held one of these meetings this year and found it to be a great vehicle for conversations about QUIC and Satellite. Registration is free at the link above and I have included the program below - Thanks Tom Program: The 2nd QUIC and Satellite Open Stakeholder Meeting will examine performance when using an Internet path that includes a satellite communication (SATCOM) network. **13:30 – 16:00 CET, Thursday 2nd December 2021, On-Line, via Webex** IETF QUIC is defined in RFC9000 and related RFCs. It provides an extensible transport, improving performance for web and other traffic and adding support for connection migration. In contrast to TCP, QUIC encrypts and authenticates all header fields, providing enhanced privacy and security. QUIC’s design prevents existing methods to enhance satellite network performance - such as PEPs, Compression, DPI for QoS, and other cross-layer enhancements, but also provides opportunities to influence the specifications and QUIC extensions, which if widely supported, could offer significant benefit to satellite services. People attending the meeting are invited to discuss performance over satellite systems, what is needed by the satellite communications sector, how people can collaborate on research, and what steps might be taken to increase stakeholder engagement in the design and use of QUIC over satellite services. *This will be an open meeting organised by the ESA MTAILS project ([https://artes.esa.int/projects/mtails](https://artes.esa.int/projects/mtails)). All participants will have to register on-line before they can join the webex meeting, details will be provided once the programme has been confirmed.* # Topics of Interest * Experience with IETF QUIC using Broadband Satellite * New Transport Mechanisms for QUIC over Satellite * Network-Layer Techniques for Encrypted Traffic (QoS, ECN, AQM) * Analysis of Concatenated Transport Paths (e.g. QUIC with Satcom and * WiFi or Cellular) * Operating and Managing Encrypted Satellite Services # Program ## Introduction/coordination - Gorry Fairhurst (5 minutes) Meeting Organisation and Note Well ## Part 1: QUIC Implementation and Performance ### (1.1) Evolution QUIC and Satellite over the Last 3 Years **Gorry Fairhurst, Tom Jones, Ana Custura** This presentation will trace the evolution of the IETF QUIC specifications and work in progress within the IETF, focussing on operation over a GEO satellite system It will identify key mechanisms impacted by the characteristics of satellite systems and review of current QUIC implementations. (15 minutes talks + 5 mins Q&A) ### (1.2) Protocols, QUIC, and SATCOM **Joerg Deutschmann** This presentation will present experience on using a QUIC Interop running with satellite links; and measurement of the performance of web protocols. (15 minutes talks + 5 mins Q&A) ### (1.3) Performance implications of interoperability **Nicolas Kuhn** This presentation will present experience when different combinations of QUIC servers and clients are considered. Looking at the file transfer time, this shows the importance of considering the acknowledgment strategy. (10 minute rapid talk *including* Q&A) Break: 10 minutes ## Part 2: Mechanisms to Enhance QUIC Performance ### (2.1) Application-Layer QoS Metrics To Aid Network Performance Monitoring and Diagnostics For Encrypted Traffic **Chi-Jiun Su** Most network statistics do not capture the impact of network conditions on user's applications and their quality of experience (QoE). Active measurements can help, but their results may not accurately reflect the QoE at end users. In this work, a low complexity non-intrusive method is proposed to estimate application-layer Quality of Service (QoS) metrics experienced by end-users. The method passively and continuously monitors user's traffic from a vantage point within the ISP network to capture the network conditions experienced by end user’s devices or internet applications. This approach is designed for encrypted traffic. (15 minutes talks + 5 mins Q&A) ### (2.2) Sliding Window FEC (SWF) over Satellite Networks **Matthieu Petrou** This presentation investigates the benefit to protect transport flows with a Sliding Window FEC (SWF) over satellite networks. We focus on QUIC protocol (picoquic version) and TCP in a SATCOM context with OpenSAND emulator. Considering several losses pattern scenarios, results show that CUBIC substantially gains from SWF protection compared to picoquic/BBR. We conclude that the use of SWF should not be only considered following the network loss characteristics, but also conjointly with the congestion control variant. (15 minutes talks + 5 mins Q&A) ### (2.3) Can QUIC Proxies Help Satellite Performance? **Joerg Deutschmann** This talk introduces the new QUICSAT project and ideas for using Proxies with QUIC in a satellite context. (10 minute rapid talk *including* Q&A) ### (2.4) Transport parameters for 0-RTT connections **N. Kuhn, E. Stephan, G. Fairhurst, T. Jones, C. Huitema** When clients resume a session to download a large object, the congestion control algorithms will require time to ramp-up the packet rate as a sequence of Round-Trip Time (RTT)-based increases. This presentation will describe plans for a method that can improve traffic delivery by allowing a QUIC connection to avoid a the slow process to discover key path parameters including a way to more rapidly grow the congestion window when used over paths with a larger bandwidth delay product. (10 minute rapid talk *including* Q&A) ## Part 3: Questions and Observations about QUIC over Satellite Open Mic -All workshop attendees. (20 minutes) Final Remarks # Note Well This meeting is expected to coordinate contributions that may be made to the Internet Engineering Task Force and Internet Research Task Force. The following note-well will therefore apply to all contributions at this meeting: https://irtf.org/policies/irtf-note-well-2019-11.pdf. From nobody Fri Nov 26 06:51:42 2021 Return-Path: X-Original-To: etosat@ietfa.amsl.com Delivered-To: etosat@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB18C3A0688 for ; Fri, 26 Nov 2021 06:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hloYf3elGCUP for ; Fri, 26 Nov 2021 06:51:34 -0800 (PST) Received: from mailin.dlr.de (mailin.dlr.de [194.94.201.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E142A3A0687 for ; Fri, 26 Nov 2021 06:51:33 -0800 (PST) X-IPAS-Result: =?us-ascii?q?A2HBBQAR9KBh/xeKuApaHgEBCxIMQIJ6gWsVgUILlVADk?= =?us-ascii?q?luJdYFgAwUEBwEBAQEBAQEBAQgBKgEKDAQBAQMBA4IIgnUCgngmOBMBAgQBA?= =?us-ascii?q?QEBAwIDAQEBAQEBAwEBBgEBAQEBAQUEAQECgRiFLzkNgjUifIEGAgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEWAQENNB41EgEeAQEBAQMBAStBGwIBCBEBAwEBIQECB?= =?us-ascii?q?AcCJQsUAwQBAQUDAgQTCAYLglmDFrB2eIEzgQGJaBCBOoYWgRSHCIJQgRWCe?= =?us-ascii?q?jA+gmMBgSMEERMtH4VHBI9dgS9LGhcBFAwQHgEMIB1RARkBARsMCwYLL5FgB?= =?us-ascii?q?4xYO4EvD54YB4INhn+DDox/iRcvFZV8kTSHA48TgiGeNy6DPoFIAgQCBAUCF?= =?us-ascii?q?oF4gX5xT4JpCUgXAg9XjgCDboRhhUp0OAIGAQoBAQMJkG8BgTWBEAEB?= IronPort-PHdr: A9a23:tm5x3BBVo5tVjo7jsvHtUyQUR0MY04WdBeb1wqQuh78GSKm/5ZOqZ BWZua80ygKTFtuFo9t/yMPu+5j6XmIB5ZvT+FsjS7drEyE/tMMNggY7C9SEA0CoZNTjbig9A dgQHAQ9pyLzPkdaAtvxaEPPqXOu8zESBg//NQ1oLejpB4Lelcu62/6v95HJYwhEmjWxbLJzI R6rsQjfq84ajJd4JK0s0BXJuHxIe+pXxWNsO12emgv369mz8pB+7Sleouot+MFcX6r0eaQ4V qFYAy89M28p/s3rtALMQhWJ63ABT2gZiBtIAwzC7BHnQpf8tzbxu+Rh1CWGO8D9ULY5Uimg4 ah2Uh/lkCcJOSAk/mHLhMJ+j6xbrxCgpxNjzIHZe4SVOOZ8fq7HYd8WWXdNU8BMXCJBGIO8a I4PAvIGMOhGqIn9okEBrQC5BQW2Gezg1CFFhnjy3aIgyOkuDAXG3BY6E90TrnvZtdP4P7odX u6p1qfH1ynDb+9I1jfn7ojFag4trO2SUb9zcsfd1FciGx/YglmOt4HrMC+Y2/kNvWWY8uZtV OCih3AppQxtojWhxsQhhIbXi4wbyF3J9zl1zJgzKNalRkB7ZtukH4FRtyGcL4Z5X8ciQ3tyt Ckn1LILv4OwcisSyJk/2hLTd+aLf5WL7x/sTuqdPDl1iXF/dL6hiRu+6VWsx+/iWsWuzlpGs zBJnsTOu30MzRDf986KQeZn8Ei7wzaAzQXT5/lBIUAziKXUNYYswqU1lpoPqUTDGTL2mFnug K+WaEok/u+o5vzpbLvgqJGSOI96hAH5PKotncKxG/o0PwYBUWea5+mwzrzj/UvlQLVQlPI6i LTWsJTAJcgBu6G2HRdZ0ocl6xmhEzeryMkUkWUdIF5Yex+KgJLlN0zALf37F/uznVqhnC9ux //cP73hBpvNLmLEkLfkZbtz9UlcyA8pwtBE4JJYEKwOL+ztV0/2sNzXFAQ0PBGww+b9Etlyy 50RVXqVAqCFKKPSrUOI5uU3LueDeoEVvyvzJOI55/P1jH82h0Mdfaez0ZsQcnC4EacuH0LMN VfQhewIDU8LsxYwCuvwhwvRfyRUYiPmY6U57yo8To6rJoDHT6ihhKbH0CrtTc4eXXxPFl3ZS SSgTI6DQfpZMEqv IronPort-Data: A9a23:gCT3gKou1a2VLvn06OuxeqnmQSpeBmIlZBIvgKrLsJaIsI4StFGz/ 9Y/7Vv2S5vuYmL1e9hoLMXyxf41yZCBn9BlTQo6rS02E3wUo8PMW4WQfhavNn6Yc8GfERo54 slDNNPJJ5A/Fi6BrRvzaOe69yAkjPGDSLD1UeSdai4ZqWOIMMsEoUsLd7kR0tUAbaGFKwORp cvp8YqYJ0C6nT9uLmxS7LiM7xZmvfD3sTVful0lefFNsliZnH4UCvojydqKww3FrvN8RqjiL 9v+8YxV3l813j8gWoz/y+ajIxEGG+eJM1eHhHALVfP6jhEa/idq2ahlaNMROBxd49mrc3Gd6 znvWbiYE1pB0njkwbxFO/VgO3gie/UAodcrGFDn2SCp5xSun0DEnrM+UynaAaVCorwuWDgUq 6RCQNwwRknra9yekerTptZE25xLwPnDZOvzbVk5kFk1pd5/KXzya/2iCe1whV/ctegSdRrqX Pf1XBI0BPj2j7yjDX9MYH42tL/AanAS6FS0onrNzUY8yzC7IACcTNEBmTcaEzCHbZw9o6qWm o7J1zj5WUAGd/a/8iCizVi1vuvQlgWgAbtHQdVU9tYy6LGS7kA3JDA4e36ahMHj0WOOcJReL VAO82wiqbJ0+EHDotvVBkX++S7Y+EdHC5wKSIXW6ynUokbQyzqeA2EfSXhNZfchsMYeSTgwk FOE9z/sLWI26uzMFiPAnluShTa0PiwlJE0wXC4JbyJe8si++boUkzuaG76PF4bw1LUZAwrY7 gyNlyEir7QekcBN0L+0lW0rmBqgopTEQAAw5wDPBDmo/gg/ZYi5fYXu5VzBq/pNRGqEcmS8U LE/s5D2xIgz4VulzURhnM1l8GmV2su4 IronPort-HdrOrdr: A9a23:TuzzRqnQff+jPPmU5Uj5DKMrCOvpDfIb3DAbv31ZSRFFG/Fwz/ re+MjzpiWE7wr5OUtQ4uxoV5PhfZqxz/NICMwqTNKftWrdyRGVxeNZnOjfKlTbckWUnNK1l5 0QEZSWY+eeMbEOt6fHCX6DferIruPqzEniv5a5854kd3ASV0hP1XYANjqm X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.87,266,1631570400"; d="txt'?scan'208,217";a="61291795" From: To: Thread-Topic: [Coin] IEEE Access Special Issue - Internet of Space: Networking Architectures and Protocols to Support Space-Based Internet Services Thread-Index: AQHX4tUYO9+gA4ZaFES8l4aSxWav0w== Date: Fri, 26 Nov 2021 14:51:29 +0000 Message-ID: <2cbf5637825e46f89cc0b83d411bd500@dlr.de> References: <50b1fe8d9c3344fdb16e7263959badae@dlr.de> <1009b71d4fdc463a8a401c9214fd078f@dlr.de> In-Reply-To: <1009b71d4fdc463a8a401c9214fd078f@dlr.de> Accept-Language: it-IT, de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="_004_2cbf5637825e46f89cc0b83d411bd500dlrde_" MIME-Version: 1.0 Archived-At: Subject: [EToSat] FW: [Coin] IEEE Access Special Issue - Internet of Space: Networking Architectures and Protocols to Support Space-Based Internet Services X-BeenThere: etosat@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2021 14:51:40 -0000 --_004_2cbf5637825e46f89cc0b83d411bd500dlrde_ Content-Type: multipart/alternative; boundary="_000_2cbf5637825e46f89cc0b83d411bd500dlrde_" --_000_2cbf5637825e46f89cc0b83d411bd500dlrde_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear EToSat colleagues, I remind you this special issue, probably interesting for many of us. Best Regards, Tomaso de Cola From: Coin On Behalf Of Tomaso.deCola@dlr.de Sent: Freitag, 26. November 2021 15:49 To: coin@irtf.org Subject: Re: [Coin] IEEE Access Special Issue - Internet of Space: Networki= ng Architectures and Protocols to Support Space-Based Internet Services Dear All, I kindly remind you about this interesting special issue on IEEE Access, wh= ose manuscript deadline is on *November 30th*. Looking forward to receiving your contributions! Best Regards, Tomaso de Cola ------------------------ Deutsches Zentrum f=FCr Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaff= enhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola@dlr.de= http://www.dlr.de/kn/institut/abteilungen/san From: Cola, Tomaso de Sent: Montag, 27. September 2021 17:38 To: 'coin@irtf.org' > Subject: IEEE Access Special Issue - Internet of Space: Networking Architec= tures and Protocols to Support Space-Based Internet Services (apologize for cross-posting) IEEE Access Special Issue - Internet of Space: Networking Architectures an= d Protocols to Support Space-Based Internet Services Submission Deadline: 30 November 2021 IEEE Access invites manuscript submissions in the area of Internet of Space= : Networking Architectures and Protocols to Support Space-Based Internet Se= rvices. This Special Section is focused on the most recent scientific research and = insights on the evolution of communication architectures and protocols for = an Internet of Space, able to boost the creation of a truly global Internet= by means of the integration of the current Internet with a new Internet of= Space. Such evolution is expected to have a significant impact on several = markets such as IoT/Industrial IoT, Mobile services, Industry 4.0, Governme= nt enterprise, and Connected mobility. The section shall cover work focused on aspects such as how to support the = operation of Tier-1, Tier-2 or even Tier-3 airborne/spaceborne networks; ho= w to address interoperability, within and across different protocol layers = in the network architecture, leveraging cross-layer design; and finally how= to design a more unified next generation Internet architecture able to tra= nsparently include spaceborne and airborne platforms in a way that allows f= or user-centric services, and a smooth operation of transient networks. However, an original and competent Internet of Space, calls for the definit= ion of a networking framework able to accommodate specific properties of dy= namic systems, including heterogeneous physical layers, frequent changes in= network topology, high propagation delays, and intermittent connectivity. = The dominant success factor for such a networking framework is low-cost ban= dwidth, although its capability to support low latency and high-throughput = services plays an important role. Secondly, a global Internet is only possible with a transparent integration= of an Internet of Space with the current Internet, while supporting multi-= tenants, multi-systems in different orbits and altitudes, as well as multip= le markets. Such an integration requires rethinking the Internet architectu= re in order to extend its operation to all systems above the Earth's surfac= e, which requires the integration of heterogeneous communication devices an= d protocols. Such a unifying networking framework will have a truly global = reach, allowing the connection between information producers and consumers = in any corner of Earth and Space. Last but not least, the seamless integrat= ion of an Internet of Space with the current Internet will lead to a global= empowerment, providing information access to everyone who may need it to s= ustain enriched human life, while mitigating some of the major limitations = of a network infrastructure that is built on Earth's surface, which is subj= ected not only to geographic limits but also to political limits. >From a technical perspective this Special Section is focused on the design = and performance evaluation of networking architectures and protocols for th= e Internet of Space, as well as on a more unified design that best deals wi= th the networking challenges to be faced. The topics of interest include, but are not limited to: * Network architectures, able to support multi-tenants, multi-systems i= n different orbits and altitudes, as well as multiple markets, while being = transparently integrated in the current Internet architecture. Such new, un= ifying, network architecture may require the exploitation of paradigms such= as Delay Tolerant Networking (DTN), and Information Centric Networking (IC= N). * Network virtualization, leveraging well-known technologies such as So= ftware Defined Networking (SDN) and Network Function Virtualization (NFV), = as well as their integration with the emerging concept of Multi-Access Edge= Computing (MEC), allowing the virtualization of networking, storage and co= mputing fabrics at the edge, required for the offloading of tasks that have= latency constraints from the core to the edge. * Decentralized Internet Infrastructure, allowing a scalable Internetwo= rking between computing processes and service hosted at the network edge (i= ncluding flying platforms and spaceborne platforms, such as smart satellite= constellations), leading to an end-to-end latency reduction due to user pr= oximity, as well as a reduction of network traffic through traffic localiza= tion and device-to-device communications. * Network management, such as support for the global orchestration of n= etwork functions on board spaceborne platforms (e.g., satellites) to best = support data processing and aggregation; seamless interoperation of mobile = Edge infrastructure and devices; resilience and seamless adaptation based o= n the capability to anticipate the behavior of services on a global scale. * Cognitive networking, in which programmable spaceborne networks allow= networked devices to perform customized computation, including the usage o= f Artificial Intelligence. Such cognitive functions will be exploited to de= velop more intelligent, adaptive networks, able to perceive network conditi= ons, decide upon those conditions, and learn from the consequences of its a= ctions. * Networking protocols, including support for inter-satellite communica= tions, and satellite to ground communications, Quality of Service (QoS) and= Quality of Experience (QoE), integrated security, and mobility, and their = integration with existing protocols such as IP routing (e.g. segment routin= g), transport protocols from the Transmission Control Protocol (TCP) and Us= er Datagram Protocol (UDP) to Quick UDP Internet Connections (QUIC), and ap= plication protocols such as Domain Name Service (DNS). * Wireless technologies, including not only the usage of radio frequenc= y systems but also free space optical systems, and a combination of both. * Network measurement & performance, to assist in understanding and exp= osing the performance of spaceborne networking resources, infrastructure, a= nd available communication protocols in a variety of ground-to-space, inter= -satellite communication scenarios. * Privacy, security and trustworthiness, assuming end-to-end scenarios = involving satellites with computational and storage capabilities, and cover= ing aspects such as data security, decentralized trust architectures. * Impact on Internet services, such as advanced IoT services (e.g., Aug= mented Reality/Virtual Reality in manufacturing or farming) served by space= borne platforms and spaceborne communications; real-time IoT applications (= e.g., critical monitoring of public infrastructures); awareness services (e= .g., public safety services). * Impact on data management aspects, including the support of the next = generation of Edge computing in space, as well as a fast cooperation betwee= n a large set of Edge-based producers of data. We also highly recommend the submission of multimedia with each article as = it significantly increases the visibility and downloads of articles. Associate Editor: Rute C. Sofia, fortiss GmbH, Germany Guest Editors: * Paulo Mendes, Airbus, Germany * Vassilis Tsaoussidis, Democritus University of Thrace, Greece * Tomaso de Cola, DLR, Germany * Scott Burleigh, California Institute of Technology, USA * Mianxiong Dong, Muroran Institute of Technology, Japan * Eduardo Cerqueira, University Federal of Par=E1, Brazil ------------------------ Deutsches Zentrum f=FCr Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaff= enhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola@dlr.de= http://www.dlr.de/kn/institut/abteilungen/san --_000_2cbf5637825e46f89cc0b83d411bd500dlrde_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear EToSat colleagues,

I remind you this special issue, probably interestin= g for many of us.

Best Regards,

Tomaso de Cola

From: Coin <coin-bounces@irtf.org> On Behalf Of Tomaso.deCola@dlr.de
Sent: Freitag, 26. November 2021 15:49
To: coin@irtf.org
Subject: Re: [Coin] IEEE Access Special Issue - Internet of Space: N= etworking Architectures and Protocols to Support Space-Based Internet Servi= ces

Dear All,

I kindly remind you about this interesting special i= ssue on IEEE Access, whose manuscript deadline is on *November 30^th=*.

Looking forward to receiving your contributions!

Best Regards,

Tomaso de Cola

—R= 12;——————————&#= 8212;——————————= —

Deutsche= s Zentrum f=FCr Luft- und Raumfahrt (DLR)
German Aerosp= ace CenterInstitute of = Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 822= 34 Wessling | Germany

Tomaso de Cola, Ph.D.
Telefon += 49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola@dlr.de
http://www.dlr.de/kn/institut/= abteilungen/san

From: Cola, Tomaso de
Sent: Montag, 27. September 2021 17:38
To: 'coin@irtf.org' <coin@irtf.o= rg>
Subject: IEEE Access Special Issue - Internet of Space: Networking A= rchitectures and Protocols to Support Space-Based Internet Services<= o:p>

(apologize for cross-po= sting)

IEEE Access Special = Issue - Internet of Space: Networking Architectures and Protocols to = Support Space-Based Internet Services

Submission Deadline:= 30 November 2021

IEEE Access invi= tes manuscript submissions in the area of Internet of Space: Networkin= g Architectures and Protocols to Support Space-Based Internet Services.

This Special Section is= focused on the most recent scientific research and insights on the evoluti= on of communication architectures and protocols for an Internet of Space, able to boost the creation of a= truly global Internet by means of the integration of the current Internet = with a new Internet of Space. Such evolution is expected to have a significant = impact on several markets such as IoT/Industrial IoT, Mobile services, Indu= stry 4.0, Government enterprise, and Connected mobility.<= /p>

The section shall cover= work focused on aspects such as how to support the operation of Tier-1, Ti= er-2 or even Tier-3 airborne/spaceborne networks; how to address interoperability, within and across different pro= tocol layers in the network architecture, leveraging cross-layer design; an= d finally how to design a more unified next generation Internet architectur= e able to transparently include spaceborne and airborne platforms in a way that allows for user-centric se= rvices, and a smooth operation of transient networks.

However, an original an= d competent Internet of Space, calls for the definition of a networking framewor= k able to accommodate specific properties of dynamic systems, including het= erogeneous physical layers, frequent changes in network topology, high prop= agation delays, and intermittent connectivity. The dominant success factor for such a networking framework = is low-cost bandwidth, although its capability to support low latency and h= igh-throughput services plays an important role.

Secondly, a global Inte= rnet is only possible with a transparent integration of an Internet of Space with the current Internet, while supporting multi-= tenants, multi-systems in different orbits and altitudes, as well as multip= le markets. Such an integration requires rethinking the Internet architectu= re in order to extend its operation to all systems above the Earth’s surface, which requires the integra= tion of heterogeneous communication devices and protocols. Such a unifying = networking framework will have a truly global reach, allowing the connectio= n between information producers and consumers in any corner of Earth and Space. Last but not least, the seamless integra= tion of an Internet of Space with the current Internet will lead to a global em= powerment, providing information access to everyone who may need it to sust= ain enriched human life, while mitigating some of the major limitations of = a network infrastructure that is built on Earth’s surface, which is subjected not only to geographic = limits but also to political limits.

From a technical perspe= ctive this Special Section is focused on the design and performance evaluat= ion of networking architectures and protocols for the Internet of Space, as well as on a more unified design that best d= eals with the networking challenges to be faced.

The topics of interest = include, but are not limited to:

Network architectures<= /b>, able to support multi-tenan= ts, multi-systems in different orbits and altitudes, as well as multiple ma= rkets, while being transparently integrated in the current Internet architecture. Such new, unifying, network architec= ture may require the exploitation of paradigms such as Delay Tolerant Networking (DTN), and Information Centric Networki= ng (ICN).
Network virtualization= , leveraging well-known tech= nologies such as Software Defined Networking (SDN) and Network Function Virtualiza= tion (NFV), as well as their integration with the emerging concept of Multi-Access Edge Computing (MEC), allowing the virtualization of ne= tworking, storage and computing fabrics at the edge, required for the offlo= ading of tasks that have latency constraints from the core to the edge.
Decentralized Internet Infras= tructure, allowing a = scalable Internetworking between computing processes and service hosted at = the network edge (including flying platforms and spaceborne platforms, such as smart satellite constellations), leading= to an end-to-end latency reduction due to user proximity, as well as a red= uction of network traffic through traffic localization and device-to-device= communications.
Network management, such as support for the global= orchestration of network functions on board spaceborne platforms (e.= g., satellites) to best support data processing and aggregation; seamless interoperation of mobile Edge infrastructure and= devices; resilience and seamless adaptation based on the capability to ant= icipate the behavior of services on a global scale.

<= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;mso-list:l2 level1 lfo3"> Cognitive networking, in which programmable spaceb= orne networks allow networked devices to perform customized computation, in= cluding the usage of Artificial Intelligence. Such cognitive functions will be exploited to develop more intelligent, ad= aptive networks, able to perceive network conditions, decide upon those con= ditions, and learn from the consequences of its actions.<= /li>
Networking protocols, including support for inter-= satellite communications, and satellite to ground communications, Quality of Service (QoS) and Quality of Experience (QoE), integrated= security, and mobility, and their integration with existing protocols such= as IP routing (e.g. segment routing), transport protocols from the Transmission Control Protocol (TCP) and User Datagram Protocol (U= DP) to Quick UDP Internet Connections (QUIC), and application protoc= ols such as Domain Name Service (DNS).
Wireless technologies<= /b>, including not only the usag= e of radio frequency systems but also free space optical systems, and a com= bination of both.
Network measurement & per= formance, to assist i= n understanding and exposing the performance of spaceborne networking resou= rces, infrastructure, and available communication protocols in a variety of ground-to-space, inter-satellite communication s= cenarios.
Privacy, security and trustwo= rthiness, assuming en= d-to-end scenarios involving satellites with computational and storage capa= bilities, and covering aspects such as data security, decentralized trust architectures.
Impact on Internet services, such as advanced IoT = services (e.g., Augmented Reality/Virtual Reality in manufacturing or farmi= ng) served by spaceborne platforms and spaceborne communications; real-time IoT applications (e.g., critical moni= toring of public infrastructures); awareness services (e.g., public safety = services).
Impact on data management asp= ects, including the s= upport of the next generation of Edge computing in space, as well as a fast= cooperation between a large set of Edge-based producers of data.

We also highly recommen= d the submission of multimedia with each article as it significantly increa= ses the visibility and downloads of articles.

Associate Editor:&nb= sp;Rute C. Sofia, for= tiss GmbH, Germany

Guest Editors:

Paulo Mendes, Airbus, Germany
Vassilis Tsaoussidis, Democritus= University of Thrace, Greece
Tomaso de Cola, DLR, Germany
Scott Burleigh, California Insti= tute of Technology, USA
Mianxiong Dong, Muroran Institut= e of Technology, Japan
Eduardo Cerqueira, University Fe= deral of Par=E1, Brazil

—R= 12;——————————&#= 8212;——————————= —

Deutsche= s Zentrum f=FCr Luft- und Raumfahrt (DLR)
German Aerosp= ace CenterInstitute of = Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 822= 34 Wessling | Germany

Tomaso de Cola, Ph.D.
Telefon += 49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola@dlr.de
http://www.dlr.de/kn/institut/= abteilungen/san

--_000_2cbf5637825e46f89cc0b83d411bd500dlrde_-- --_004_2cbf5637825e46f89cc0b83d411bd500dlrde_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=83; creation-date="Fri, 26 Nov 2021 14:49:31 GMT"; modification-date="Fri, 26 Nov 2021 14:49:31 GMT" Content-ID: Content-Transfer-Encoding: base64 LS0gDQpDb2luIG1haWxpbmcgbGlzdA0KQ29pbkBpcnRmLm9yZw0KaHR0cHM6Ly93d3cuaXJ0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb2luDQo= --_004_2cbf5637825e46f89cc0b83d411bd500dlrde_--