Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)

ianswett <> Tue, 24 March 2020 12:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB70C3A0952 for <>; Tue, 24 Mar 2020 05:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Status: No, score=-1.554 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_20=1.546, 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 p4htIlQ5_QLM for <>; Tue, 24 Mar 2020 05:44:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D79153A094C for <>; Tue, 24 Mar 2020 05:44:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EB7A4520854 for <>; Tue, 24 Mar 2020 05:44:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585053890; bh=V74ch5XZX9NoZiRGyli6pN89b/T3tzrJlWQdWP1v9vI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=jmp8KPDAs2jfGgPsRT/rfcYaVxenNTdYvhBzXFGXWqAr+ZlpHQ6XU/cMppjBe5TIA ZjxBThA4Djl5FGMmCJxpbJTGxQqcZAgP6o5TxmsV2cXg6AVTBvfD0B3wpVjp/qEUiR 4bPoj7wc94erEEkJGELEEvKcibC8CiaRdy2MUbQc=
Date: Tue, 24 Mar 2020 05:44:50 -0700
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3529/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e7a00c2db217_1e673f97ca8cd95c1156f4"; 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: Tue, 24 Mar 2020 12:44:54 -0000

So the min TCP ack is 40 bytes vs QUIC at 50(0 byte CIDs are common, so I'll assume that), 25% larger in the minimum case.

However, with a few SACK blocks, TCP ACKs are likely to be larger than QUIC ACKs, since SACK consumes 10 bytes for the first block and 8 for each additional block.  By the time the second block is added, there's a good chance QUIC ACKs are smaller and it's almost certainly true with 3 SACK blocks(which I think is a typical number).

So I'll go back to my previous statement that the real issue is that the network can't thin QUIC ACKs effectively.

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