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

Kazuho Oku <> Wed, 12 February 2020 13:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBACF1200F8 for <>; Wed, 12 Feb 2020 05:27:53 -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 w1GmnBEls7lq for <>; Wed, 12 Feb 2020 05:27:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D083E120106 for <>; Wed, 12 Feb 2020 05:27:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ADC54A049A for <>; Wed, 12 Feb 2020 05:27:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581514070; bh=XEg9B/mtYL2O20tkrR7I8M7jyraI3Wmhn8YweP/R/Go=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Ve9XD/FR0iany+gvYx+3JDwq0ykjrA8bcuLGoGX84fEPHmA4LZzhgkwwN76bJ9QnX skUYi4I/0l7MmoC1zzMkui9fU5P5Lg7qE/8aJ2DqF/J460p71jCYlO09hPzny7UZ8E egGXkv34LDYcelIBgqr4ykAvXvXljHQJQiTOpEWo=
Date: Wed, 12 Feb 2020 05:27:50 -0800
From: Kazuho Oku <>
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_5e43fd569d8de_70853fe770ecd96026628"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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 13:27:54 -0000

> @marten-seemann is right. You don't allow ACK-only packets to be limited by the congestion controller. I believe that don't is "can't" in practice.


> And we should prioritize acknowledgements over data. There's a point where you can't do anything but ACK, but that's the case no matter what we decide here.
> All I'm saying is that loss of an ACK-only packet is a signal that we are being encouraged to ignore right now, for no good reason.

Yeah. I might agree that there is "no good reason" to agree. But my argument is that simply saying that an endpoint MAY take loss of ACK-only packets into consideration does not fix the problem.

Please correct me if I am wrong, but CC is designed as a feedback loop between send-rate adjustment and loss observation. Including loss of ACK-only packets to the latter, without adjusting the send-rate of ACK-only packets is going to change the equation.

Let's consider an example. Consider the case of a satellite link that has 1000ms RTT, 1Mb/s downstream bandwidth. When the downstream path is fully utilized, there would be ~100 downstream packets per second (or per RTT), which means that there would be ~50 ACKs being sent to upstream.

Let's assume that the loss rate of packets sent to upstream is 2%, regardless of the packet size. Under the status quo, CWND to upstream would be ~8 packets, because on average one loss would be observed per every 50 ACK-eliciting packets being sent. However, if we are to take into consideration the loss of ACK-only packets, the outcome would be that packet loss would be observed at a probability of 70% for each RTT. I think that would lead us to a CWND size of 2 packets or below.

One might argue that the loss rate is actually proportional to the size of packets, rather than the number of packets. So let's assume that the size of an ACK-only packet is typically 100 bytes. That does move a needle a bit, but I think the problem still exists. Assume that MTU is 1400 bytes, loss rate being 10% / MTU, ACK-eliciting packet are always full-sized, and that ACK-only packets are 50 bytes long. In status quo, I think that CWND would be somewhere between 2 MTU to 3 MTU (because the loss rate is 10% / MTU). But once we take the loss of ACK-only packets into consideration, the observed loss rate per RTT becomes 1.5x~2x, because the amount of data being sent per RTT increases by 50*50=2500 bytes. That would lead to a noticeable reduction of CWND size.

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