Re: [quicwg/base-drafts] Should we allow ACK-only packets to be declared lost? (#3451)

mirjak <> Wed, 12 February 2020 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5BB31200F8 for <>; Wed, 12 Feb 2020 07:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.682
X-Spam-Status: No, score=-3.682 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_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, 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 Vy1qwyhcSMxv for <>; Wed, 12 Feb 2020 07:43:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47B4B1200E7 for <>; Wed, 12 Feb 2020 07:43:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 302558C0037 for <>; Wed, 12 Feb 2020 07:42:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581522179; bh=kN9/MopwicGnXLlG4zdPEnbF4LzvzEhTiNzFUETKydU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ATEv2mG2/X1O/ajwG1z+czRuAo3evkZhxlR5MQTN2EchWoUxx+ZyY33AwQZ6eMJt/ oKtuj/CXCShZnQfBVbJo3AgoBF4q+h2bdEDhbcdMuu2WwT1dnwk2cSeUq45HW38wg/ rjokv/WFlaDxBrRjqEi0IiBN5dsQCYXHVoR4Csog=
Date: Wed, 12 Feb 2020 07:42:59 -0800
From: mirjak <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3451/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Should we allow ACK-only packets to be declared lost? (#3451)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e441d0321257_4ad53fd6c5ccd964292515"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mirjak
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: Wed, 12 Feb 2020 15:43:03 -0000

I agree with Martin, there is no reason to ignore loss of ACKs as a signal. What you do with this information is a different question. There have been proposals for "ACK congestion control" in the past which basically means that you may adjust your ACK rate (e.g. if you send an ACK for every second packet you could easily reduce that rate if possible by your indicated max ack delay). I'm not saying we should specify any "ACK congestion control" but we should definitely make it possible to enable future experimentation on this.

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