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

IngJohEricsson <> Tue, 28 April 2020 12:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 268FC3A146E for <>; Tue, 28 Apr 2020 05:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Status: No, score=-3.099 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, 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 0JrrjAHgfJ8B for <>; Tue, 28 Apr 2020 05:34:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A4283A146B for <>; Tue, 28 Apr 2020 05:34:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 06FF48C08B2 for <>; Tue, 28 Apr 2020 05:34:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1588077259; bh=ERXA6rWG9IZwPZvkxG0mVabcHF2+hQr9lIciE86cGbE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZsyJqzEioHWstX6NNlLFO5AA5ZQq+nUeCWLxAQSzemAGpte6fQFy9gDRrHj9B5q2O LiwqZEcoPi+RMmgZPJVXyOYBsyjjsBp0FCkGfxi+SjCyfttRmbiF1vjsN+lBgIoPCf NHjWGW8Zw8FG4mQkdOTkowWAoC8gtoXq3Jzg6yew=
Date: Tue, 28 Apr 2020 05:34:18 -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_5ea822caeab83_c973f9b1d6cd96c326666"; 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: Tue, 28 Apr 2020 12:34:22 -0000



I believe that it is beneficial to use a 1:10 policy, I understand that this means that a 1:2 policy that still be used in the initial phase (flow start) or does the timer mechanisms kick in to avoid that ACKs are transmitted too sparsely in this case ?.




From: Gorry Fairhurst <> 
Sent: den 28 april 2020 13:38
To: quicwg/base-drafts <>
Cc: Ingemar Johansson S <>; Comment <>
Subject: Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)


On 27/04/2020 17:19, Lars Eggert wrote:

> Folks who care about a change here need to prioritize progressing this 
> issue. We're close to being able to last-call the specs, and would 
> like this resolved in time.
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> < <> >, 
> or unsubscribe 
> < <> >.
We’ve completed a round of updated analysis of the proposed change to 
the QUIC spec, using quicly (changing to a 1:10 policy), and chromium 
(which currently does 1:10 by default). Our hope is that this change to 
the spec,  to actually make standard end-to-end QUIC work better than 
TCP over asymmetric paths!

This is a short slide deck about the performance of the proposed change:

There have been a number of other change made by the QUIC ID editors 
relating to ACK processing, so we wanted to be sure these results were 
up to date. (These results do not consider additional ACKs after 
re-ordering - reflecting the latest text removing that.)

We also really hope this will motivate a change the practice of forcing 
of QUIC fallback to TCP (with PEP/Thining) over highly asymmetric paths. 
People may also be interested in work for L4S to evaluate the impact of 
ACK Thining for TCP-Prague.

Please do provide feedback, or any questions on this - as Lars notes, we 
think the time is running out for considering new changes, even 
relatively simple ones like this.


P.S. First email:

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: