Re: [quicwg/base-drafts] What if an ACK frame doesn't fit in a packet (#3312)

MikkelFJ <> Thu, 12 March 2020 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79ED83A0437 for <>; Thu, 12 Mar 2020 05:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Status: No, score=-1.482 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 uIzivyJSfHeD for <>; Thu, 12 Mar 2020 05:59:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B7193A041D for <>; Thu, 12 Mar 2020 05:59:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 31F766E130F for <>; Thu, 12 Mar 2020 05:59:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1584017946; bh=LcBSsWozcUxjQMP4c+Q1ekPI3QiEqn3BqE75W6G5cAc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=TMkYDfUeBpwsPyoXxIz7XPGCkBmjS/7GSNkV7NSkrfo80Qd5OKO0OFgqQNT3JZ0nx 92FLL7bB9WwVL7jnJbov9Khjrrr7Epdwb1OgZyDdrsOKay6PFYMJzI0/CVzWPNWuFZ LTb1lXy5+v4K7e0qjqKbrg3zvj1zMkv7+f/9IVXM=
Date: Thu, 12 Mar 2020 05:59:06 -0700
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3312/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] What if an ACK frame doesn't fit in a packet (#3312)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e6a321a23881_591a3fd6c4ecd9686825c"; 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: Thu, 12 Mar 2020 12:59:08 -0000

mikkelfj commented on this pull request.

> @@ -3182,7 +3182,9 @@ caused by losing previously sent ACK frames, at the cost of larger ACK frames.
 ACK frames SHOULD always acknowledge the most recently received packets, and the
 more out-of-order the packets are, the more important it is to send an updated
 ACK frame quickly, to prevent the peer from declaring a packet as lost and
-spuriously retransmitting the frames it contains.
+spuriously retransmitting the frames it contains.  An ACK frame is expected
+to fit within a single QUIC packet.  If it does not, then older ranges
+(those with the smallest packet numbers) are omitted.

"are omitted" is vague. Does this mean a receiver can conclude non-receipt of any packet number higher than the oldest in an ACK frame. If so, the wording probably should be "MUST be omitted".

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