Re: [quicwg/base-drafts] Clarify client anti-amplification response (#3445)

Martin Thomson <> Wed, 19 February 2020 02:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA64A120891 for <>; Tue, 18 Feb 2020 18:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 02DZIXQLjG4G for <>; Tue, 18 Feb 2020 18:01:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4099712088E for <>; Tue, 18 Feb 2020 18:01:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4F9606A004B for <>; Tue, 18 Feb 2020 18:01:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1582077669; bh=nxD8nAaQhUv6ugrQMjh4SRUjdAq0ej9OS4V0WIxfY3I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=2N/rzI+/ZJaH0WIK2SoR+MbSO7tCXklyKJZJ6QfvpmT0pTU+k+jRBypsneUVihBGm M0oFYnXhmQIdwsHMUyeicz6hOQe6rTbjMq6iG9KKT/XlsJBdWuIPQyea3tGes8CDdy vZcOFvI6QzYvDEDoZnjssuGr//SNbgyTkxVtO+UA=
Date: Tue, 18 Feb 2020 18:01:09 -0800
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3445/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clarify client anti-amplification response (#3445)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e4c96e540197_41443fd7f78cd96c73117"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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: Wed, 19 Feb 2020 02:01:12 -0000

martinthomson commented on this pull request.

> -handshake deadlock, clients MUST send a packet upon a probe timeout, as
-described in {{QUIC-RECOVERY}}. If the client has no data to retransmit and does
-not have Handshake keys, it MUST send an Initial packet in a UDP datagram of
-at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a
-Handshake packet.
+Loss of an Initial or Handshake packet from the server can cause a deadlock if
+the client does not send additional Initial or Handshake packets.  The server
+can reach its anti-amplification limit, but if the client has received
+acknowledgements for all the data is has sent, it has no reason to send more
+packets. In this case, where the client would otherwise not send any
+additional packets, the server will be unable to send because it has not
+received enough from the client or validated the clients address. To prevent
+this deadlock, clients MUST send a packet on a probe timeout, or PTO;
+see Section 5.3 of {{QUIC-RECOVERY}}. In this case, the client MUST send an
+Initial packet in a UDP datagram of at least 1200 bytes if it does not have
+Handshake keys, and otherwise send a Handshake packet.

It seems to me that this doesn't matter.  Probing generally goes for ack-eliciting, and some might favour sending data over just a PING, but if the server only needs more bytes, it shouldn't matter if this is PADDING, PING, or CRYPTO. 

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