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

Tatsuhiro Tsujikawa <notifications@github.com> Thu, 26 March 2020 01:47 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 0CDDF3A0DB2 for <quic-issues@ietfa.amsl.com>; Wed, 25 Mar 2020 18:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.471
X-Spam-Status: No, score=-1.471 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, T_SPF_TEMPERROR=0.01] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id w0ahnFMtPxpo for <quic-issues@ietfa.amsl.com>; Wed, 25 Mar 2020 18:47:48 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1613A0CB1 for <quic-issues@ietf.org>; Wed, 25 Mar 2020 18:46:07 -0700 (PDT)
Received: from github-lowworker-f045d1f.ac4-iad.github.net (github-lowworker-f045d1f.ac4-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id BA85E660020 for <quic-issues@ietf.org>; Wed, 25 Mar 2020 18:46:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1585187165; bh=APO9VdDv2yjLjHm6apcNDR3ICmpCS5cfbfAoIYn6eFc=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=NW/mg1HNkCPgWW3UB5w03zmrYGTnElGLJLsrrNJW+JDy+Ojs3xS0K/EAE4QH6ngOZ jnt3SCcIaYnp7jSpEH/gDxi56X5ClD77D8W8R6Viin/U0RB3u+JOPRbpeq8KP3CKL+ BkzGRPiWetmVsTc/n3Z1awEmhBHsbytLiZsoVUBA=
Date: Wed, 25 Mar 2020 18:46:05 -0700
From: Tatsuhiro Tsujikawa <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4TWSAYLXKD4QBW7OV4Q7VF3EVBNHHCGDM7NY@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@github.com>
Subject: [quicwg/base-drafts] PTO probes are sent too frequently (#3546)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e7c095daa942_5a3f3ff88becd95c3176a3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: tatsuhiro-t
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/AqQ2NlLC8m31sI5axypGEVcmu5w>
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 01:47:54 -0000

It looks like under the current PTO algorithm PTO probes are sent too frequently under certain condition.
To create such a condition, suppose that client never send Handshake packets.
According to the -27 spec, client sends ack-eliciting anti-deadlock packet on pto_count=1.
Then it gets ACK from server for it, which resets pto_count to 0.  After next pto timeout, it sends anti-deadlock packet again.  This process repeats indefinitely until either endpoint gives up handshake.  The problem is that depending RTT, PTO probes are sent too frequently.  With RTT=6ms, it sends PTO probe once per ~33ms.  And both sides do this.  ACK+PADDING packets are also sent without delay in this period if remote endpoint does PTO.   I'm not sure TCP does the similar things, but it sounds like PTO probe is too aggressive.
If both endpoints are implemented properly, this probably does not happen, but in practice, we don't know the remote endpoint is broken in this case, and have no means to check that out.

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