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

Gorry Fairhurst <notifications@github.com> Mon, 23 December 2019 08:55 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 65DE3120074 for <quic-issues@ietfa.amsl.com>; Mon, 23 Dec 2019 00:55:33 -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 q54hSjcdU6kR for <quic-issues@ietfa.amsl.com>; Mon, 23 Dec 2019 00:55:31 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D05120025 for <quic-issues@ietf.org>; Mon, 23 Dec 2019 00:55:31 -0800 (PST)
Received: from github-lowworker-25680bd.va3-iad.github.net (github-lowworker-25680bd.va3-iad.github.net [10.48.17.61]) by smtp.github.com (Postfix) with ESMTP id 69816C60E1E for <quic-issues@ietf.org>; Mon, 23 Dec 2019 00:55:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1577091330; bh=6dMKM6lsECh4UlP/K64To5/gQiFv+Qxo7LhBoQsR7JI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=KiIL9EXJ6O+PZUAkmHappPXPyFmbx+HsTLvxEYJ9m2+S5tcgfi4m78Z+PjpfLE5Jd YRsOrvf69Ly7T/7tlUM7TFI/xqQdbFToA7lCYMjeZ7ySgirgIOHVjS6oDfz4dGZzAV mjlGhh8lEBszVyIiKe8Is4Up2IS5k27+mtfl8TDA=
Date: Mon, 23 Dec 2019 00:55:30 -0800
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5M7Z63W7ISU4ZZLHF4BWZYFEVBNHHCAHNJCY@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/568407752@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_5e0081025bcfa_591c3ff5e7ecd96c54305e"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: gorryfair
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/Qpkc6aKdrSq64YrPDn_PQtl7cIk>
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: Mon, 23 Dec 2019 08:55:33 -0000

I agree keeping 1:2 (or even 1:4) is useful for low-rate flows, age 1:2 in TCP originated at a time when rates were << 1 Mbps.

The decision to switch based on number of packets received or some heuristic based on ACK rate is probably what is needed: Detecting the impact of ACKs by looking for an overloaded return path is very hard - basically a design needs to understand there is "cost" to sending ACKs - sending an ACK every other data packet consumes 1/3 of transmit opportunities in overhead. That's expensive in radio resource - however the value fails to take into account that in many scenarios the physical layer is less efficient in the return direction (for various physical reasons) and will result in greatly  increased cost and/or greater variability if the ACK rate is high. There is a reason why RFC3349 mechanisms have been widely used with TCP for over 25 years - however,  I'd suggest 10 Mbps of data is already making a rather high ACK rate, probably 1 Mbps is nearer the point at which the cost matters.

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