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

Kazuho Oku <> Wed, 12 February 2020 05:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE7311200E3 for <>; Tue, 11 Feb 2020 21:34:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 ja7DpHKFhxbP for <>; Tue, 11 Feb 2020 21:33:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11DBC12022C for <>; Tue, 11 Feb 2020 21:33:59 -0800 (PST)
Date: Tue, 11 Feb 2020 21:33:57 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581485637; bh=P/YFf58I5YMfLnPVQGNxUbihBXSOtoqboedNoUtXzus=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0VlzVlsRG7fDVlq1y8AtZgCqpIcoIeRSoJgNCoLJpvTsvVpOCVw5k2qOW2Dmr0aj0 o4iHDl4dmr97iT85aeVVxl56wcDYRq40BkzPYBVJpalnI/bOkLMo+oh7pFIkzEmAzt NrVDdwaxlKNUjXnbMxUgEtAF3V8nK+3E8t5Sj6gY=
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_5e438e45b7907_5dec3f8fa98cd96c1597d6"; 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 05:34:03 -0000

Let my paraphrase.

> There's a simpler one: if sending packets causes congestion such that loss (or ECN-CE marking) occurs, then ignoring that signal means that you will likely create more congestion.

Are you arguing that an endpoint SHOULD throttle the rate in which it sends ACK-only packets, when some of those ACK-only packets are being lost?

I would assume that your answer is no, and that is because send-rate of ACKs are not controlled by the endpoint. It is controlled by the peer that is sending data.

Up until now, CC is per-direction. An endpoint sends data at a rate controlled by ACKs sent by peer in response. The other side does the same thing, individually.

While I do not dispute the fact that *ideally* we should take the loss of ACK-only packets into consideration, my argument is that we are not at that point (yet), because we do not control the send-rate of ACK-only packets.

Using the loss of ACK-only packets without controlling the send-rate of ACK-only packets based on their loss essentially means that we are going to prioritize emission of ACKs above data. This would be a departure from the per-direction CC design that we have now.

As I stated in my previous comment, I am concerned about the negative impacts that the change in design might cause.

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