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

IngJohEricsson <> Mon, 04 May 2020 06:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 221D33A0C37 for <>; Sun, 3 May 2020 23:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Status: No, score=-3.1 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RJ5xZw2Tc4jr for <>; Sun, 3 May 2020 23:49:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63B313A0C3D for <>; Sun, 3 May 2020 23:49:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E15F7521EED for <>; Sun, 3 May 2020 23:49:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1588574967; bh=sLTic9Wzs/nbDVMx70ixuN5v8r4WmtIsfkwdP3HbTWY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=f2MNosAY+fksnm+GlyJLTcUnJuRK7D4aX5peO2F9rLfOPe24g+bg7JGZK43PfIu6M Mr6VxH8KPKoCcHId+ffsM5E6aFxEt3rrojVPSeqZZRg/zqBM8NAc6d17aiNAiX5SFO Igg3UWx5dDImXYOC8j5v7TV7rcui1ZacSE5Al1+w=
Date: Sun, 03 May 2020 23:49:27 -0700
From: IngJohEricsson <>
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_5eafbaf7d13b5_5d3e3fca74acd9642727ba"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: IngJohEricsson
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: Mon, 04 May 2020 06:49:32 -0000



Need to admit that I have not had too much time to follow the QUIC work lately. 


I too believe that draft-iyengar-quic-delayed-ack-00 is a good long term solution that allows endpoint to set a desired ACK frequency that is not more than necessary. As experiments show there are good incentives to keep the ACK frequency as low as possible in terms of client/server load and asymmetric links limitations. An ACK-FREQUENCY frame  will allow to find the proper balance between the requirements given by the congestion control, the traffic type and the above given limitations.

I am not too concerned if it takes an extra development/standards cycle to have that in place in the standard and in running code as long as the QUIC community shows other SDOs that the challenge with QUIC ACKs is being addressed. 




From: Bob Briscoe <> 
Sent: den 2 maj 2020 18:50
To: quicwg/base-drafts <>
Cc: Ingemar Johansson S <>; Comment <>
Subject: Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)


I'm greatly in favour of draft-iyengar-quic-delayed-ack-00 (BTW, where would you prefer me to give review comments about that?)

I am much less keen on any default delayed ACK policy, whether 1:2 as now in quic-transport, or the 2-10/100 numbers proposed in draft-fairhurst-quic-ack-scaling-02

My concerns would melt away if the default policy was explicitly /implementation-dependent/ and the draft instead gave /guidance/ to implementers.

*	The draft could still give the same 2-10/100 policy, but as /guidance/ for the current public Internet.
*	The draft should also state the conditions under which this guidance was determined (e.g. Internet paths with BDP between x and y, or whatever).

What's the difference? Stating a default policy implies this is a matter of interoperability. It's not. If we change to giving guidance, I'm sure most implementers will just use the guidance. However, implementers will be free to evolve their default as they gain experience.

This reduces the possibility that other behaviours will evolve around any default like 2-10/100. For instance, network monitoring using it as a signature. Or congestion controls optimizing around it. In turn, this will reduce the chance of ossification around the first numbers we thought of.

Senders can always use the ACK frequency frame to ask a receiver to change from its default. Then receivers will gradually learn what senders prefer them to do, and change their default accordingly. IMO, a continually improving default is important for short flows, so senders can avoid requesting a different ACK frequency right from the start.

You are receiving this because you commented.
Reply to this email directly, view it on GitHub <> , or unsubscribe <> .  <> 

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