Re: [quicwg/base-drafts] Another pacing algorithm (#3655)

Martin Thomson <> Thu, 14 May 2020 01:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94B653A0B80 for <>; Wed, 13 May 2020 18:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.273
X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, 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_MSPIKE_H2=-0.001, 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 I9eS9Cbcu3pQ for <>; Wed, 13 May 2020 18:31:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB66E3A0AFF for <>; Wed, 13 May 2020 18:30:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 962538C1007 for <>; Wed, 13 May 2020 18:30:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1589419855; bh=pkbQE6lTawRQ7Hc5sRlGBbLMpYE/lidhIe5NVyUhLeA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=hdjJpmGs/xHLxcoFmT1GqrBNScwBx75Zg+3MswMcxc5ZLRJxZrEy39hjWDsQb1Dky f0JSi4c0HRwmPsG4Y75vdZ++1/1icEVbiwMYngb+cB6bSp1cZDQ1MxgSTGeFyG0aDD spvpevnWOQrG2Lw4DNP2LJ4T7OKDZuHF3WfTxm4g=
Date: Wed, 13 May 2020 18:30:55 -0700
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3655/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Another pacing algorithm (#3655)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ebc9f4f879a3_6e5c3f92ad0cd96816456c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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: Thu, 14 May 2020 01:31:09 -0000

@martinthomson commented on this pull request.

I'm ok with either this or the other one.

> +exceed a small multiple, `pacing_gain`, of the congestion window. Larger
+bursts can reduce CPU utilization at the risk of increased retransmits rates.

This last sentence seems a little disconnected from the rest.  A small tweak might might help:

exceed a small multiple, `pacing_gain`, of the congestion window. Endpoints can
trade off sending packets in bursts, which might be done to reduce CPU
utilization, against even pacing, which has a lower risk of inducing packet

> +A `pacing_gain` multiplier greater than 1 allows senders to increase the rate
+of sending. The value of `pacing_gain` might be larger in slow start than
+congestion avoidance to ensure the sender is able to double its congestion
+window every round trip.

There are two reasons.  As the window increases, the rate increases, so you only really need this gain to a) anticipate future increases and b) avoid having scheduling delays eat into your send rate.

The future increases thing is worth noting.  Pacing causes packets to be spaced out over time, and you won't be able to realize an increase in congestion window until an entire round trip has passed if pacing_gain is 1.  Whereas if pacing_gain is matched to the rate of increase in the window, you are already sending at the increased rate, so you never have to worry about the pacer being the cause of you not sending enough.

@janaiyengar argued that you don't need to worry about this effect.  I think that it's worth compensating for, at least partially.  With pacing, increases to the window will be continuous, or at least multiple times per round trip time, so the degree to which your pacer drags your send rate down is based on the rate of updates (i.e., ACKs) you get.

This is a stair-step function bounded by a straight line (well, a logarithm, but just change conceptually to a log vertical scale).  The steps happen as you get ACKs (or timer pops), so the amount you shade is bounded by how often the updates are.  You get closer to shading the area under the line if you update more often.  The realization here is that you can shade a similar area if you are willing to shade above the line :)  If you set pacing_gain == multiplicative increase, you are not keeping the steps below the diagonal, you are putting them on top by assuming that you will get an increase.  Choosing a value between 1 and m hedges a little.

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