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

Nick Banks <notifications@github.com> Tue, 17 December 2019 14:48 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1137712084D for <quic-issues@ietfa.amsl.com>; Tue, 17 Dec 2019 06:48:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U2Db9WOeg_y for <quic-issues@ietfa.amsl.com>; Tue, 17 Dec 2019 06:48:15 -0800 (PST)
Received: from out-22.smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E341112080B for <quic-issues@ietf.org>; Tue, 17 Dec 2019 06:48:14 -0800 (PST)
Received: from github-lowworker-e8b54ca.ac4-iad.github.net (github-lowworker-e8b54ca.ac4-iad.github.net [10.52.23.39]) by smtp.github.com (Postfix) with ESMTP id 0471BA1CF6 for <quic-issues@ietf.org>; Tue, 17 Dec 2019 06:48:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576594094; bh=mrAJXJWtbAkjgQr6PP3XnZQwKaDWeX0l5h7PsxF3wlE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZP35E5Hp/08Roa8a2EC6M4/i/ZEH6t4h6vXjRdZU8dMJdAOVM8+O2c9uLdR85DQmN /EWmVhDyDuQNh8UuNfAd1IlfDQOMPuquj7N+AoOkE7uGTscy6sds4FrMlkCS++9AS2 70P+8TwaQE7yCJ9Thpdf3MyHJIKNrY8w5L85/OVk=
Date: Tue, 17 Dec 2019 06:48:13 -0800
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZ7CBUOJIWKSB4RVQ54AYOS3EVBNHHCAHNJCY@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/566573047@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3304@github.com>
References: <quicwg/base-drafts/issues/3304@github.com>
Subject: Re: [quicwg/base-drafts] ACK generation recommendation (#3304)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df8eaade9bab_71803f9ec72cd968110596"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/2kvQWg7xoeEgfa5MHsgUEufx4JY>
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 14:48:17 -0000

> 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.

Could you expand on this? I find this to be an extremely general statement, and not very helpful in understanding the real motivation for any possible changes. You say it "has noticeable CPU costs for QUIC", but are you referring to the client, server or some middle boxes somehow?

Assuming you're worried about the CPU costs on the server side, has anyone explicitly measured the differences in CPU cost for generating different number of ACKs per RTT? What's the effect on FC? Fewer ACKs will mean the sender (I'm assuming the server?) is going to have to buffer more, and FC windows might be hit more often. Is this really such a big problem that is requires a spec change? In V1?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3304#issuecomment-566573047