IETF Logo Mail Archive

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

ianswett <notifications@github.com> Thu, 26 March 2020 14:46 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C783A0A1A for <quic-issues@ietfa.amsl.com>; Thu, 26 Mar 2020 07:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6yjwYZgxxdM for <quic-issues@ietfa.amsl.com>; Thu, 26 Mar 2020 07:46:34 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEE73A0931 for <quic-issues@ietf.org>; Thu, 26 Mar 2020 07:46:34 -0700 (PDT)
Received: from github-lowworker-cd7bc13.ac4-iad.github.net (github-lowworker-cd7bc13.ac4-iad.github.net [10.52.25.102]) by smtp.github.com (Postfix) with ESMTP id 60B31C60615 for <quic-issues@ietf.org>; Thu, 26 Mar 2020 07:46:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; 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 <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZFRDEAWG3GKFKN4Y54RCQUTEVBNHHCGDM7NY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3546/604472286@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3546@github.com>
References: <quicwg/base-drafts/issues/3546@github.com>
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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/1kKug3xGikx2HNRhREPwAjSarqY>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=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:
https://github.com/quicwg/base-drafts/issues/3546#issuecomment-604472286

v2.23.0 | Report a Bug | By Email