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

Junho Choi <> Wed, 18 December 2019 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 634C5120967 for <>; Wed, 18 Dec 2019 12:16:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Status: No, score=-6.382 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_24=1.618, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oMflSNAzT8Mp for <>; Wed, 18 Dec 2019 12:16:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7DE5120A77 for <>; Wed, 18 Dec 2019 12:16:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D3982660C38 for <>; Wed, 18 Dec 2019 12:16:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1576700200; bh=aqkS1qyyNDrygzXP1jdQ02GK5K7TiMlUBkOLcXP7NZE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uGa5uVFxZiO6GQKOEcbj4PbEvhH+DBowFKBAU1DRcQj6H8N30CyMKvnvUaUJhxB+2 OwVqptnpsyk8GypTUYoOJmbfV3Wx7JMljK0BGwq+rEY9blnePNSpMxNkpuBNydJIU9 kYvozCSNzId+byuf72rEWS6EIL22wh9tziM6wdvM=
Date: Wed, 18 Dec 2019 12:16:40 -0800
From: Junho Choi <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3304/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] ACK generation recommendation (#3304)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dfa8928c3bde_da23fdf364cd95c444676"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: junhochoi
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Dec 2019 20:16:43 -0000

Cloudflare(quiche) is implementing Reno at this point (and will soon add more congestion controls). Since now there is a variety of parties implementing/choosing their own choice of congestion control module (Reno as in the draft, Cubic is mentioned, Google has BBR(v2), Facebook has COPA...), I think it's good to keep a general strategy in the draft (every-2-packet ack is what TCP recommends so I think it's fine for most cases). But worth mentioing alternative strategy is possible (what Chromes does, or something like linux TCP_QUICKACK?)

If we want to use TP, I think Server may send its congestion control algorithm using a transport parameter so that Client can pick up its own ack strategy if needed.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: