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

Igor Lubashev <> Sun, 16 February 2020 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFE69120033 for <>; Sun, 16 Feb 2020 11:43:59 -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 zShNPaMgAO4g for <>; Sun, 16 Feb 2020 11:43:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF0F412001B for <>; Sun, 16 Feb 2020 11:43:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DC43C6E054B for <>; Sun, 16 Feb 2020 11:43:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581882236; bh=ftClnx1U4o6ZLYanNPdnREIYssDEgBs40nRf96fClYA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NOIfxVzDOdEM2p5NoowmrCyt476xkpeHbq6tZWPP5mYKIQWn697BIsnG4tuNcDqBh RBoif8P1qvFZgaJ5OB8rA2Jh+in3twfI2tTbtvGKZW4B27JcMDn6e/7JaKJHyG2Sue xc4N8/MCoJX3Jq5Zmr72pN3VM5iZKqrFArhtkyj4=
Date: Sun, 16 Feb 2020 11:43:56 -0800
From: Igor Lubashev <>
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_5e499b7ccbf2d_2f9b3f89156cd968446244"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: igorlord
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: Sun, 16 Feb 2020 19:44:00 -0000

The text is slightly ambiguous on the topic of whether pure-ACK packets are to be acknowledged.

Section "13.2.  Generating Acknowledgements" implies that they are ACKed later:

> Packets that are not ack-eliciting are only acknowledged when an ACK frame is sent for other reasons.

Section "13.2.1.  Sending ACK Frames" implies that they SHOULD but not MUST be ACKed:

> Every packet SHOULD be acknowledged at least once


> [all] packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header SHOULD be acknowledged immediately

It seems strange NOT to acknowledge all packets when sending an ACK frame. What benefit is there to NOT doing so? And if there is no benefit, why not require the protocol implementations to be more predictable?

What specific response a specific congestion controller has as a reaction to a lost / EC-marked pure-ACK packet is an implementation matter, of course.

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