Re: [quicwg/base-drafts] ACK generation recommendation (#3304)

Christian Huitema <> Mon, 23 December 2019 01:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A79A120048 for <>; Sun, 22 Dec 2019 17:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B1Wxr9-Ng2ni for <>; Sun, 22 Dec 2019 17:54:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 282DD120026 for <>; Sun, 22 Dec 2019 17:54:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4F8AF1C0AB5 for <>; Sun, 22 Dec 2019 17:54:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1577066051; bh=qyEeAV3Z1mVev3AXEeM8FOYibIjcFdH/ozzxlKq5ZKU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=w9AC18kcZ3Ijc37KZ9lBdFg6kJ4V2fJLT6T80tmODJ5vuf05POfMT/an4X1/GAaCD Js9xTR6WRzwdxkp6yzBRGtEdBBNz1P2cDfjw9p9zo7ke2x7iQMdNbcfW0EwnRvgLeU kE0CpWC3iHMn5JwJHhybQmcFvKgTmknk3kXHM2WY=
Date: Sun, 22 Dec 2019 17:54:11 -0800
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3304/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] ACK generation recommendation (#3304)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e001e433fb38_439e3f8c75ccd9682604d4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Dec 2019 01:54:14 -0000

I have been experimenting with various ACK reduction schemes in picoquic, larely as part of experimentation with satellite link. There are two distinct motivations: CPU reduction, and asymmetric links in which the return path is much narrower than the data path.

In the asymmetric scenario, acking every two packets leads to a lot queuing and losses on the return path. The end to end delay becomes very large, and the default congestion controller becomes very confused. In these paths, ack reduction is essential. The right thing to do is probably to write control loop that increases the ACK interval when detecting ACK congestion. I have not written that yet, and did something simpler: just go to interval=10 when the delay is long and the bandwidth is high enough.

The actual algorithm in Picoquic is:
if more than 128 packets received:
    if rtt_min > 100ms and receive_rate > 10MB/s:
        ack_gap = 10
    else if no_holes_detected
        ack_gap = 4
else if FIN received on last active stream:
The max_ack_delay is set to:
    max( 1ms, min(25ms, RTT/4))

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: