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

Jana Iyengar <> Wed, 12 February 2020 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73126120041 for <>; Wed, 12 Feb 2020 15:54:39 -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 s7EYsu_DlGqq for <>; Wed, 12 Feb 2020 15:54:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A44512002F for <>; Wed, 12 Feb 2020 15:54:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8D64352002D for <>; Wed, 12 Feb 2020 15:54:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581551676; bh=aTf/XTdQUo+ycRoHWKkJf629VvGLRHbA4RlKlSDBpRY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=x8vJtLZY2RYrCpbJoUnHdrd85QnmKs3hxQ8ySKF46hVHwBlS4QhFQ0jucXwHYXtSg ebCJdXFf3ZErC+5KxIDjusU+3dQWkqwlxnlGSZg+KWY5DVGdL1mi4OMi2ZZg3j11tb W4SHHGiOKuz4VSUnoGkHsMcASVoHBnxBXOMq6jxE=
Date: Wed, 12 Feb 2020 15:54:36 -0800
From: Jana Iyengar <>
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_5e44903c7d8b4_552d3faf188cd960767e6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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 23:54:39 -0000

Thank you, @kazuho, for raising a point that I had completely forgotten! I remember now why I had not wanted ACK loss to drive the congestion controller. I think @kazuho and @ianswett are saying similar things, but the short of it is this: the congestion controller assumes that cwnd amount of data is in flight when it reacts to loss, reducing the cwnd. However, the cwnd has nothing to do with the amount of ACKs that are in flight, and as a result, the reduction of the cwnd in response makes no sense in this case.

(It does make an increasing amount of sense to use as the traffic in this direction is increasingly dominated by ack-eliciting data, but that also makes it increasingly likely that a congestive loss will be of an ack-eliciting packet.)

We should not change the design here. I'm fine with @ianswett's proposed addition, but I don't think we should use the loss of ACKs as a congestion signal that affects the congestion window.

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