[quicwg/base-drafts] Simplify the client's PTO code by allowing the server to send a PING (#3161)

ianswett <notifications@github.com> Mon, 28 October 2019 17:30 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 01EFB1208EB for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 10:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bM__8n6y8CF6 for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 10:30:26 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.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 22FFD1207FD for <quic-issues@ietf.org>; Mon, 28 Oct 2019 10:30:26 -0700 (PDT)
Date: Mon, 28 Oct 2019 10:30:25 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572283825; bh=IOWC24DSktkDxxBKndhdQp1xEoj/sw7L+4G6zqcL7S8=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=scmyiEeJQFR+f3AGO0MH9t1DhHGaBJhJjANzXZmRhc0vwaFhNawa3+eNlXpuBkDOZ h5Fj/w1hAnFPn8P2ZDVq5ysY7GRDnwTz2+WbsGVvqgKQ6NaewTSz9Yc35OAQpNfqvN ZWEfGX3tAZcswPZZ4nn9RMcm7sEbvaSPx/3ZmEkI=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK436G4DWF4AYDJIZ753YRTEDEVBNHHB5GVBRY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3161@github.com>
Subject: [quicwg/base-drafts] Simplify the client's PTO code by allowing the server to send a PING (#3161)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db725b147934_2e663ff2c36cd9644101c"; 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/gg5b0zi1pX0SAmYTVuy84CyuizM>
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: Mon, 28 Oct 2019 17:30:28 -0000

At the New York QUIC interim, we dealt with the problem of the server being blocked by the amplification factor by making it arm the PTO until it knew the server had validated the path, even if it had nothing to send.

>From the recovery [pseudocde](https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-recovery.md#on-timeout):
`  if (endpoint is client without 1-RTT keys):
    // Client sends an anti-deadlock packet: Initial is padded
    // to earn more anti-amplification credit,
    // a Handshake packet proves address ownership.
    if (has Handshake keys):

When reviewing https://github.com/quicwg/base-drafts/pull/3057, I realized that if we allowed the server to send a PING-only packet when the PTO fired and the amplification factor had been reached, then that would elicit a padded Initial ACK frame in response, which also fixes the issue.

@martinduke though that was a simpler solution than the current approach and this is a bit of an edge case, so simple is probably good.

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