IETF Logo Mail Archive

Re: [quicwg/base-drafts] Update ACK generation policy (#3501)

Gorry Fairhurst <notifications@github.com> Sun, 22 March 2020 19:25 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 06ABB3A080C for <quic-issues@ietfa.amsl.com>; Sun, 22 Mar 2020 12:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Level:
X-Spam-Status: No, score=-1.482 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 KYhAE_zAjvsd for <quic-issues@ietfa.amsl.com>; Sun, 22 Mar 2020 12:25:45 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA9F3A080A for <quic-issues@ietf.org>; Sun, 22 Mar 2020 12:25:45 -0700 (PDT)
Received: from github-lowworker-39b4a70.va3-iad.github.net (github-lowworker-39b4a70.va3-iad.github.net [10.48.16.66]) by smtp.github.com (Postfix) with ESMTP id 92FEA9604C5 for <quic-issues@ietf.org>; Sun, 22 Mar 2020 12:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584905143; bh=KYHxvDS7dIKe5xgHSrVGHJ5K5Z+m5I63uoF8+cRs1ss=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=w6MuhGKqcfTv8XwbSbiYVGCndTkSnNWuxxOMne2dkTWR6YS23P6nCbgMRbZbdkFzU sHtWxgR/TdVHW6U1hMbnozrDNbq/V52FkRJEBwLIuxA182ocs9X+neEe323GBJIIdv zzaifGQ4v8CEAQ5PSjkyFitA/X5MhzgObFlKlLnM=
Date: Sun, 22 Mar 2020 12:25:43 -0700
From: Gorry Fairhurst <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7IKQKUTBFJDHWED554QOOLPEVBNHHCEV4TFI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3501/review/379038862@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3501@github.com>
References: <quicwg/base-drafts/pull/3501@github.com>
Subject: Re: [quicwg/base-drafts] Update ACK generation policy (#3501)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e77bbb784700_547f3fd285acd964772e4"; 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/GWBLmfPCS0YjIrFdDC9oFuYgDJk>
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: Sun, 22 Mar 2020 19:25:48 -0000

gorryfair commented on this pull request.



> @@ -3170,11 +3170,21 @@ delayed retransmissions from the peer. For Initial and Handshake packets,
 a max_ack_delay of 0 is used. The sender uses the receiver's `max_ack_delay`
 value in determining timeouts for timer-based retransmission, as detailed in
 Section 5.2.1 of {{QUIC-RECOVERY}}.
+The max_ack_delay needs to be set so that at least several samples can

Does that matter for there first RTT?  The sender still receives an ACK after IW packets (assuming IW packets are sent)? If it matters, let's figure out how to solve that.

If the RTT turns out to be smaller than max_ack_delay*n (n updates/sec), then you can reduce max_ack_delay. I think this replicates  the ACK policy in Chromium? - but would be happy to see a different formulation that generates sufficient ACKs.

-- 
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/pull/3501#discussion_r396131247

v2.23.0 | Report a Bug | By Email