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

ianswett <> Thu, 02 January 2020 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F86B120813 for <>; Thu, 2 Jan 2020 13:08:14 -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 usmLVPGswf0B for <>; Thu, 2 Jan 2020 13:08:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A1B5120220 for <>; Thu, 2 Jan 2020 13:08:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 667E11C2EEE for <>; Thu, 2 Jan 2020 13:08:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1577999292; bh=n6XFirnZbbDHZ9PiYFekwTaU5j3XP4fnVshD1zpLy00=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=PkXTtDFvXwRpnoU9EVziZ/N2ZBjyCvqGzemeDz1L44KjEUJZYEYyF7claI9DW5Mkr PDA6xX35PAWw+u5gFN68QynoTQBYx63SPM4sQZRaf6JL+cR/BvvwimZpKBjKavtTu3 Cm70bZbAs9hC7fVpf6ZN7vRPs4j/yHkbex06dG1g=
Date: Thu, 02 Jan 2020 13:08:12 -0800
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3312/>
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_5e0e5bbc55719_305a3f9f806cd96472234"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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, 02 Jan 2020 21:08:18 -0000

@janaiyengar In terms of which is the right section, I'll explain my thinking.

In my mind, I think of the subsequent two sections as examples of how one could limit ACK frame size, but not really required reading, because I think that's how they were originally written?  However, there's quite a bit of normative text in there, so maybe I have an obsolete mental model.

An easy alternative to doing what's in those sections is to set a max number of ACK ranges(ie: 3), which I think should be considered acceptable, even if it might not be optimal.

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