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

MikkelFJ <> Fri, 21 February 2020 13:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B0FB120106 for <>; Fri, 21 Feb 2020 05:17:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Status: No, score=-6.382 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_24=1.618, 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 hyRRgbGrRb51 for <>; Fri, 21 Feb 2020 05:17:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A257612004A for <>; Fri, 21 Feb 2020 05:17:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 92371280D29 for <>; Fri, 21 Feb 2020 05:17:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1582291042; bh=EPjJIfd8C0anPMEGUcc2XULj3urQcaXzCjqrMrmzpgw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=auCEHK8WPirn2pE9IGyO+5RFRvgzcjUUDm8+NUCwec3LQLPefpX+Q3hNejZXMkpJH z2HalSV0FDRivgdZi3/Ayy+K3FQih0fcR8x+YB3efwLdslZjD1UfF3+RTDqGz2CU+6 6wKfGU3TtPt5inTQ2MMB8CoL11v5yes7R08CJTdk=
Date: Fri, 21 Feb 2020 05:17:22 -0800
From: MikkelFJ <>
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_5e4fd8628299b_7b773ff0dc4cd968292279"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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 13:17:26 -0000

@igorlord I'm not sure there is a contradiction here. You want to acknowledge all packets eventually because as you say, it is odd to have to bypass an ACK frame. But you don't want certain frames to actively initiate ACKS. I think this is covered in the three sentences that you quote.

The odd special case is when the connection terminates. What if there are pending ACKs that you don't want to acknowledge?

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