IETF Logo Mail Archive

Re: [quicwg/base-drafts] When the sender is using standard Reno congestion control, ack every ~2 packets (#1428)

ianswett <notifications@github.com> Tue, 11 September 2018 22:54 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 540CF130F63 for <quic-issues@ietfa.amsl.com>; Tue, 11 Sep 2018 15:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level:
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 QCA_L_UgAOyC for <quic-issues@ietfa.amsl.com>; Tue, 11 Sep 2018 15:54:14 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7104D130EF7 for <quic-issues@ietf.org>; Tue, 11 Sep 2018 15:54:14 -0700 (PDT)
Date: Tue, 11 Sep 2018 15:54:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1536706453; bh=G9fF+onfOFCDdbQC+SsItXvBswj1D26ZY7Q20ytp2Y0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=fEDFKVRo9WWqxC7484Prh4yspz/PwGJXBO95WUPOQBdjWadFKzxYSr1Z/w6T24MNo TTyXG1c/u+XOSXtxK63CPgGEiCchmMc8DbHWxTViI6TvzdsRMp5RuKcI+GlbAfqpjw YC+xgnoPCHa6zH5X30Cpox24aDkpqbZjGgh2ELxE=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abf1cf7df59c4b2610f5f8456b818e4e42891daf3792cf0000000117b0099592a169ce13ae108c@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1428/420453247@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1428@github.com>
References: <quicwg/base-drafts/issues/1428@github.com>
Subject: Re: [quicwg/base-drafts] When the sender is using standard Reno congestion control, ack every ~2 packets (#1428)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b984795424f3_7f263fd6318d45b889389"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/RTX4WlXjtyIVYq_Lw-8Clx7tCQk>
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, 11 Sep 2018 22:54:16 -0000

Thanks Christian, specifying the preferred peer max ack delay as a fraction of RTT is what gQUIC does today, and works well for BBR and other rate-based congestion controllers.  However, at the moment, there's gQUIC also sends an ACK every 10 packets, but some experiments have been done to raise that to 20, and no degradation was observed.

My concern is that I never got fraction of RTT based acking to work as well as every 2 packets for TCP Cubic, but I never tried a value lower than 1/8RTT.

In general, I think this suggestion is good and easy to implement, but I'm a bit concerned about regressions vs the "ACK every 2 packets" approach with Reno or Cubic.

We could have a 'status quo' knob that if the ack delay isn't specified, just ack every two packets with the recommended max ack delay?

-- 
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/1428#issuecomment-420453247

v2.23.0 | Report a Bug | By Email