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

IngJohEricsson <> Sat, 28 March 2020 10:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 771333A0EC2 for <>; Sat, 28 Mar 2020 03:04:22 -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 OynFll1oijqU for <>; Sat, 28 Mar 2020 03:04:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 079973A0EC1 for <>; Sat, 28 Mar 2020 03:04:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A68FE660E47 for <>; Sat, 28 Mar 2020 03:04:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585389859; bh=LBoUaK60gyimZ4D0vVgILCxeOsh2xiIBJVApr26Yysc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=nzIsYE9IZkQw7ZVkruERSgAu28oW+TrPMn+RP11FP8P3Ar8twC7IHrGM60EQXzldT WQPQf40MALyQ26bUkps3Uz+lOzpPpOV0PiOfTho+lzn9K7CkrJ7UbpTTMjl7gqvf8X plSRZhaMlM3eKaCOvtlKpqferHF1+9GHxImT7Two=
Date: Sat, 28 Mar 2020 03:04:19 -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_5e7f212395c5f_27673fb859ccd96c3708c0"; 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: Sat, 28 Mar 2020 10:04:23 -0000

Anybody has a gut feeling how very low latency congestion control fares with sparse ACKs?. I have experienced that DCTCP is more picky with ACK aggregation than e.g Reno. I suspect that ACK-thinning can have the give the issue as well. A too sparse ACK spacing can also give problems. Another aspect is how e.g. TCP Prague with paced chirps work with sparse ACKs ?. To me the RTT/4 rule makes sense but I feel that the best alternative depends a  lot on both the congestion control and the source material. Large file transfers are more trivial than sources that are occasionally idle. 

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