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

ianswett <> Wed, 12 February 2020 15:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DFCE1200E7 for <>; Wed, 12 Feb 2020 07:14:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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 dcf2OHSWYzOq for <>; Wed, 12 Feb 2020 07:14:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66E641200A3 for <>; Wed, 12 Feb 2020 07:14:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DD0C09604FE for <>; Wed, 12 Feb 2020 07:14:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581520454; bh=1np4ULmxQbnA8eyWHRdZmINMKpCkD+Vy6DTV6+os11A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=AYG9xHgaOXGrm0QLbMGiDNl5KrF4plVsAPTCqObpQeXR5MfBVxwTyuusDcW/f/j3n fZIQ1xzo0ldEDujuS7Jhp1M1wqSs2PiJw2JUeUenqVr2uT2LTLigkwBn56h8lOMI3k nMckBRXTXPa88eE4cQl7spsBQU+7StQfZ1OofaHc=
Date: Wed, 12 Feb 2020 07:14:14 -0800
From: ianswett <>
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_5e441646cec3f_38563fd9236cd96468437"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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:14:18 -0000

I'd prefer to keep this as is, because I think ensuring everything works correctly with an updated design is going to be a bit complex and potentially error prone, and I don't see any value in the change.

For example, when an ACK is lost, if the CWND is reduced, that doesn't reduce the rate of ACKs, it just reduces the rate of sending future data.  Because ACKs do not count towards bytes in flight, the congestion window would never increase if a peer is only sending ACKs, so we'd be putting peers in a situation that the CWND could decrease, but never increase.  That alone seems sub-optimal.

FWIW, I do believe we discussed this at length a few years ago and ended up where we did because of (at least) three points:
1) ACKs are not required to be acknowledged, even once.
2) This is very similar to what TCP does.
3) Congestion controlling ACKs is a research topic.

@martinthomson We track lost packets for a while in case they were declared lost too early, so the existing design is quite natural and a bit simpler.

If in QUICv2/etc we think it's worth making ACK-only packets congestion controlled and count towards bytes in flight, I think that would be a more holistically appealing design.  I also think it's quite a bit of work and research to get right.

But I do think we should make this point a bit clearer in recovery and articulate why this choice was made.

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