IETF Logo Mail Archive

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

ianswett <notifications@github.com> Tue, 17 December 2019 18:03 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 795A6120CE0 for <quic-issues@ietfa.amsl.com>; Tue, 17 Dec 2019 10:03:15 -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 lYni08dZmFj8 for <quic-issues@ietfa.amsl.com>; Tue, 17 Dec 2019 10:03:13 -0800 (PST)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D35120CED for <quic-issues@ietf.org>; Tue, 17 Dec 2019 10:03:11 -0800 (PST)
Date: Tue, 17 Dec 2019 10:03:10 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576605790; bh=6y6E8+p8MqrZQFYyjtrrsm+vIt2Q8050ug0EyZdagbs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=SgtZJD4/iYGGkn9W+gnhROd9QG1oSX8nxXviUxnk7EYRMb2SRPYvliyepB2nDmloN SZ+Zfo74Ulic8Rjoce6UJe9wo4vMVJMo4S1sINeyfeZcwALnHSa5VFGNq7874u1yWP uykjV8dm2c/ae+x0eAF4kndV+cqatLLOAKrYcn9w=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZSEVBVE4VJB25M6ZF4AZFN5EVBNHHCAHNJCY@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/566679135@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_5df9185e5193a_7d0c3ff6d16cd95c2596f4"; 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/_o1SdB-JydjAM_jpolH0Br-OkO8>
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 18:03:15 -0000

There was still a regression with 1/8th RTT and Cubic.  We we using pacing at the time, FYI.  Not pacing or pacing differently may lead to slightly different results.

Given TCP has no formal recommendations on this that I'm aware of, I tend to think we should solve this problem properly or punt it to an extension.  Recommending the heuristic that Chrome arrived at though some(though not exhaustive) experimentation makes me concerned.

Sending fewer ACKs impacts the sender's congestion controller, so ideally the sender would be in control of this, or at least be aware of what the peer's algorithm is.  We could add some transport params to unilaterally communicate that, like we do max_ack_delay, but then do we need to specify how to compensate for that in the recovery draft?

I'm having a really hard time coming up with a good recommendation here without some combination of a new frame and/or transport params.

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

v2.23.0 | Report a Bug | By Email