Re: [quicwg/base-drafts] ACK generation recommendation (#3304)

Jana Iyengar <> Wed, 18 December 2019 03:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4ECF9120178 for <>; Tue, 17 Dec 2019 19:50:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 DNNx4IfEUoSA for <>; Tue, 17 Dec 2019 19:50:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACC8D12008F for <>; Tue, 17 Dec 2019 19:50:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EF8236E044A for <>; Tue, 17 Dec 2019 19:50:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1576641035; bh=wdyqIKCnu+MPjCo5CxkPm+IpCLongURtvwIuSQkkWbQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=HvgTtQ8XbiFlMAklT35NSyPzNc1Y2L78Ne5E1DkFGOqvqi36ghA7KAmJNWyZkMyX0 EuJRv7gLeobOFxzK3zR+ND2mplUCppxtJ8g1oT5JmtnfhVOZX88k4zmzYbDCZ3xTTA FhpD0jf1+ZTsOBdeU3afMnEz7ntuJzBre2zZZUPo=
Date: Tue, 17 Dec 2019 19:50:35 -0800
From: Jana Iyengar <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3304/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] ACK generation recommendation (#3304)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df9a20be1a86_61443fe96decd95c157649"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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: Wed, 18 Dec 2019 03:50:39 -0000

@ianswett: TCP does have a formal requirement which we cite in the recovery draft right now. From RFC 5681:
   The delayed ACK algorithm specified in [RFC1122] SHOULD be used by a
   TCP receiver.  When using delayed ACKs, a TCP receiver MUST NOT
   excessively delay acknowledgments.  Specifically, an ACK SHOULD be
   generated for at least every second full-sized segment, and MUST be
   generated within 500 ms of the arrival of the first unacknowledged
The problem is that this is quite dated and the TCP ecosystem has corrected for this by collapsing ACKs in the network. Additionally, the two major QUIC clients deployed right now -- FB and Chrome -- neither follows this recommendation. It seems silly to continue saying SHOULD when we expect it to not be followed.

Also, @kazuho [raises an interesting  point]( Chrome is likely to be speaking to servers that might be using Cubic or Reno in the near future. Do you recall how serious the degradation with Chrome's ACKing scheme was? With 1/8th RTT?

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