IETF Logo Mail Archive

Re: [EToSat] FW: picoquic ACK Tuning

Christian Huitema <huitema@huitema.net> Wed, 14 December 2022 01:40 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 1A099C14CE30 for <etosat@ietfa.amsl.com>; Tue, 13 Dec 2022 17:40:34 -0800 (PST)
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, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9NqMmdQ7Apb for <etosat@ietfa.amsl.com>; Tue, 13 Dec 2022 17:40:30 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A836C14CF0C for <etosat@ietf.org>; Tue, 13 Dec 2022 17:40:30 -0800 (PST)
Received: from xse441.mail2web.com ([66.113.197.187] helo=xse.mail2web.com) by mx281.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1p5Gkx-000Nje-MS for etosat@ietf.org; Wed, 14 Dec 2022 02:40:26 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4NWyjb36vCz8kt for <etosat@ietf.org>; Tue, 13 Dec 2022 17:40:19 -0800 (PST)
Received: from [10.5.2.49] (helo=xmail11.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 1p5Gkt-0000iI-94 for etosat@ietf.org; Tue, 13 Dec 2022 17:40:19 -0800
Received: (qmail 23510 invoked from network); 14 Dec 2022 01:40:18 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.46.249]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <John.Border=40hughes.com@dmarc.ietf.org>; 14 Dec 2022 01:40:17 -0000
Message-ID: <55209c55-7271-ab9a-ec2f-4e30aad6b6fe@huitema.net>
Date: Tue, 13 Dec 2022 17:40:17 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1
Content-Language: en-US
To: "Border, John" <John.Border=40hughes.com@dmarc.ietf.org>, "EToSat@ietf.org" <etosat@ietf.org>
References: <MN2PR11MB3647FF3FA8E4A3D2B59932E590E39@MN2PR11MB3647.namprd11.prod.outlook.com> <c89502ab-686d-82fa-c5ee-2af1f5d50fa3@huitema.net> <MN2PR11MB36472D158CBB05DA0D645FE790E39@MN2PR11MB3647.namprd11.prod.outlook.com>
From: Christian Huitema <huitema@huitema.net>
In-Reply-To: <MN2PR11MB36472D158CBB05DA0D645FE790E39@MN2PR11MB3647.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: 66.113.197.187
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: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zGFFoTDPM8FUgarAdxxdv742UuDhyzVYcwl2RB+0Aaejr3 jtKr/815LkMgRcIp2U4h55uqY3MhMgFAHq5BxPxPXn36fLqvhISQ5ykyqUZqUd1jhnM/Mbva2XLV /LIEzaL2KoAZhJekBPedneT7f699uvtHXBBpVLPPnzBhUeiMwYPAgTtUp75uqlx0KezvZHV29smA 2hkwfsDYG4PV2gV9WQaaSSaRcFTFxaRvADgOuFdAU5fRzM/QzQW9/IoH33AG8ECuCwECazCwODtO F78PiyQEs+dlGXUJLWZ+Gc08Nmllke3azHdKmySKNUVQl4ntlVxnbS8qIO7oudHyb2T1VQ58xe/l rqiRGalI3YPsxOTrFXToVyBmRCgQVX6zVyFUu8qzeMQP6uTHL0d9UjfYgBBNGjSbbSRA1Z+Pmb5M C1YFvf25LVONYbYifH5OzZDcG6hsRQZiAIgw+z837AqgX7ewI8e1h7RITgN14BHmGVt/ReJ9Mfhz zmbKTH7wI9GEU1utNskUAORCV2WFZX0jsSNp9M7ieETeL5bKSNOUm6KwUNnrAyVw6c2CMHU/u+8Z DyovJAIWvUFlDjxc8i4YEnFzsC48bTEFY06/YbB87Ww8G0LoS8V3Mt1pta8qAcLtCB3G1CwpaI3Z 4ESkMWDVJEenxBoIht3V0nekAoxXAtWiLPuEysUIrRH8WsXN2pGyuLfHqAnAj7rgKH7+eCmmvAds i+ucwRQidG95puyHQVShcA6Xvva2QAVEjpqzANbJ1UfXmet2cbFKoyT/OdZLbdiDt8nCM/LirEzG Y7ETam0AuXq0T17woJo3avKeADIsy647Mn0zwmGzAi3Zn+YdthRNgs7Ig4l/XErpYn3glZTKFuaT l19W3ISq9+1KiLsESGU+y+fjdgjudZxiTPi+MG1QP35nsYfP84c+RFK3KiZuZ5OAUoGBziSYFLZu u6zX3xxsmqT8l9ARlsTalAaf
X-Report-Abuse-To: spam@quarantine14.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/Z0T1Jcac_JGaLHV_Rzpg7IXgqz4>
Subject: Re: [EToSat] FW: picoquic ACK Tuning
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.39
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, 14 Dec 2022 01:40:34 -0000


On 12/13/2022 1:57 PM, Border, John wrote:
> 
> 
> -----Original Message-----
> From: Christian Huitema <huitema@huitema.net>
> Sent: Tuesday, December 13, 2022 11:29 AM
> To: Border, John <John.Border@hughes.com>
> Subject: Re: picoquic ACK Tuning
> 
> **EXTERNAL EMAIL**
> 
> 
> 
> On 12/13/2022 8:17 AM, Border, John wrote:
>>
>> Christian,
>>
>>       You did a lot of ACK rate tuning work in picoquic as part of getting good performance results  over GEO.  Is this captured in an I-D somewhere or do I need to just  look at the code?
> 
> I don't think I wrote it down, except maybe in emails. I could certainly write a blog. The basic algorithm is expressed in the ACK rate computation in the code, which feeds in the standard "delayed ACK" logic of QUIC. But that code contains a few magic numbers, and these are worth an explanation.
> 
> The most complicated part happens when doing that with multipath, and allowing acks to be sent on a variety of path. It is more efficient overall, but brings in a lot of complexity. You don't need it in most setups.

This morning, John asked me whether the ACK strategy implemented in 
Picoquic was written down somewhere. It was not, but now it is: 
https://www.privateoctopus.com/2022/12/13/managing-quic-acks-in-picoquic.html.

Thanks for the prompt, John.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email