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

Igor Lubashev <> Fri, 21 February 2020 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3162120058 for <>; Fri, 21 Feb 2020 10:14:16 -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 Jnfg4J9Cpnpc for <>; Fri, 21 Feb 2020 10:14:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C528B120018 for <>; Fri, 21 Feb 2020 10:14:14 -0800 (PST)
Date: Fri, 21 Feb 2020 10:14:13 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1582308853; bh=tYFxkhQe4sxMMv/hdPvBPaHMA8vQk5zxYu6fAkjemAE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=W6FbwOMsH95+KIRWRWtrdp138LGHAhnngI97KobElT3bKGnvGzivgfklEIZ2glwBF ck7CCkwmHm48uvn+M42YWjME7wQDAIuruEppIX52iVQnPH3NoNCWlpEYtVLWXqdmYz 4QSfUQGgvxErgcKK2QWD+dbnjnquZqHQ7kgUwETU=
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_5e501df5ced54_7e753fdf3f0cd95c275d1"; 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: Fri, 21 Feb 2020 18:14:17 -0000

@mikkelfj, @ianswett Thanks, the SHOULD in "Section "13.2.1. Sending ACK Frames" being a SHOULD due to connection termination makes sense, but it would benefit for being explicit that it is the only case when packets may never get ACKed.

@ianswett Some implementations might not care about loss of ACK-only packets, while others may care about such losses. For the latter ones, knowing of such losses is as required for correct functioning as knowing of loss of packets with DATAGRAMs (what bytes count toward a congestion window is not the only implementation concern).

I do not think that there is any burden on even the simplest implementation. If the simplest implementation detects a gap, it can send a packet with an ACK. If that gap was detected due to a receipt of an non-ack-eliciting packet, a PING frame could be included with the resulting ACK (to satisfy "_An endpoint MUST NOT send a non-ack-eliciting packet in response to a non-ack-eliciting packet, even if there are packet gaps which precede the received packet._"

The bottom line is that building in a "loss ambiguity" into the protocol without a great reason is a mistake. TCP has a retransmission ambiguity, and we know it is a problem.

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