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

Jana Iyengar <notifications@github.com> Tue, 17 December 2019 03:44 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2B71912009C for <quic-issues@ietfa.amsl.com>; Mon, 16 Dec 2019 19:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IJ7KJF2oveVk for <quic-issues@ietfa.amsl.com>; Mon, 16 Dec 2019 19:44:20 -0800 (PST)
Received: from out-20.smtp.github.com (out-20.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89473120041 for <quic-issues@ietf.org>; Mon, 16 Dec 2019 19:44:20 -0800 (PST)
Received: from github-lowworker-292e294.va3-iad.github.net (github-lowworker-292e294.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 6BED58C01E4 for <quic-issues@ietf.org>; Mon, 16 Dec 2019 19:44:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576554259; bh=tBd69447RbQxgpCayLGBa6XvsuNlDPe6MDCGLmxMQck=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=qBjJHfAfYAmQgBfauJqqpfNSnXiOOzlodEmxDuHVopN3ZuyaBA4nUllDdB4Web0kA mCdcLA/W7mYr8VjfVsUIc2H6eI28j2cBKKWS7IgZzXwqyy6KHcjTJovmQsGR+CPtnZ z23HGyOhEuvlQPOq/LzGswUWTFAUNqoazLvZS+fM=
Date: Mon, 16 Dec 2019 19:44:19 -0800
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6TTZX2BK5CICBFH3V4AWAZHEVBNHHCAHNJCY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3304@github.com>
Subject: [quicwg/base-drafts] ACK generation recommendation (#3304)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df84f135cef8_21b03fb07eecd95c7306e"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Fiad9d3HKnWYUj9_keX47WIARC8>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2019 03:44:22 -0000

The transport draft currently says:
An ACK frame SHOULD be generated for at least every second ack-eliciting packet.
This recommendation is in keeping with standard practice for TCP {{?RFC5681}}.

Gorry raised the point that in experiments, this generates way too many ACK packets in high bandwidth networks, such as satellite networks. This has noticeable CPU costs for QUIC, for both sending as well as for receiving. Satellite networks use middleboxes that collapse TCP ACKs, but they can't for QUIC. 

We have talked about doing a more general strategy separately as an extension, but we have experience with a fairly straightforward one. Chrome uses an ACK coalescing strategy that does the following: after the first 100 packets, ACK once every 10 packets or 1/4th of an RTT, whichever comes earlier. If we agree that this might be good general strategy, we should suggest it in the transport document.

@ianswett: my recollection is that the strategy had some throughput reduction when used with Cubic, is that correct? Do you think using 1/8th RTT might resolve this?

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