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

ianswett <> Thu, 26 March 2020 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54C783A0A1A for <>; Thu, 26 Mar 2020 07:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Status: No, score=-1.554 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_20=1.546, 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 f6yjwYZgxxdM for <>; Thu, 26 Mar 2020 07:46:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AEE73A0931 for <>; Thu, 26 Mar 2020 07:46:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 60B31C60615 for <>; Thu, 26 Mar 2020 07:46:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585233993; bh=G+P3hUnFnfn30lyTO0yZaXSr7E/3WRQlUXkHI4jP77o=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tuWoFxpFS6Wz2Y8RhcvOPKadMLmodD8+TndeMrdhY8SOy6i2bz6r1CdDeTfGub/NA /rI6fKHcLSW1X2+9xdvpiT+vD0lg1FFmn/CnTwmgkAmSGQpvyCxCFaRoTn+vvwHV8p sm7mR30A6tEOy13VumQrhk0psvIwhlruRPsgRtd8=
Date: Thu, 26 Mar 2020 07:46:33 -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_5e7cc04951cd6_269d3fa7626cd95c609af"; 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: Thu, 26 Mar 2020 14:46:37 -0000

If the server keeps quickly ACKing packets but not sending handshake data, then yes, the client will keep sending full-sized packets, believing the server is blocked by the anti-amplification limit.

At first I thought this couldn't happen in a real-world scenario, but possibly if one had async TLS handshaking so the ServerHello could not be sent immediately upon receipt of the ClientHello and the server and client were very close, a packet could be exchanged as quickly as 1 packet each direction per kGranularity time until the async process returned?

TCP doesn't have an anti-amplification limit and it doesn't require Handshake packets to provide address validation.

I would characterize this as an issue with the client's anti-deadlock response, rather than a problem with PTO.

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