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

IngJohEricsson <> Mon, 30 March 2020 06:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09AC83A0E73 for <>; Sun, 29 Mar 2020 23:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.474
X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[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_28=0.726, 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 CUgikcsXcLl3 for <>; Sun, 29 Mar 2020 23:31:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F6F63A0E74 for <>; Sun, 29 Mar 2020 23:31:03 -0700 (PDT)
Date: Sun, 29 Mar 2020 23:31:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585549863; bh=v4r/OqTAJxNvn4r0Q/SToH74mEHObDV4DVYlFgjRaL0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iNL32Pl+WBHs1txGOPZFh3vFJT4mJqEk8sh0/esjWbv2R93DeGbm12vEpu0oIqkYE kF96gJ9oIvCKznWPV+FeQgie/riSzKFZ9itXeWFpOu6l94BJxl7FwTAAXCjOU6hCrI AukY2UeQX9quFQdkZn7BHaV+GbJAXbGrDRjw7y4c=
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_5e8192273397_4f8e3fe788ecd95c186033"; 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, 30 Mar 2020 06:31:06 -0000

I am kind of donkey in the middle... 
ACK thinning in networks should be discouraged. Standardization of ACK thinning mechanisms was proposed in 3GPP RAN2, this request was turned down mainly with reference to that it can harm transport protocol performance and does not work safely. Nothing stops UE (terminal and modem) vendors from implement ACK-thinning but I certainly hope that 5G UE vendors don't attempt to thin QUIC-ACKs as this is a slippery slope.   
High ACK rates is a 5G problem mainly for high band NR (=5G at e.g 28GHz). It is mainly a coverage issue as UEs have a limited output power due to practical and regulatory requirements. At the same time one need to address that end users don't only download movies today and even VoD streaming implies uplink traffic in the form of chunk requests. And then we have an increasing amount of people doing uplink streaming or upload an infinite amount of pictures of food plates and cats :-) 
Operators and 5G vendors have to deal with this and solve the problem with deployment of 5G access in various frequency bands to get the best downlink and uplink performance.
Reduced ACK rates is  of course welcome but I don't currently see a problem that the initial ACK ratio is 1:2 , to increase to 1:? as the congestion window grows, bounded by e.g an RTT/4 rule. But here I need to admit that I at least I have not studied this in detail.
Ergo.. I am not convinced that it is necessary to handwire the QUIC spec to 1:10 is needed but I also cannot say that it should not be done.

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