Re: [quicwg/base-drafts] congestion window increase on every ACKed packet could result in bursty sends (#3094)

Tommy Pauly <> Wed, 15 January 2020 23:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BB6812008F for <>; Wed, 15 Jan 2020 15:31:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Status: No, score=-2.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, 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 FcoLVox1LfMN for <>; Wed, 15 Jan 2020 15:31:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21471120044 for <>; Wed, 15 Jan 2020 15:31:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3AFB1E005C for <>; Wed, 15 Jan 2020 15:31:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579131079; bh=Ryocdst0uva2yjCuBlVcUmD1SHP8s1x1Z15cs8ydKOk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=exhMNjP6WYdsfJdyJziGeg52D3BrbxPVSJ7/4l4toNtQPfESYLOAmZN6w04R99M6v zeCDh33FhqYtcdlUdJk2q5GOOczS7wr3yzj3E8AFJ2M3JjEDPWIHHJBnwadf/7iycN T1pf8cFUKrp3cxn0iGDq2kIDAJyl0HX/6XU6JcoM=
Date: Wed, 15 Jan 2020 15:31:19 -0800
From: Tommy Pauly <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3094/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] congestion window increase on every ACKed packet could result in bursty sends (#3094)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1fa0c72bda5_2573fce98acd96419107c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: tfpauly
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, 15 Jan 2020 23:31:22 -0000

Bringing conversation in from the list:

With regards to #3232, one of the things we found in testing was that it could (a) still allow an implementation to be vulnerable to too much bursting (the original problem), but more importantly (b) locked receivers into an ack pattern of acking every other packet. My main concern is that this causes problems if receivers want to experiment with and change acking strategies going forward in way that otherwise would be fine.

One way to look at the problem described by this issue is that the existing text has a minor underspecification, in which it has the notion of a burst limit but says nothing about the frequency of such bursts. Two "bursts" of 10MSS that are sent within a couple nanoseconds are really one burst that's too big. Another way of fixing this is to remove even the specification of the 10MSS limit if we really don't want too much text about the non-pacing cases.

Essentially, what this comes down to is: pace, or even if you don't pace, you need to not send bursts above some frequency; and if you don't set some pacing timers, you'll likely underutilize the link.

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