IETF Logo Mail Archive

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

Jana Iyengar <notifications@github.com> Thu, 19 December 2019 03:48 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 590B112004F for <quic-issues@ietfa.amsl.com>; Wed, 18 Dec 2019 19:48:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 6fMK9pAHQc66 for <quic-issues@ietfa.amsl.com>; Wed, 18 Dec 2019 19:48:08 -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 11547120018 for <quic-issues@ietf.org>; Wed, 18 Dec 2019 19:48:08 -0800 (PST)
Received: from github-lowworker-6349a71.ac4-iad.github.net (github-lowworker-6349a71.ac4-iad.github.net [10.52.18.20]) by smtp.github.com (Postfix) with ESMTP id 6B3FD661228 for <quic-issues@ietf.org>; Wed, 18 Dec 2019 19:48:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576727287; bh=Tww4AmdbbIphdgJ+T2MB1+xt2lzN25JKij6edCTJk5E=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=M8Pg7jQ2dlPNXkoncIvwe5RGHO/upErxvfV0IXvaDV3WEHOkW5gkJQhhuNVdsnePj 2C+irro8GyipgsRI/coMy7VODUEmfPrG+8oPHKlYLc6B8IOwsliQq1S2nlmV+Bqkwc /DNtn9Ox1PZCIqcdZg1os0dtYt1SUm29s59am87I=
Date: Wed, 18 Dec 2019 19:48:07 -0800
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZ6G5QABJDRJTQ4CON4BASXPEVBNHHCAHNJCY@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/567319581@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_5dfaf2f75babc_33b93f8c0c2cd96892498"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/1nd5qTKaNAHgZTp8gHRXx-q4lhk>
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: Thu, 19 Dec 2019 03:48:09 -0000

@yangchi:

> Shouldn't that largely depend on server implementation?

Yes, specifically the congestion controller. My question was directed at @ianswett, about experiments with Chrome's strategy for a server that does Cubic. My point is that the client here (Chrome) has decided to use an ACKing strategy that works well with BBR (that's what Google servers use), but as Ian notes, that strategy may cause perf regressions for a server that speaks Cubic or Reno. Since most QUIC servers out there are unlikely to be speaking BBR (this is simply my assertion), my question was about the extent of this degradation.

I understand why this is not simple, and that is why I've opened this issue -- we have a recommendation right now in the draft that suggests that we know a good answer.

I will send out a PR shortly, which should help make this conversation more concrete.

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

v2.23.0 | Report a Bug | By Email