Re: [EToSat] Packet lost on last mile network?

Christian Huitema <huitema@huitema.net> Wed, 13 May 2020 15:50 UTC

Return-Path: <huitema@huitema.net>
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 711193A1003 for <etosat@ietfa.amsl.com>; Wed, 13 May 2020 08:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ONYroqpnASIl for <etosat@ietfa.amsl.com>; Wed, 13 May 2020 08:50:19 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 681113A0FEB for <etosat@ietf.org>; Wed, 13 May 2020 08:50:04 -0700 (PDT)
Received: from xse434.mail2web.com ([66.113.197.180] helo=xse.mail2web.com) by mx36.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jYtdr-0005ex-FU for etosat@ietf.org; Wed, 13 May 2020 17:50:00 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49MfHz4tZTzLjr for <etosat@ietf.org>; Wed, 13 May 2020 08:49:51 -0700 (PDT)
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jYtdn-0001bg-HW for etosat@ietf.org; Wed, 13 May 2020 08:49:51 -0700
Received: (qmail 12230 invoked from network); 13 May 2020 15:49:51 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.43.109]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <etosat@ietf.org>; 13 May 2020 15:49:50 -0000
Content-Type: multipart/alternative; boundary="Apple-Mail-6B21640D-72D4-477A-AEE8-8D5BA2D5C177"
Content-Transfer-Encoding: 7bit
From: Christian Huitema <huitema@huitema.net>
Mime-Version: 1.0 (1.0)
Date: Wed, 13 May 2020 08:49:49 -0700
Message-Id: <7C07C17B-2A81-4B8A-94E2-87858A5FDDC2@huitema.net>
References: <HE1PR0702MB37550F63AB9CDD4FD637CC3EA9BF0@HE1PR0702MB3755.eurprd07.prod.outlook.com>
Cc: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>, "etosat@ietf.org" <etosat@ietf.org>
In-Reply-To: <HE1PR0702MB37550F63AB9CDD4FD637CC3EA9BF0@HE1PR0702MB3755.eurprd07.prod.outlook.com>
To: Nitay Argov <Nitay@gilat.com>
X-Mailer: iPhone Mail (17D50)
X-Originating-IP: 66.113.197.180
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0RZ/HtDapBdRUZhgsSk2AkqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDYbC1vFNC/qFxauDStI0QV8RX qYbtEQV1z/L435ZRxFS7S+oSA/nBYBORgHskQAyz+rYZvu7UEJiU3s27VgKHO7lwS3dBJTnTxDoD vBGGxpgwWbxrOZCJSMpTl/yE2fo2ANRUfkFjthfvkYMyqnVcYgZ6weYgSzquK2hxskqXvy8woCTx LKweTbuJ+19zsyHVGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLCanpZsarZa LIRpEqA8mZHAckWQtBD6EVGGpW9zBe910IbnuMu9EEp+gJkNPI3I7UNjJKRX8FcYJiqTX88iQo/2 ie80q3LAG2MiIaIREzT1xNjuO97khcUFBr/guEWv1bdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1LxVbS0Br3rcHZz1Xa/wpZzF2jZAOanSBpz6Rja2u/0jIpdzLyApdOF9KexMCQbpkqp9uz hJrm7FMIb2gsrvBsDfysta6u1iHEyuS7GD1uvcoSUX/PG8fKeiJDJ+KMKr9UJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/1nH4vq1S01_XBVt7KcFtVomhqXo>
Subject: Re: [EToSat] Packet lost on last mile network?
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." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2020 15:50:22 -0000

I am running simulations of that lossy configuration as part of the Picoquic test suite. When using BBR, I observe that the large transfer over a high speed link takes a couple seconds more than in the absence of losses. The issue is not congestion, and not even the 1.6% bandwidth consumed by error correction. The problem is the cascade: some of the corrections of lost packets will be lost again, which causes several rounds of retransmission at the end of the transfer.

-- Christian Huitema 

> On May 12, 2020, at 11:52 PM, Nitay Argov <Nitay@gilat.com> wrote:
> 
> 
> Thanks!!
> I will study the suggested resources.
>  
> From: Kuhn Nicolas [mailto:Nicolas.Kuhn@cnes.fr] 
> Sent: יום ד 13 מאי 2020 09:45
> To: Nitay Argov <Nitay@gilat.com>; etosat@ietf.org
> Subject: RE: Packet lost on last mile network?
>  
> Hi,
>  
> IMHO, you are not missing much, there is an issue when you have a lossy end-user delivery network (unless QUIC supports an unreliable transmission).
> Moreover, you may also have congestion losses in the aggregation network of the satellite system.
> To consider this issue, we have proposed a specific use-case in the QUIC4SAT draft : https://tools.ietf.org/html/draft-kuhn-quic-4-sat-04
> There are multiple ways of solving this issue: adding coding in QUIC (draft-swett-nwcrg-coding-for-quic-04), enabling local retransmissions (e.g. with MASQUE approach) or having an “aggressive” congestion control that ignore loss as a congestion signal, etc.
> There are also some IETF presentations on this issue:
> https://datatracker.ietf.org/meeting/105/materials/slides-105-panrg-quic-over-in-sequence-paths-with-different-characteristics-00
> https://datatracker.ietf.org/meeting/105/materials/slides-105-panrg-quic-over-satellite-00
>  
> I hope this helps,
>  
> Nico
>  
> De : EToSat <etosat-bounces@ietf.org> De la part de Nitay Argov
> Envoyé : mercredi 13 mai 2020 05:28
> À : etosat@ietf.org
> Objet : [EToSat] Packet lost on last mile network?
>  
> Hi,
> I'm looking for discussions on issues related to a satellite network that is used with a lossy end-user delivery network – e.g. WiFi. As far as I understand, once QUIC is used, any packet drop by the user network will need to be retransmitted over the satellite? Doesn't this pose a real problem for using QUIC over such networks?
> Am I missing something? I am sure this issue was discussed in the past but I could not find where.
> Thanks!
> IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person.
> IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person. _______________________________________________
> EToSat mailing list
> EToSat@ietf.org
> https://www.ietf.org/mailman/listinfo/etosat