Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)

Kazuho Oku <notifications@github.com> Mon, 01 June 2020 02:53 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 A47603A0B10 for <quic-issues@ietfa.amsl.com>; Sun, 31 May 2020 19:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.101
X-Spam-Level:
X-Spam-Status: No, score=-8.101 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 o93SwEGongDT for <quic-issues@ietfa.amsl.com>; Sun, 31 May 2020 19:53:22 -0700 (PDT)
Received: from out-27.smtp.github.com (out-27.smtp.github.com [192.30.252.210]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700D53A0C08 for <quic-issues@ietf.org>; Sun, 31 May 2020 19:53:16 -0700 (PDT)
Received: from github-lowworker-f62aa54.va3-iad.github.net (github-lowworker-f62aa54.va3-iad.github.net [10.48.17.68]) by smtp.github.com (Postfix) with ESMTP id BE8D6E003A for <quic-issues@ietf.org>; Sun, 31 May 2020 19:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590979995; bh=tUVESPDquNRkw5HYnHJsIBVnU9fD6JAFrV5aDqDZuvE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Jlyi9wXWDcS3oAqSDlw+IVwKuNcTajZz6DsunpzVfLDZ2xD0/HW707h7gdkKJcr6a KlXj6ay/bfBl5ngVNaNJmIj7/37rCIaW7MZcxW5Oh3D+saOt5mFdiXJ6cFAYJpNm32 4BdnLCKaWhlR1Vu4sn3GOPLFaj2wqsIDEGsd5JU8=
Date: Sun, 31 May 2020 19:53:15 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK67I7VIDZWJJKGC5SV44BHJXEVBNHHCFSANWY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3529/636585635@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3529@github.com>
References: <quicwg/base-drafts/issues/3529@github.com>
Subject: Re: [quicwg/base-drafts] Changing the Default QUIC ACK Policy (#3529)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ed46d9bad7a1_46683fd459acd95c2688f5"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/HTz2znOZY1JNrDkVQKaJG7z8Dw4>
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, 01 Jun 2020 02:53:26 -0000

@gorryfair 
>> Please bear in mind that Chrome's ack policy of 1:10 works with BBR, not with Cubic or Reno.
> 
> I didn't find something in QUIC spec. that was a major concern. It looked to me like QUIC had learned from TCP how to handle stretch-ACKs.
> 
> After that, we changed quicly to use 1:10 with Reno, and things worked well. Didn't @kazuho <https://github.com/kazuho> also use Reno?

Just to clarify, in our experiment, we reduced the ACK frequency from the default (2) to `max(1/8 cwnd, 3 MTU)` after leaving slow start, then updated it every 4 PTO. I _think_ that would work fine on a high-bandwidth, stable network. But I am not sure if it would work as well as ack2 on all network conditions.

Anyways, I'd explain our experiment as an optimization of ack 2, as it was reduction of ack rate after leaving slow start. I think that that was a sensible choice, because IIUC having frequent acks during slow start is essential.

Assuming that we'd prefer using ack 2 during slow start, the question is if we need to hard-code in the base draft how to _optimize_ after leaving slow start. While I agree that continuing to use ack 2 after slow start is concerning for certain networks, I am reluctant to spending time on looking for such a fixed set of values across diverse networks (including much slower links or lossy ones).

Rather, my preference goes to shipping the base-draft as-is, then moving on to finalize the ack-frequency frame. I think we can assume most if not all of the popular clients to support the ack-frequency frame. Then, it becomes less of a question what the default in the base-draft is.

-- 
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/3529#issuecomment-636585635