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

Christian Huitema <huitema@huitema.net> Wed, 20 May 2020 19:14 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 542363A0AF5 for <etosat@ietfa.amsl.com>; Wed, 20 May 2020 12:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L5=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 rDPl-Ff5ZRgr for <etosat@ietfa.amsl.com>; Wed, 20 May 2020 12:14:22 -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 4A49A3A0AE7 for <etosat@ietf.org>; Wed, 20 May 2020 12:14:22 -0700 (PDT)
Received: from xse501.mail2web.com ([66.113.197.247] helo=xse.mail2web.com) by mx147.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jbTCa-000mKj-RY for etosat@ietf.org; Wed, 20 May 2020 20:13:25 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49S14J4ytFz4NYF for <etosat@ietf.org>; Wed, 20 May 2020 11:09:52 -0700 (PDT)
Received: from [10.5.2.13] (helo=xmail03.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 1jbTA8-0007Nr-IJ for etosat@ietf.org; Wed, 20 May 2020 11:09:52 -0700
Received: (qmail 5947 invoked from network); 20 May 2020 18:09:52 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.109]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <etosat@ietf.org>; 20 May 2020 18:09:52 -0000
To: Carsten Bormann <cabo@tzi.org>
Cc: Nitay Argov <Nitay@gilat.com>, Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>, "etosat@ietf.org" <etosat@ietf.org>
References: <HE1PR0702MB37550F63AB9CDD4FD637CC3EA9BF0@HE1PR0702MB3755.eurprd07.prod.outlook.com> <7C07C17B-2A81-4B8A-94E2-87858A5FDDC2@huitema.net> <D369D911-6F31-42D5-844E-7C597EC74CB0@tzi.org> <7ab5eb1c-afc9-0198-2d50-8bccd4872a41@huitema.net> <13D10772-5139-439E-9527-8D72205F0E47@tzi.org>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <3e61ab01-13de-9742-e058-8e552828f582@huitema.net>
Date: Wed, 20 May 2020 11:09:51 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <13D10772-5139-439E-9527-8D72205F0E47@tzi.org>
Content-Type: multipart/alternative; boundary="------------A21D37A175A1B36A0CE919A1"
Content-Language: en-US
X-Originating-IP: 66.113.197.247
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.65)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0etK79GjTETSC9a1ypZ8nc2pSDasLI4SayDByyq9LIhVdV7VIjDQTNRs k2MPCnFTJ0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDYbC1vFNC/qFxauDStI0QV8RX qYbtEQV1z/L435ZRxFRcxZCQkPj3KP5INz8xpH9R+rYZvu7UEJiU3s27VgKHO7lwS3dBJTnTxDoD vBGGxph9w6EwXICYy0ePXtGEMhqr9I4+l5b13gm+zHVNr3UD/2U6UgOqKJ9sMwhVoOBGSAIboXtx P9OF0EfNs5TqNq2Yhy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8ZL5jehbcgzc3iNCEP65/DGMwnNorvknifMrY7upaQn6/5yQ6Z8yNvfGXSV8zy1Gwov UwPy3x0FYtCNEb10sHyQCLHEvD1OqP6bgZ4L66GcgBg66gs5OuzYxJgw5atIxeNDvjI/CYe5WPy0 +t1RP0azSVvTCZhMLWdvzE+7ddVkYpxMPnetLBJMh51NiRRoHICd0q/sJZ0xuLuN6KBgE7MlmiK7 x42VjdzChZMe6O/Did+/hGXTmfhE+Dx2/NyzMXr+JSmItNAYP9X/5BJRdoKFvOnCUbNPgcPcQwzM gKHyQxUo+ql2ySTkvEFH/23XMww2BnTTFGX5/yI4Ky+1ZJcbGqc5H4PEZHeoI/d6LWFf332z7LMw LGdoi9FMQ5j9dQUvMi1YKAun15JQSJLyCT5k+MTObVKxHy/dols381l9r9ft9daDonlwd6LnuX+J u10=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/05glaWK4KMQu1mdKIOyL346NyaU>
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, 20 May 2020 19:14:24 -0000

On 5/20/2020 9:56 AM, Carsten Bormann wrote:
>> And, if they are only deployed in a
>> fraction of the Wi-Fi network, then the transport folks will still need
>> an end-to-end solution.
> They sure will.  But that never can be as good as local recovery.

In a nutshell, that's the entire discussion of end-to-end vs middle-boxes.

It is always possible to do a local optimization by adding some
intelligence in the network. That's the case for pretty much all middle
boxes, and it seems that the proxies envisaged in Loop fall into that
category. But there are always downsides, such as management,
flexibility, and most importantly ossification by old proxies prone to
bit rot.

Given effort, it is almost always possible to find end-to-end solutions
that are "good enough", getting you within 90% of the optimum or some
such. FEC as tail probe would be one example of that. The end-to-end
solutions also tend to get better over time, as implementers devise more
clever algorithms and update the code. All it takes is some motivation
that the effort is important.

An example of that would be support for cellular networks. Twenty years
ago, this was a niche, and TCP was not optimized for it. Hence the
deployment of middle-boxes in the cellular networks. But as this became
an ever more important scenario, TCP improved, and QUIC will improve
over that. The cellular middle-boxes become harder to justify, and will
start moving from the "optimization" to the "hindrance" category.

Satellite networks are a peculiar case. They remain very much a niche
application to this day, something like a communication media of last
resort in places that fiber or cellular cannot reach. Given the niche
status, it is unclear whether end-to-end transports will bother
implementing optimized algorithms, even when these are available. But it
is also unclear whether "mainline" networks will bother deploying
middle-boxes solely for the benefit of the satellite niche, which kinds
of rules out solutions like 'deploy a box in every Wi-Fi network'.
'Deploy a proxy at the ground station' might work, because the satellite
operator has the right business incentives, but of course that requires
nodes to still do something special for satellites, i.e., discover the
proxy and use it. Not obvious.

Hence my effort to look at end-to-end solutions covering not just the
satellite case, but also other long distance networks such as
intercontinental connections. These are still niches today, given VPN,
but they are still useful for P2P applications. Given enough niches,
there might be enough motivation for doing the effort.

-- Christian Huitema