Re: [quicwg/base-drafts] PTO probes are sent too frequently (#3546)

ianswett <> Fri, 27 March 2020 13:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FBAC3A0827 for <>; Fri, 27 Mar 2020 06:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Status: No, score=-1.482 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_IMAGE_ONLY_24=1.618, 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 bo6nrCPdkJyf for <>; Fri, 27 Mar 2020 06:38:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24C383A07CE for <>; Fri, 27 Mar 2020 06:38:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 356505205E3 for <>; Fri, 27 Mar 2020 06:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585316318; bh=Z+ctth+mKMW+Rn4TS0kTJbbEs9wZPo1cLrL13kPJFrM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=01MZLdqlhu0HYSTGbWljPdAfqbkAIV9TA1PIdIehdD3NpjjMuUtEb7LuDaTecT/gP 7uhljx/klMTIiMn7fE8coBCVRJPRYtXC9U/jQ8nwsUaq9lwmskYT7fT13EsxJ5p2hU EeC1gb9yfmSzuLG/aNYfFa820h/M5z2w6NN23imI=
Date: Fri, 27 Mar 2020 06:38:38 -0700
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3546/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] PTO probes are sent too frequently (#3546)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e7e01de25bed_99d3fa15f2cd964247571"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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: Fri, 27 Mar 2020 13:38:41 -0000

There are other cases when we send ack-eliciting packets including only PINGs or other non-application data and we do want to set pto_count back to 0 when those are acknowledged.

We could specifically recommend sending non-ack-eliciting packets for the anti-deadlock packet, but then you lose an opportunity for an RTT measurement early in the connection, which is unfortunate, though not a dealbreaker.  For full-sized Initial packets, it's likely they'd never be acknowledged if they weren't ack-eliciting, because no ack-eliciting Initial packets would be sent after them.

@kazuho I believe always incrementing pto_count would be detrimental to performance, unless it's under some very narrow circumstances.

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